Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:[email protected]] > > 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. >
I will not claim to understand all details regarding extended precision, but as far as I do understand them, extended precision is controlled by the hardware instruction set, not so much by the human-readable source code. Furthermore, debuggers can be easily fooled: they deal with the numbers representable in ordinary precision, whereas the extra bits used in extended precision remain hidden. Because there are only a few registers capable of holding them, a program has to convert results back and forth and in a manner that does not allow analysis. Hence, the result may be more precise, but in an unpredictable way. A slight change in the order of operations and things can go another way. >From more or less recent newsgroup postings I gather that the newer processors >do not include extended precision instructions - they are also bad for vectorisation. Some more information: http://www.vinc17.org/research/extended.en.html (One of my favourite arguments against extended precision is a simple program to determine the value of "epsilon", that is, the smallest number eps such that 1.0+eps can be distinguished from 1.0. With extended precision in charge, you get too small a value!) That said, I will have a look at the Python/Windows results, as I do not remember ever seeing such a long list of differing examples before. Regards, Arjen 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. ------------------------------------------------------------------------------ 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
