Re: Sorry Ross: No Sale
You're a hard man jb, to make me search a cvsweb on a phone line...
glibc-2.3.2 inverse cosine, single:
[link|http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/i386/fpu/e_acosf.S?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=glibc|http://sources.redha...kup&cvsroot=glibc]
glibc-2.3.2 inverse cosine, long double:
[link|http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/i386/fpu/e_acosl.c?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=glibc|http://sources.redha...kup&cvsroot=glibc]
The whole IEEE interface:
[link|http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/i386/fpu/?cvsroot=glibc|http://sources.redha...pu/?cvsroot=glibc]
This is interesting:
[link|http://www.ussg.iu.edu/hypermail/linux/kernel/0103.0/0453.html|http://www.ussg.iu.e.../0103.0/0453.html]
(drill down down down)
What Linux does presently on x86 is as right as right can be on this platform. Compare with what MS's compilers do (die when you run out of the fp stack slots, telling users to simplify the expressions in the source code) and be happy. The *BSD choice is valid by some lines of thought, but it also denies people the happy accident of computing with more precision and range than they thought they needed. Overall, computing with x86 double-extended is a good thing so long as you don't introduce multiple roundings. That's a compiler issue, not a kernel one. Historical note: According to one of the x87 designers, this all boils down to the simple fact that there's no time when a pair of collaborators in California and Israel can be both awake and lucid enough to explain things well over a noisy telephone line. Amazing that it really wasn't long ago. And if anyone's really interested, keep checking
[link|http://www.cs.berkeley.edu/~wkahan/|http://www.cs.berkeley.edu/~wkahan/]
as some of Dr. Kahan's older papers are slowly converted and added. They give a great deal of insight into the choices that eventually became the accepted IEEE 754 standard.
-drl