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.
I guess you have as little idea as me then about how it is intended to work?
-----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
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
