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
__________________________

------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to