David Noon wrote in a message to Tom Almy:

TA> I discovered that if you use the inline function optimization,
TA> trig functions break with large argument values. Try sin(1e30) --
TA> the result isn't between -1 and 1!

 DN> There was a discussion in the Usenet comp.lang.rexx Newsgroup a 
 DN> couple of weeks ago about errors evaluating transcendental 
 DN> functions. This specific problem was included.

Rexx is a special case because of the way numeric operations are required
to be performed.  Rexx also accepts a significant speed penalty on this
kind of math because it is intended to provide consistent results across
widely different platforms, such as OS/2 and OS/390 (ex-MVS).

 DN> The issue arises over the uncertainty in the argument
 DN> exceeding the full cycle from 0 to 2*pi, which means that
 DN> any value in the range -1 to 1 could be returned as being
 DN> valid. I suspect Intel has chosen to ignore this in the
 DN> hardware implementation of trig. functions, and the FPU
 DN> simply returns whatever turns up after its [probably]
 DN> iterative algorithm has run its course.

This is a classical problem.  Knuth shows that no machine is capable of
solving these kinds of problems in the most general case, and that all
floating point operations are eventually going to run smack into problems
of exactly this sort.  The best you can do is formulate a set of rules
which guarantee consistemt behavior, and that is what IEEE compliance gives
you.  It is important to understand that the IEEE rules are not
particularly "right" or "valid" in any mathematical
sense, but rather that the IEEE rules are designed to provide consistency
within the restrictions of commonly used machine word sizes.

The Intel FPU does trig operations in a basically non-iterative manner, and
actually does table lookup followed by interpolation.  Even relatively
simple operations such as division are handled initially in this way, as
the world found out when the infamous Pentium FDIV bug was discovered.
 
-- Mike


---