[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Zeroes and infinities
Thorsten Siebenborn wrote:
A rogue comment:
After Vincent has formerly raised some objections and
giving me some headaches about properly defining functions
in the IEEE 754 space and then reading the comments and thinking
about the problem:
I think the whole system is rotten.
With the reason that NaN^0 should be 1 because the former
argument must be any kind of number: (1.0/0.0)^0 = 1
Brrr...
There are some general principles used in the standard that cover pretty
well all cases for just about any real valued function of a real
variable, at least in the default round-to-nearest mode. These
principles require NaN^0 return NaN. In some cases, there is a feeling
that an exception to these principles is more convenient or more
intelligible. 0.0^0.0 = 1.0 is one of these cases. As for your
"Brr...", you are by no means alone in your attitude to the idea that
NaN^0 = 1.
1/0 is not a number. It is *not* infinity.
Infinity can be incorporated into an arithmetic system in a consistent
manner, just as the square root of minus 1 can be. The problem is that
how this is done depends on the application and that you end up having
to sacrifice some of the rules of arithmetic. The IEEE standard takes
the approach that infinity is the result of a limiting operation and the
rules follow from the algebra of limit theorem for real-valued functions
of several real variables. That is why 1/+0=+infty, 1/-0=-infty and
0/0=NaN. In the last case, there is no single limit, it depends on how
it is approached. Hence 0/0 does not have a defined numeric result and
is considered as a domain error, requiring special handling by the
program. Should you ever take a course in advanced theory of
integration (usually called measure theory), among the first things
defined is the extended real numbers, which adds +infty and -infty,
together with appropriate the rules of arithmetic. In this case
+/-infty*0 = 0, as the area of a rectangle with a side of length zero is
zero, no matter how long the other side. infty-infty is still
undefined. Similarly, in complex analysis, an unsigned projective
infinity is always introduced when dealing with algebraic functions.
Infinity isn't
even or odd (or for the arguments sake, if it is interpreted
as a number too great to know, the oddness is unknown
and therefore undefined).
You are not the only one to balk at this idea. I'd be very surprised
and disillusioned if the IEEE committee ever adopted this view. It is
just bad.
I don't like the signed zero either. Zero *has* no sign.
See my reply below.
So apart from the standard I ask myself why on earth noone
has thinked about positive and negative underflows aka
infinitesimals and only one zero.
They have. When the original IEEE 754 standard was being written, there
was a proposal by Fraley and Walther, to have special overflow and
underflow symbols. It is described in "Analysis of Proposals for the
Floating-Point Standard", W. J. Cody, Computer, pp,. 63--68, v. 14, no.
3 March, 1981. Presumably the actual proposal is given in ACM SIGNUM
Newsletter, special issue on the Proposed IEEE Floating-Point Standard,
October 1979.
From the discussions originating from your original post, and my own
musing along similar lines concerning the interpretation of NaN's, I
have the impression this idea doesn't gain you much, at the expense at a
complex and hard to understand system. What always seems to happen is
either the conditions resolve themselves in one or two operations, or
the set of numbers they encompass quickly grows to become meaningless,
essentially a NaN. In other words, not much different to what already
happens with the IEEE infinities and signed zeros.
They have. If you really insist on sticking with this idea, then the
only sensible approach is to use interval arithmetic. Of course, you
need some standard computer arithmetic to implement is, e.g. ieee 754.
That is the main reason for the rounding modes. A letter was recently
posted pleading for the standard to mandate better support for interval
arithmetic. In particular the author was asking for per operation
rounding modes to be mandated and for programming languages to provide a
means of expressing the rounding modes of the basic operations.
.
.
.
The branch cuts which are the whole reason Kahan implemented
this abominable negative zero are equally good solvable with
infinitesimals.
Why was negative zero included? I suspect the process was something
like this. The sign bit is there anyway, but in the case of zero it is
doing nothing useful. So either insist it is always zero or just ignore
it. However, if you interpret floating point values, as I suggest
below, then you can propogate the sign of zero through arithmetical
operations, in a manner that is useful. There are two use cases that
come immediately to mind. The first is underflow, where a little bit of
information can be preserved and perhaps be used to rescue the
situation, hence the rule 1/(-0) = -infty and 1/(-infty) = -0. This
idea also follows from the inclusion of signed inifinity. Note that
early on, it was proposed to include an unsigned projective infinity as
well. The second use case is for branch cuts, where it allows you to
give the limits of the function as it approaches the branch from either
side.
As for your overall bemusement, I feel it arises from being seduced by
certain views concerning the interpretation of the floating point
values. e.g. "a floating point number represents an interval". The only
interpretation that works is this: A floating point number stands for
itself. The interval interpretation doesn't work in most cases because
the interval that results from an operation is not the same as the
interval corresponding to the floating point operation. i.e.
[x-e,x+e]+[y-e,y+e] gives [(x+y)-2e, (x+y)+2e], not [(x+y)-e,
(x+y)+e]. In other words, if you want to adopt this interpretation, you
have to use full-blown interval arithmetic, where the intervals are
explicitly stored and propagated.
The idea that a floating point number stands for itself applies equally
for infinity. Infinity does not represent an overflowed value. That
infinity is the result of an operation where overflow occured and is
returned by the rounding operation. i.e. just like any other result, an
overflow must be rounded to something. If the rounding mode is round
towards zero, infinity only occurs as a result of an exact operation.
The case of signed zero is a partial exception to this principle. Both
plus and minus zero represent zero, and all operations producing a
finite number follow this principle. In fact the only cases where the
sign of zero has a substantial effect are 1/0 and copysign(x,0). In the
first case, 1/+0 equals +infty and 1/-0 equals -infty. These results
are exact and hence uneffected by the rounding mode. As for
copysign(x,0), it too as defined, i.e. copysign(x, +0) = |x| and
copysign(x, -0)=-|x|, follows the same principles. The way to think of
the sign of zero is that it is an auxiliary flag, that preserves some
history as to to the origin of th ezero in the first place.
In producing results such as +/-infty and +/-0, the following principle
is used. For any real valued function f(x,y) of two real variables x and
y, f(x,y) is the limit as (u,v) tends to (x,y), of f(u,v). In the case
one of x or y is +/-0, the limit is taken as the variable approaches
zero from above or below, as appropriate. If the limit is zero, and it
is approached from above, f(x,y) = +0, if it is approached from below,
f(x,y) = -0. To obtain the floating point value, apply rounding with
the current rounding mode. If the limit does not exist, then (x,y) is
not in the function's domain and so return NaN. Should x or y be NaN,
propagate the NaN. Where this rule is not used, it is because it is
inapplicable. For example, for +/-0 != x == y != +/-infty, x-y is
defined to be +0, except when round to -infty is in effect. sqrt(-0) is
defined explicitly to be -0, as the 0 cannot be approached from zero and
so the limiting principle cannot be used. For the comparison operations,
this limiting approach cannot be applied, so the standard ordering of
the extended real numbers is used, and +0 and -0 are treated as the
same, since they both represent zero.
If the sign of zero bothers you, ignore it. It will only cause you
problems if an overflow occurs and does not resolve itself, in which
case you will end up with +/-infty or NaN, or if you use copysign, in
which case you should be paying more attention anyway. Of course, I am
assuming you are not a compiler writer, a floating-point hardware
designer, a library routine author or a standards committee member.
Regards,
Peter Henderson