[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: FW: Transcendental function tables: comments welcome!
On 2007-06-03 14:56:07 +1000, Peter Henderson wrote:
Vincent Lefevre wrote:
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.
For f(x) = (+0) * x, that's why (+0) * (+Inf) is the limit of (+0) * x
when x -> +Inf on the real numbers, hence +0, isn't it? :)
Really, the current definition of the infinity in the standard is buggy.
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.
No, it doesn't. First, more precisely, for the same reason that +Inf
can be regarded as a (large) positive integer, +Inf can be regarded
as a (large) positive even integer (this is not really important for
sinpi, but is for cospi). Now, if x is a positive even integer, one
has: pow(-1,x) = +1, sinpi(x) = 0 and cospi(x) = 1. So, I repeat my
question:
Why would you choose sinpi(+inf) = NaN while pow(-1,+inf) = +1?
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,
Of course, this is completely wrong in IEEE 754, which guarantees
that operations on integers are exact as long as the result is
representable. So, using floating-point numers to perform integer
computations makes sense. I did that many times. There are even
several good reasons:
* Some functions are available on floating-point numbers only
(e.g. pow in ISO C99).
* On some platforms, a floating-point number can represent more
consecutive integer values than an integer type (e.g. 54-bit
integers vs 32-bit integers). This is less and less true,
though.
* On some processors, floating-point computations can be faster
(either because a single operation is faster or because there
are more units).
then f(infty) is the limit as the integer argument tends to
infinity, NOT the limit as the representable integers approach their
maximum.
Well, the reason of taking the limit on the floating-point numbers was
not that floating-point numbers could be used to represent integers.
It was probably to preserve properties in case of overflow, e.g. if
one has property P(x) for finite floating-point number x > x0, then
one should still have it for x = +Inf. Note that in this case, 0 has
the same treatment because of the underflow.
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.
If you mean that the purpose of infinity is to detect errors, this
is not the reason, since 1/+Inf gives 0: with a common operation,
you lose the error condition!
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.
That's precisely the reason why it can be better to make pow(-1,+Inf)
return +1 instead of NaN.
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.
Of course, but this is not specific to the infinity. I'd even say
that most problems in programs using floating point are *not* due
to infinities. If one wants to solve problems for the unwary user,
one should no longer allow the extended precision, one should treat
a cancellation as an exception and so on.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)