Peter Jeremy wrote: > On 2009-Dec-31 17:50:05 -0200, Gonzalo Tornaria <[email protected]> > wrote: >> gcc is actually inlining exp(1.0) to its correct value. The exp() from >> the sun library is incorrect. Try this program instead: > > FreeBSD libm is derived from Sun's libm and also gets exp(1) 1ULP high > on amd64 (on i386, exp() is written using i387 assembler) so I tend to > agree that the bug is in Sun's libm.
But if FreeBSD's libm for the 387 chips is based on Sun's library for a SPARC processor one needs to be cautious before making that assumption. If FreeBSD's implementation was based on Sun's library for the x86 processor, then I'd say FreeBSD got something wrong, since exp(1.0) is computed accurately with Open Solaris running on an Xeon processor. Virtually all computations on reals are going to introduce some errors. The fact the 387 can do some of those calculations in 80 bits means there is a reason for having a more accurate library than on the SPARC processor, which is only 64-bits. I do not know whether the SPARC processor has an instruction which computes exp(x) directly. Finding such a simple bit of information in manuals which are 100's of pages long, is no easy task. At least some of the manuals are here: http://www.sun.com/processors/documentation.html The oldest processor listed is the IIi, and the newest the T1, but one can find documents with the newer http://www.sun.com/processors/UltraSPARC-T2/perspectives.xml#anchor1 Somewhere here I have a paper copy of the 80387 processors manual, but I can't seem to find it. I think Richard's point about there being a tradeoff between speed and accuracy is important to keep in mind. Based on the 64/80 bit difference, I can see a justification for using a more accurate implementation of exp(x) on a x86 chip, than I can on a SPARC chip. If it going to take you long to compute something to an extra bit of accuracy, only to lose that bit as soon as you do any non-trivial computation with it, then one would have to question whether it was worth spending the extra time in the first place. Because the x86 processor works internally at 80 bits, it should be able to preserve all 64 bits when it writes to RAM. I'm not saying this is a bug, I'm not saying it is not. But the more I think about it, taking into account what I know of the 80 vs 64 issue, and what Richard said about the extra time needed to compute a result more accurately, I'm inclined to think this is not a bug. Dave -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
