Re: FW: Transcendental function tables: comments welcome!

[Peter Henderson <petercbh@xxxxxxxxxxx>]

Vincent Lefevre wrote:
> On 2007-05-23 11:23:23 -0700, David James wrote:
>   
> > The tables were based on interpretations derived from:
> >   Draft 1.4.0, April 13, 2007
> >     
.
.
.

> Also, why would you choose sinpi(+inf) = NaN while pow(-1,+inf) = +1?
>   
I suspect your question may have been rhetorical, but here is an
answer anyway.

I don't know where the idea originated, or who adheres to it, but the
view that +/-infty is a positive integer is a bad one and contrary to
the  philosophy of the standard.  In the standard, f(infty) is the
limit as the real argument tends to infinity, NOT the limit as the
floating point numbers tend to infinity if we allow the exponent to
grow indefinitely.

The adoption of the view that infty is a positive integer tends turns
up when a floating point number is being used to represent integer
arguments, i.e. in a function of the integers as opposed to the reals,
which answers your question of why the two cases are treated
differently.  But it just as surely leads to nonsense.  If floating
point numbers are being used to represent integer arguments, which
only makes sense if the processor has no native integer format, then
f(infty) is the limit as the integer argument tends to infinity, NOT
the limit as the representable integers approach their maximum.

The purpose of having a floating point representation of infinity in
the standard is to allow the indication of certain error conditions
without incurring the penalty of triggering the exception handling
machinery, which in general leads to an unrecoverable condition,
leaving no option except for the program to halt.  The is condition is
nearly always unrecoverable as few languages properly incorporate
hardware exception handling.  For C at least, it is impossible to
write exception handlers that do anything else other than longjump or
call a procedure that does not return.  In such circumstances,
programmers are forced to check these exceptional conditions won't
occur before the operation is performed, which, in the case of
overflow is a particularly onerous requirement.  Defining arithmetic
operations for these infinities, means that in many circumstances,
these conditions can be ignored and the problem will rectify itself in
useful manner.

The objections to this approach are that makes problems difficult to
track down and that the unwary user can receive nonsensical results
without any indication.  A response to the first of these objections
is that some means should be provided to turn off the default
exception handling during debugging, which in general is the case.  As
for the second objection, in practice, if returning infinity does not
lead to a sensible result, NaN's start to appear almost immediately.
Of course many people aren't satisfied with this appoach.

So the correct answer to your tricj question is that pow(-1, +inf) = NaN.
> To avoid such inconsistencies, general rules may be useful.
>   
Regards,
Peter Henderson