Need help with a maths problem!

Our "pub" where you can post about things completely Off Topic or about non-silent PC issues.

Moderators: NeilBlanchard, Ralf Hutter, sthayashi, Lawrence Lee

Post Reply
chylld
Posts: 1413
Joined: Fri Oct 10, 2003 4:45 pm
Location: Sydney, Australia
Contact:

Need help with a maths problem!

Post by chylld » Wed Jan 03, 2007 10:28 pm

hi all

i realise this is a bit of a long shot, but for the math/geometry geniuses out there i need help with a seemingly simple problem :)

imagine a path made up of circles of varying diameter. some circles are close together, others further apart. the problem involves finding the shortest path from the first circle to the last circle, touching (or going through) each of the in-between circles in order, a bit like this:

Image

i know the position and radius of each circle, so i know it's solvable - my brain just can't seem to figure out a working algorithm!

any ideas anyone??

jb_
Posts: 65
Joined: Sun Dec 04, 2005 11:16 pm
Location: Sydney, Australia

Post by jb_ » Thu Jan 04, 2007 12:09 am

Can't help you out with a full algorithm... but maybe this will help. This is the simplest part of the algorithm (eliminating co-linear circles like #2 from the list) but the rest of it is actually really difficult... the intersection point of the line with a particular circle is not just dependent on the circles either side but on every single circle, right to either end of the list. e.g. considering #4, moving circle #6 would change the optimal intersection point on circle #5, which would mean that #4's optimal intersection point changes too. (I typed out the steps below before realising this.... so point #1 wouldn't be true unless you were looking at either end of the list (circle #1 or #6 in the example))

What's this for? It sounds too difficult to be a uni assignment (I'm studying engineering and I'm not sure how I'd go about implementing an algorithm for this).

Anyway, here's a way you could eliminate redundant, co-linear circles like #2

1. The line (if extended) would necessarily pass through the first circle's centre. I can't prove it... but consider any placement of the other circles and you'd see this were true too. If an extension of the line didn't pass through the centre of the 1st circle, it would be longer than necessary.

2. Thence you would want to consider the next circle, and find the range of ray angles from the first circle that would also pass through the next circle. You could do this by comparing the centre of the next circle to the centre of the first circle to get the middle of the angle range, and then using inverse tan to find the magnitude of the range either side of the middle of the range. However, you wouldn't draw the line connecting the circles yet.

3. Repeat step 2 - first you would've compared the angle range of #2 from #1, next compare the angle range of #3 from number #1. Basically what you're trying to do is finding where the 'co-linearity' of the circles stops. In this example, #1-#3 are co-linear but not #4. Comparing #2 with #1 would give you a pretty wide range of angles, comparing #3 with #1 then narrows it down. Step 2 is repeated until you find a circle whose angle range from #1 no longer intersects with the narrowed-down angle range (that you've found by examining #2 and #3).
[size=92][b]Laptop:[/b] Macbook Pro - Core Duo @ 1.83ghz - 2gb DDR - 100gb @ 7200rpm - [b]MacOS/WinXP dualboot[/b]
[b]Desktop:[/b] Northwood C @ 3.0ghz [i]Passive[/i] w/ Scythe Ninja - Abit IC7-G - 2gb DDR - X800Pro - Samsung 160gb (suspended) - 2x Nexus 12cm
[b]Server:[/b] A64 Venice 3000+ @2.16ghz/1.25V - DFI RS482 - 512mb - Samsung 200gb - Maxtor 250gb - WD 300gb[/size]

chylld
Posts: 1413
Joined: Fri Oct 10, 2003 4:45 pm
Location: Sydney, Australia
Contact:

Post by chylld » Thu Jan 04, 2007 12:25 am

thanks for the response jb_ :) interesting to hear from another aussie (let alone sydneysider) first!

i appreciate your thoughts on eliminating/ignoring co-linear circles - that was actually the first step i took as well :) essentially drawing rays of possible directions and then narrowing it down by "looking through" the nearest circle to the next, and so on.

using this approach, it appeared that when the angle of rays is as small as it can go, something needs to happen at the first 'narrowing' of the longest current ray (at some circle C) to allow the rays to 'turn' and thus open up more angles to make a turn of some sort. unfortunately the arrival and departure points that lie on this circle C seem to be almost always different, and the fact that all regions are circles certainly doesn't help.

a simplification i'm using at the moment involves replacing each circle of diameter d with a square of side length d; this eases the load on the brain quite a lot.

this isn't for a uni assignment, more a project i'm undertaking on my own. i finished uni (software engineering) 2 years ago, and apart from some math courses i did i'd have to agree that this would seem hard for a uni assignment. unfortunately, this is still only a simple step, as the final algorithm will also have to consider the weight of each line (which changes between points) - but we'll ignore that for now.

jb_
Posts: 65
Joined: Sun Dec 04, 2005 11:16 pm
Location: Sydney, Australia

Post by jb_ » Thu Jan 04, 2007 12:45 am

No problems, sorry if it sounded a little basic.

Because of the nature of this problem (I think it would be called a multivariate optimisation?) I don't think there's a cut-and-dried algorithm that would produce the correct answer with one iteration.

You know you've got the shortest path when the angles made by the line with the tangent to the circle where it intersects, are equal as the line approaces the circle and as it leaves the circle. Maybe this could be the basis for an iterative process where you just plonk the line anywhere on the circle, and then repeatedly going through the list of circles, moving the intersection point to where the angles with the tangent on either side are equal. 1000 iterations and you'd get pretty close to the optimal solution. Or, since with each iteration the reduction in total line length approaches zero, you could just keep iterating until the delta goes under a certain threshold.

(Funny that, I'm studying SE too [though combined with commerce, majoring in finance]!)
[size=92][b]Laptop:[/b] Macbook Pro - Core Duo @ 1.83ghz - 2gb DDR - 100gb @ 7200rpm - [b]MacOS/WinXP dualboot[/b]
[b]Desktop:[/b] Northwood C @ 3.0ghz [i]Passive[/i] w/ Scythe Ninja - Abit IC7-G - 2gb DDR - X800Pro - Samsung 160gb (suspended) - 2x Nexus 12cm
[b]Server:[/b] A64 Venice 3000+ @2.16ghz/1.25V - DFI RS482 - 512mb - Samsung 200gb - Maxtor 250gb - WD 300gb[/size]

jb_
Posts: 65
Joined: Sun Dec 04, 2005 11:16 pm
Location: Sydney, Australia

Post by jb_ » Thu Jan 04, 2007 12:51 am

As a starting point for the above process, you could use the point on a particular circle (e.g. #4) that lies on the line connecting the centre of that circle (#4) with the midpoint of the line connecting the centres two adjacent circles (#3 and #5). That'd give a rough approximation from which you could iteratively optimise.
[size=92][b]Laptop:[/b] Macbook Pro - Core Duo @ 1.83ghz - 2gb DDR - 100gb @ 7200rpm - [b]MacOS/WinXP dualboot[/b]
[b]Desktop:[/b] Northwood C @ 3.0ghz [i]Passive[/i] w/ Scythe Ninja - Abit IC7-G - 2gb DDR - X800Pro - Samsung 160gb (suspended) - 2x Nexus 12cm
[b]Server:[/b] A64 Venice 3000+ @2.16ghz/1.25V - DFI RS482 - 512mb - Samsung 200gb - Maxtor 250gb - WD 300gb[/size]

chylld
Posts: 1413
Joined: Fri Oct 10, 2003 4:45 pm
Location: Sydney, Australia
Contact:

Post by chylld » Thu Jan 04, 2007 1:35 am

*sigh* ... an iterative approach is looking more and more appealing the more i think about the problem...

do you think an iterative approach would adapt well if each section of line coming off a circle was weighted differently? i admit i'm having a bit of difficulty visualising an iterative approach (though not by fault of your explanation) - and as such would rather avoid spending time on it if it ultimately can't be used.

i imagine that the iterative approach would be O(n) or O(n^2), which is reasonable enough given that i don't expect there to be more than 200-300 circles in any single calculation (typically around 50-100). i was also thinking of a brute force solution where you split each circle up into a circular arrangement of p points, and test each possible path... however this is obviously inefficient (O(p^n) without optimisation) :twisted:

chylld
Posts: 1413
Joined: Fri Oct 10, 2003 4:45 pm
Location: Sydney, Australia
Contact:

Post by chylld » Thu Jan 04, 2007 3:20 am

jb_ wrote:1. The line (if extended) would necessarily pass through the first circle's centre. I can't prove it... but consider any placement of the other circles and you'd see this were true too. If an extension of the line didn't pass through the centre of the 1st circle, it would be longer than necessary.
i understand and agree with this point now. the way i'm visualising it in my head is to draw a line through all of the midpoints, and 'tighten' it by pulling it through the start midpoint and end midpoint. what you would end up with is a series of connected, straight lines which would be the answer.

so easy to say and to visualise... hard to algorithm-ify :)

Felger Carbon
Posts: 2049
Joined: Thu Dec 15, 2005 11:06 am
Location: Klamath Falls, OR

Post by Felger Carbon » Fri Jan 05, 2007 10:09 am

The problem (a variant of the well-known "traveling salesman" problem) is slightly misstated. The real problem is to mathematically prove that the optimum (shortest) path has been found, for a particular set of circles. After all, finding a path is trivial.

Arvo
Posts: 294
Joined: Sat Jun 10, 2006 1:30 pm
Location: Estonia, EU :)
Contact:

Post by Arvo » Fri Jan 05, 2007 1:15 pm

IMHO this is not a traveling salesman problem - because order of circles is know beforehand (or did I misunderstand?). This is just nasty problem to formalize in easily computable way.

-------------------------------

edit: some kind of possible solution or at least little idea:

Sorry, but I don't know math terms in english - if something is wrong or not understandable, please correct and ask.

Assume:

1. N+1 circles have center coordinates X0(n),Y0(n) and radiuses R(n), n in [0,N]
2. every circle crosses line at one point, creating angle A(n), A(n) in [0,2*pi)
3. intersection point has coordinates X(n),Y(n), which can be calculated from:
X(n)=X0(n)+R(n)*sin(A(n))
Y(n)=Y0(n)+R(n)*cos(A(n))
NB! We can safely assume that every circle intersects line in one point - we can just skip other point, if it exists
4. line length L(n)=sqrt((X(n)-X(n-1))^2+(Y(n)-Y(n-1))^2), n in [1,N]
5. we need minimize sum(L(n)) by changing A(n)

Iterative solution, let S(s) mean sum(L(n)) at step s, s in [0,...] (look at edit2):

0. set inital values A(n)=0, s=0, calculate S(0)
1. for each n in [1,N] find min(L(n)) by changing A(n-1) (ideally by differentiating, but can be iteratively too)
2. for n=N find min(L(N)) by changing A(N)
3. set s=s+1, calculate S(s)
4. if abs(S(s)-S(s-1))>precision goto step 1


Problems:

1. there's no proof that such iteration will converge - result sum can be oscillating
2. there's no proof that even iteration converges, then it converges enough fast to find actual minimum value (before iteration will be cancelled by reaching given precision)

-------------------------------

edit2: somewhat better iteration:

0. set inital values A(n)=0, s=0, calculate S(0)
1. for n=0 find min(L(1)) by changing A(0)
2. for each n in [1,N-1] find min(L(n)+L(n+1)) by changing A(n) (ideally by differentiating, but can be iteratively too)
3. for n=N find min(L(N)) by changing A(N)
4. set s=s+1, calculate S(s)
5. if abs(S(s)-S(s-1))>precision goto step 1

This should converge faster :)

chylld
Posts: 1413
Joined: Fri Oct 10, 2003 4:45 pm
Location: Sydney, Australia
Contact:

Post by chylld » Fri Jan 05, 2007 10:45 pm

thanks for the thoughts guys; i really appreciate it!

felger carbon: the problem is not a tsp, as i know the order of the circles already (apologies for possibly not making this obvious earlier) and hence the 'rough' path through the circles i need to take. but you are right in that finding any path is trivial - i'd simply travel through each circle's centres in order! :)

arvo: interestingly i think i actually understand your maths! are you saying essentially (for "edit2") that you change the angle at one circle while examining the lengths coming either way off this point? please correct me if i am wrong.

one thing we know already is that for two points on the "outside" of a circle's tangent (i.e. a line joining them does not touch or cross the circle) the path representing the shortest distance has equal angles of incidence and reflection:

Image

in the diagram, if you reflect B about the tangent, the shortest path between A and B is obviously a straight line, hence the equal angles theta. any other point on the line will yield a longer AB distance, and from the diagram it is also obvious that any point on the circle will yield a longer distance (except for the point on the tangent of course.)

given that we know this, i believe the challenge lies in defining the circle arc on which a point may lie (i.e. the bounds for R(n)), and getting a good estimate and effecting the above rule as many times as is necessary to get < precision.

Arvo
Posts: 294
Joined: Sat Jun 10, 2006 1:30 pm
Location: Estonia, EU :)
Contact:

Post by Arvo » Sat Jan 06, 2007 7:10 am

chylld wrote:arvo: interestingly i think i actually understand your maths! are you saying essentially (for "edit2") that you change the angle at one circle while examining the lengths coming either way off this point? please correct me if i am wrong.
You are right, this is what I meant.

One picture is worth more than thousand words:

Image

As you can see, this algorithm handles both cases (line only touches circle or goes through it) without need to vary R(n). Red line corresponds to current optimal line placement, what you need to achieve by changing (currently increasing) A(n).

Your claim (the path representing the shortest distance has equal angles of incidence and reflection) is of course right, but completely irrelevant in my iterative algorithm.

Of course you can decrease computational cost by analyzing scene and splitting it to two cases - straight line intersects circle or not. But I think that computation time won't be too big anyway, even using my "brute force" approach.

Disclaimer.
I can't guarantee that my math is right or my algorithm gives any reasonable results. After all, I've not dealt with math problems for many-many years...

chylld
Posts: 1413
Joined: Fri Oct 10, 2003 4:45 pm
Location: Sydney, Australia
Contact:

Post by chylld » Sun Jan 07, 2007 2:31 pm

nice diagram arvo :) i think i finally understand your approach - rely on a totally forward-based iteration/differentiation solution, rather than my method of trying to use a few rules/laws and building around those.

your method has a distinct advantage in that it will always satisfy the objective of having the path touch each circle in order. my approach involved the calculation of the 'arc' on each circle, and since each arc is more and more of an estimation compared to the last, posed the problem of missing a circle altogether during optimisation.

i'm not yet sure if it's possible to use differentiation to our advantage, but when i get to that stage i'll definitely try to use it (along with the 2nd derivative) to get some minimum points which will ease the burden of a purely iterative approach.

the only flaw i can see with your brute-force approach is the case where in a sequence of circles A B and C, circles A and C lie entirely within circle B. the shortest path would hence be the shortest path straight from A to C, however the algorithm requires the path to touch the circumference of circle B and hence would result in an incorrect solution.

obviously an ideal would be to sample the whole area within each circle rather than just the circumference, but i have a feeling this is rather inefficient :) any thoughts on this?

Arvo
Posts: 294
Joined: Sat Jun 10, 2006 1:30 pm
Location: Estonia, EU :)
Contact:

Post by Arvo » Mon Jan 08, 2007 8:37 am

chylld wrote:the only flaw i can see with your brute-force approach is the case where in a sequence of circles A B and C, circles A and C lie entirely within circle B. the shortest path would hence be the shortest path straight from A to C, however the algorithm requires the path to touch the circumference of circle B and hence would result in an incorrect solution.
Da*n, you broke my nice universal algo :P (Like my everyday programming work - always some client finds hole in otherwise foolproof solution.)

Actually I assumed that circles do not overlap (exactly like coding - most problems arise from incorrect or misunderstood problem description). The latest case needs different formulas (like you said - iterate over the whole circle - or something equivalent); minimizing by two arguments (radius and angle - or some other pair of independent values) is somewhat more difficult.

I'll think about that in some later time :)

chylld
Posts: 1413
Joined: Fri Oct 10, 2003 4:45 pm
Location: Sydney, Australia
Contact:

Post by chylld » Mon Jan 08, 2007 12:27 pm

overlapping circles represent a case i also had not considered at first, but having just recently seen the data for which the algorithm will be used, it seems quite inevitable.

thankfully my brain is working this morning; a workaround to that is to not just consider the circumference of the current circle (i.e. varying An at the same Rn) but also the parts of the circumferences of other circles that lie within this circle.

assuming the differentiation doesn't prove too difficult, the hardest part would be to find the local minima on these arcs, as it might be hard to find stationary points.

but it should work :)

chylld
Posts: 1413
Joined: Fri Oct 10, 2003 4:45 pm
Location: Sydney, Australia
Contact:

Post by chylld » Tue Jan 09, 2007 10:58 pm

results! :)

Image

this is with only 2 iterations. obviously it's a very simple case, but it's a good sign of things to come. thanks all for the help so far!

Post Reply