[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: New approach to annex D of the 754-R proposal.
Vincent Lefevre wrote:
On 2007-06-21 22:34:11 +1000, Peter Henderson wrote:
Signed infinities and signed zeros are inextricably linked to each other.
One is the mirror image of the other. The problems in assigning a sign to
exact infinity are exactly the same as those of assigning a sign to zero.
No, I recall that +0 = -0, but +Inf != -Inf.
I am not saying it is. But assigning a sign to a zero that occurs for
f(x) at y, assigns a sign to the infinity resulting from 1/f(y). If the
rules proposed for assigning signs to zero are followed, then a sign is
assigned to the infinity that occurs when the reciprocal of the function
is evaluated. This is already what the standard requires for a function
such as 1/(x-1). At 1, this evaluates to +infty, even though the limit
as x tends to 1 does not exist in the affinely extended real numbers.
What is important is that in a sequence of floating point calculations
involving addition, subtraction, negation, division and square root, if
an infinity occurs internally, but the limit at the end is finite as the
critical point is approached, then assigning either sign to the infinity
will give the correct result, i.e. the limit as the critical point is
approached.
Also, the value -0 of sqrt(-0) makes some sense since on the
real numbers, sqrt(0) = 0, but choosing -Inf for a function
f(x) = 1/sqrt(x) on x = -0 doesn't make any sense.
It seems to me sqrt(-0) should have been defined to be +0, precisely to
avoid this. I have not been able to find a reference giving the reason
-0 was chosen for sqrt(-0).
Contrary to the case of 0, the sign on the infinity is not just
additional information. It is really part of the value, and one
has a total order on the numbers:
-Inf < neg reals < 0 (includes -0 and +0) < pos reals < +Inf.
The situations my proposal attempts to deal with are exceptional
condition, which is indicated by returning an infinity, something a
programmer can test for if continuing with infinity arithmetic is not
suitable.
Consider functions behaving in a manner similar to 1/(x*sin(1/x)), i.e.
that rapidly switch between large positive and negative values as x
tends to the limit point. There may be good reason to perform a
comparison near or at the limit point, but if such a comparison is to
make sense, the branch in the calculation that occurs must lead to the
desired result, no matter what sign is chosen for the infinity. If this
is not the case, then the programmer needs to check for infinity and
take the appropriate action. Since such functions are likely to
generate overflows or NaN's as they approach the limit point, this will
probably be necessary anyway.
For a function that is a candidate for inclusion in a mathematical
library, the more likely behaviour is that similar to 1/(x-1), i.e. the
function tends to +infinity when approached from one direction and
-infintiy when approached from the other. In such a case, the choice of
a sign for infinity will switch the point at which the sign change
occurs between one of two adjacent floating point numbers. But again,
performing a comparison near such a point requires care by the very
nature of the function near the point in question..
Regards,
Peter Henderson