Hi Phil, Alan, Maurice,
I have had a look at the code (both Phil’s patch and the original). I am a bit
uncomfortable here:
- The original, using factor_NBCC cannot be correct, if only for
dimensional reasons. “factor” is clearly a signed surface area, so that its
dimension is L^2, whereas “factor_NBCC” has the dimension length (L).
- Phil’s patch uses FLT_MIN or DBL_MIN as a threshold for indicating
nearly parallel lines, but FTL_MIN is 1e-38 and DBL_MIN is even smaller. Given
that the incoming arguments are integer, these thresholds will simply never be
triggered.
My understanding is that the code tries to determine whether the angle between
the two lines is very small by calculating the area spanned by the vectors
defining the direction of the lines (this is “factor”) and comparing it to a
small value. But that value should be related to the length of both these
vectors. I would say something like this ought to work:
factor = … ; /* This is sin(angle) * length vector 1 * length vector 2 – plane
geometry */
limit = 0.01 * length vector 1 * length vector 2; /* This means an angle of
0.01 radians or 1 degree */
if ( fabs(factor) < limit ) {
status = status | NEAR_PARALLEL;
}
Alas, no time right now to elaborate further.
Regards,
Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, June 15, 2015 11:59 PM
> To: Phil Rosenberg
> Cc: Arjen Markus; plplot-devel@lists.sourceforge.net
> Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c
>
> On 2015-06-15 21:07+0100 Phil Rosenberg wrote:
>
> > I will have to try out git blame then. I imagined that something so
> well embedded would predate our git usage, but I guess our svn history was
> brought
> in too.
>
> Yes, Hazen and I were careful to preserve our history back to the start in
> ~1992 which in retrospect was really a smart idea because of facilities like
> "git
> blame".
>
> > I guess you have as little idea as me then about how it is intended to work?
>
> Hi Phil:
>
> Actually, if "it" refers to the notcrossed function, I do think I understand
> exactly what
> it is supposed to do, and I tried to explain it on my previous post which you
> quoted
> and which I quote again below.
>
> I suspect you may have just read my first comment below and then quit. :-)
>
> Alan
>
> >
> > -----Original Message-----
> > From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
> > Sent: 15/06/2015 19:18
> > To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
> > Cc: "Arjen Markus" <arjen.mar...@deltares.nl>;
> > "plplot-devel@lists.sourceforge.net"
> > <plplot-devel@lists.sourceforge.net>
> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c
> >
> > Hi Phil:
> >
> > "git blame" is your friend for figuring out who authored what, and it
> > turns out I am virtually (except for a change by Hez) the sole author
> > of notcrossed, but IIRC, that built on top of what Arjen had done
> > before with (embedded logic rather than a function) which built on top
> > of what Maurice had done before....
> >
> >
> > On 2015-06-15 11:10+0100 Phil Rosenberg wrote:
> >
> >> Hi Arjen
> >>
> >> I've just copied the code below as I don't just have time at the
> >> moment to sort a git patch (The plot I was making is for a
> >> presentation this afternoon!). The old code has been commented out
> >> with /* */ and my new code is directly above that from the #ifdef
> >> onwards.
> >>
> >> Basically I get that the variable factor will be zero for parallel
> >> lines and I get that there is a precision limit on that due to
> >> floating point rounding. However I don't understand how factor_NBCC
> >> works as a test.
> >>
> >> For the bug in question the inputs were xA1=20994, yA1=12219,
> >> xA2=4915, yA2=12561 xB1=20979, yB1=12219, xB2=20979, yB2=12221.
> >> Although perhaps the As and Bs were reversed, but the flagging should
> >> be identical.
> >
> > I (and presumably the rest here) were having a hard time figuring out
> > whether those two lines mathematically intersected or not. So I have
> > prepared a plot (see attached) that demonstrates that the two lines
> > _do_ mathematically intersect (where the red line is a clipped portion
> > of the A line segment and the yellow line is the B line segment in
> > totality.)
> >
> > Note however, that all the xA1, etc. values have a precision of +/- 2
> > because of rounding issues so the purpose of the PL_NBCC = 2 fuzz
> > factor is to make sure that the result are not subject to such
> > rounding issues, i.e., notcrossed only returns 0 status if the
> > crossing would occur regardless of shifts of +/- 2 in each of the xA,
> > yA, xB, and yB coordinates. And of course, in this case when the
> > second line segment only has a length of 2, the crossing result is
> > never going to be definite so you will always get a non-zero return
> > code from notcrossed.
> >
> > If that explanation makes sense to you, but you still feel noncrossed
> > needs a fix, please send that in git format-patch form so I can
> > conveniently evaluate your proposed logic change. But I suspect the
> > noncrossed logic is fine, and the fix for the issue you found needs to
> > be made in another part of our code to deal correctly with non-zero
> > return values from notcrossed.
> >
> > By the way, I hope your presentation went well despite the distraction
> > introduced by this PLplot bug you discovered at the last minute.
> >
> > Alan
> > __________________________
> > Alan W. Irwin
> >
> > Astronomical research affiliation with Department of Physics and
> > Astronomy, University of Victoria (astrowww.phys.uvic.ca).
> >
> > Programming affiliations with the FreeEOS equation-of-state
> > implementation for stellar interiors (freeeos.sf.net); the Time
> > Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> > software package (plplot.sf.net); the libLASi project
> > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> > and the Linux Brochure Project (lbproject.sf.net).
> > __________________________
> >
> > Linux-powered Science
> > __________________________
>
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project
> (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi
> project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the
> Linux Brochure
> Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
