From: Hazen B. <hba...@ma...> - 2015-05-13 15:46:12
|
Hello Alan, Arjen, As I mentioned before, the FPE's in x25c, x30c and x33c are all coming from the notcrossed() function in plfill.c. Hopefully you can provide some insight as the authors. Basically the problem arises in a situation where the two lines do not cross, but are not parallel. In this situation this function still calculates the x,y intersection. However, depending on the position and orientation of the two lines this intersection can be way outside the range of values that can be represented using (4 byte) integers. Do you recall if functions that call this function expect to receive a valid intersection point in this case? Or is it ok to just return zero? -Hazen |
From: Alan W. I. <ir...@be...> - 2015-05-13 21:50:26
|
Hi Hazen: On 2015-05-13 11:46-0400 Hazen Babcock wrote: > > Hello Alan, Arjen, > > As I mentioned before, the FPE's in x25c, x30c and x33c are all coming from > the notcrossed() function in plfill.c. Hopefully you can provide some insight > as the authors. Basically the problem arises in a situation where the two > lines do not cross, but are not parallel. > In this situation this function > still calculates the x,y intersection. However, depending on the position and > orientation of the two lines this intersection can be way outside the range > of values that can be represented using (4 byte) integers. Do you recall if > functions that call this function expect to receive a valid intersection > point in this case? Or is it ok to just return zero? Hi Hazen: I have reviewed plfill.c, and the returned intersection from notcrossed is only used when status is zero. So I have (commit ID = b916d4b) considerably simplified noncrossed to do the PLINT transformation of the intersection and return those values _only_ when status = 0. This change solved all fpe problem for examples 25 and 30, but there are remaining fpe issues for fortran examples 21 and 33. The logic in noncrossed is pretty bullet-proof now so my prediction is those remaining fpe issues are completely independent of notcrossed or else there is a non-initialized variable somewhere in fortran examples 21 and 33. But I look forward to your definitive conclusion concerning those remaining fpe issues. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2015-05-14 15:43:08
|
On 05/13/2015 05:50 PM, Alan W. Irwin wrote: > > Hi Hazen: > > I have reviewed plfill.c, and the returned intersection from > notcrossed is only used when status is zero. So I have (commit ID = > b916d4b) considerably simplified noncrossed to do the PLINT > transformation of the intersection and return those values _only_ when > status = 0. > > This change solved all fpe problem for examples 25 and 30, but there > are remaining fpe issues for fortran examples 21 and 33. The logic in > noncrossed is pretty bullet-proof now so my prediction is those > remaining fpe issues are completely independent of notcrossed or else > there is a non-initialized variable somewhere in fortran examples 21 > and 33. But I look forward to your definitive conclusion concerning > those remaining fpe issues. The issue in example 21 seems to be in the qhull library. I will look into building a qhull with debug flag to try and track this one down. The remaining issue in example 33 is that we are multiplying -2.0e-200 times 9.9e-201 when calculating iedge[i] in pldrawcn() at line 695 of src/plcont.c. The result of this calculation, ~1.0e-400, is smaller than what can be represented using floating point numbers. I changed the login in pldrawcn() to do the sign determination without doing this multiplication. I've just pushed this fix. -Hazen |
From: Hazen B. <hba...@ma...> - 2015-05-14 15:48:37
|
On 05/14/2015 11:42 AM, Hazen Babcock wrote: > On 05/13/2015 05:50 PM, Alan W. Irwin wrote: >> >> Hi Hazen: >> >> I have reviewed plfill.c, and the returned intersection from >> notcrossed is only used when status is zero. So I have (commit ID = >> b916d4b) considerably simplified noncrossed to do the PLINT >> transformation of the intersection and return those values _only_ when >> status = 0. >> >> This change solved all fpe problem for examples 25 and 30, but there >> are remaining fpe issues for fortran examples 21 and 33. The logic in >> noncrossed is pretty bullet-proof now so my prediction is those >> remaining fpe issues are completely independent of notcrossed or else >> there is a non-initialized variable somewhere in fortran examples 21 >> and 33. But I look forward to your definitive conclusion concerning >> those remaining fpe issues. > > The issue in example 21 seems to be in the qhull library. I will look > into building a qhull with debug flag to try and track this one down. > > The remaining issue in example 33 is that we are multiplying -2.0e-200 > times 9.9e-201 when calculating iedge[i] in pldrawcn() at line 695 of > src/plcont.c. The result of this calculation, ~1.0e-400, is smaller than > what can be represented using floating point numbers. I changed the > login in pldrawcn() to do the sign determination without doing this > multiplication. I've just pushed this fix. Hm, got the signs backwards, hopefully it is correct now. -Hazen |