[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