[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: gEDA-dev: Arc intersection connectivity bug



On Fri, Nov 13, 2009 at 08:28:33AM +0000, Ineiev wrote:
> On Thu, 2009-11-12 at 20:06 +0000, Ineiev wrote:
> > Probably the function should be rewritten almost completely.
> > I'll try tomorrow.
> 
> And this is what comes in the attachment.
> 
> First, I suggest computations against the centerlines
> of arcs; this simplifies the geometry and does not
> impose limitations because we have no square-ended arcs.
> 
> The general method is to use IsPointOnArc to test several
> candidates and return false if all tests results are negative.
> 
> Thus, the suggested sequence is:
> 
> (1) check the ends of each arc against the other arc.
>     this is done unconditionally, as it would be needed
>     in all groups of cases (2)..(4) under certain conditions.
> 
>     generally, the nearest distance from one arc to
>     another is achieved either on an end of the first
>     or the second arc, or on the line connecting
>     the centers of the arcs.
> 
> (2) check concentric arcs.
>     it is treated now almost correctly; but
>     the bounding boxes are irrelevant; also,
>     I'd s/l == 0\.0/l < 0\.5/ because I believe
>     that the compiler should have freedom to optimise
>     the former to false.

No, there are very few things that you can optimize in floating
point computations. Not even adding 0.0, multiplying by 1.0 or
comparing a number with itself. That is unless you use some
weird options like -ffast-math.

	Gabriel.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user