Re: libm trigonometric functions and i387

[christos%astron.com@localhost (Christos Zoulas)]

In article <20090224190659.B69869828B%pluto.mumble.net@localhost>,
Taylor R Campbell  <campbell%mumble.net@localhost> wrote:
>   Date: Tue, 24 Feb 2009 10:42:49 -0700
>   From: Sverre Froyen <sverre%viewmark.com@localhost>
>
>   How do you accurately pass an argument of 2^63 to libm's trig functions?  A 
>   quick look suggests your only choices are float or double.  For an argument 
>   value of 2^63, the uncertainty exceeds 2*pi by several orders of magnitute.
>
>That's not the point.  Each (numeric) floating-point value has a
>unique associated real number, and each real number has a unique sine,
>cosine, or tangent.  While the sine, cosine, and tangent of most real
>numbers are not exactly representable in floating-point, there are
>good approximations and there are bad approximations.  There is code
>in NetBSD's libm to compute good approximations, and there is (rather
>silly) code to compute bad approximations.  I want to invoke the code
>that computes good approximations, just like I'd get for addition,
>multiplication, square roots, &c., in the IEEE standard.  (If I wanted
>bad approximations, again, I could just pass the flags -ffast-math and
>-funsafe-math-optimizations to GCC.)  I also don't want to edit
>/etc/ld.so.conf.
>
>There are plenty of eminently Googlable arguments on the intertubes
>about the uncertainty you mention, and about the merit or numerical
>stability of algorithms that might try to compute the sine of 1e22.
>That's not what I'm interested in, but I'm sure you can Google up
>plenty of entertaining discussions about it if it is what you're
>interested in.

You are right and there is no good way to make this selection because
the policy decision is done at system level in ld.so.conf. We could
provide a better selection mechanism that is more fine-grained.

christos