On 2013-10-15 06:46-0000 Arjen Markus wrote: > Hi Alan, > >> -----Original Message----- >> From: Alan W. Irwin [mailto:[email protected]] > > ... >> >> In sum, there is an issue with our Python results on 32-bit Windows that >> needs to be >> confirmed also on 32-bit Linux. All theoretical analysis and practical gdb >> results I can >> come up with says this issue cannot occur. So I must be missing something >> and >> need help to figure this out. >> > > Could this be an issue with "extended precision"? It is a bit of a horror > that I deemed banished from > the earth, but it may be lingering on. The problem with extended precision is > that it makes reasoning > about programs with floating-point numbers almost impossible. Extended > precision uses 80 bits to > store intermediate results that may at unpredictable moments in the > computations get stored as 32- or > 64-bits numbers. While the intermediate results may be more accurate, they > cause havoc in the > final results.
Good question. Actually extended precision (using 80-bits to store intermediate floating-point results) is just a part of the deal whenever you are running software on Intel hardware. It's actually a good thing from the numerical precision point of view because the end result is that the final 64-bit values have much less significance loss than they do on non-Intel equipment. So I disagree with the negative connations of your "cause havoc in final results" comment. However, I do agree with you that because Intel equipment tends to have higher numerical precision results than expected, you do have to be careful about your floating-point precision arguments, especially when comparing results between library versions that have been compiled in different ways so the order of computations and the decisions about when to use extended precision are done differently. That said, I don't think we can appeal to extended precision to explain these results since we are comparing results calculated for _exactly the same_ core C library. The floating-point arguments of the PLplot C routines are definitely 64-bits and not 80 bits (regardless of whether the operating system and/or hardware is 32-bit or 64-bit). For the 32-bit Wine and x00 case, I have proven with gdb that the 64-bit floating-point arguments to the c_plenv C routine of our core C library are identical when invoked from either C or Python. So with absolutely identical input to the _same_ core C library in both cases (so those identical arguments are processed absolutely identically with all computations done in the same order and with the same internal decisions about whether to use extended precision or not), how can that library possibly produce different results in the two cases? The only way I can think of to answer that question, is there is some uninitialized variable in our core C library which effectively adds some unpredictability to our results depending on how the memory for that uninitialized variable was used previously. And Python has a large memory footprint so perhaps it is effectively initializing that uninitialized variable in a way that is very different from every other language. (And this would "explain" why most of the Python standard example results are affected.) However, I should point out this variable in our core C library must be properly initialized in the Linux 64-bit case since x00c produces absolutely clean valgrind results in that case with the -dev psc device. I don't have valgrind available to me on Wine (and you don't on Microsoft windows, either). But if Andrew has access to 32-bit Linux, and if he confirms these bad Python results occur for that case, then I suggest the first experiment he should do is a valgrind run in the C case to check for uninitialized variables on whichever standard examples have the simplest differences. (That was x00 in my case, but it might not be in his case.) And, Arjen, if you again confirm these same bad 32-bit python results on your 32-bit Windows platform, you might want to use every proprietary Windows code analysis tool at your disposal (purify?) on that system to look for any programming issues with our core C library that might lead to variables that are uninitialized. Finally, I should emphasize the above hypothesis is fairly improbable, but it is the best I can come up with to explain these improbably different Python results on a 32-bit operating system that is designed carefully to perform floating-point computations with the same level of precision (64-bit with some 80-bit internally) as 64-bit operating systems. 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 __________________________ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
