[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Zeroes and infinities
Peter Henderson wrote:
Thorsten Siebenborn wrote:
A rogue comment:
[...]
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.
What exactly yields the example of one case 0^0 == 1 in regard of
the question what NaN^0 should be ? And 0^0 == 1 is not just a
"feeling", it fulfills the valuable binominal theorem in case of 0.
As for your "Brr...", you are by no means alone in your attitude to
the idea that NaN^0 = 1.
For good reasons.
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.
But I am not talking about Infinity. I am talking about the result
of the *number* one divided by *number* zero. It seems to me that
you have substituted automatically "infinity" for 1/0 when I haven't
talked about the number "infinity" at all (I have said that 1/0 isn't
an infinity).
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.
Ah, you are substituting the numbers by limit operations, so in your
opinion IEEE 754 means effectively:
f(-0.0) = lim f(x) for x->-0
f(0.0) = lim f(x) for x->+0
And that f(number) must therefore return NaN if the number has no
single limit ? Is that correct ?
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.
Well, I haven't taken a course in measure theory yet, probably
because I am too dumb for such complicated things, but you
can certainly answer all my humble inquiries if I don't understand
something...
One thing -- in school I learned that numbers are
something like "fields", containing an inverse element for
multiplication and therefore the operation of division. Are these new
extended real numbers fields, too ? Is therefore
the operation "/" comparable with the operation division in a field ?
While FP numbers are crude approximations of the fields R and C
(not obeying the distributive law), they are intended to model them,
right ?
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.
Thank you. Another member already pointed out the idea of Fraley
and Walther, but didn't know when or where it was publicized.
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.
I doubt that the infinities or signed zeros are in any case better
suited or easier to understand than ov's and un's. The payoff between
rise of complexity and advantages may be a valid counterargument, but
I am not yet convinced because I miss experiences with such a system.
More below.
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? [Explanation]
I translate:
You think that I think that FP numbers are intervals. But the "only
interpretation that works" is that every FP number represents itself
when you already mentioned that infinity is a result of a
limiting operation.
A few lines later you suddenly tell us that for +0/-0 a "partial
exception" must be made because in that case the "only working
interpretation" ceases to function. You are also
claiming that both values represent zero and that they
should compare equal.
But you are *also* claiming that they are in fact limits
according to the direction the variable uses because it is the
only reason how the use of 1/+0 and 1/-0 with different results
can be explained. In fact you have summarized all the problems
I encounter with signed zeroes
- While you seem to jumble limit and number together, they have
very different meanings. A result of a *number* can be totally
different from the result of a *limit*. A *limit* can have
two values on the real axis, a *number* only one.
A function may have both identical limits from both sides of a
function, but an undefined value at the point.
f(x) = exp(-(1/x^2)) x is element of R
f(0) = undefined
lim(f(x), x->+0) = 0
lim(f(x), x->-0) = 0
There may be even a limit for divergent series (defined as Abel sum)
having no equivalent number result !
1 - 2 + 3 - 4 + .... = 0.25
because
f(x) := 1/(1+x)^2 = 1 - 2x + 3x^2 + ....
Abel sum = lim(f(x), x -> 1-)
- There is only one value *zero* and besides that plus and minus zero
*cannot* both represent the same number because they violate the
fundamental identity that for x == y => f(x) == f(y)).
If one of them is "zero", what does the other one represent and why
on earth are they compared as equal ?
- While all these problems can be defended, one crucial problem
remains: The hiding of implementation details concerning the signed
zero. It is deliberately cumbersome to find out if an argument is
0.0 or -0.0 in the mainly used programming languages. It tells the
programmer: "Don't care about that". Together with the alliance to
eradicate flags and traps it may cause strange and irregular
sign problems (if the +-infinity is eradicated in a denominator).
And that is not a freak-case; it was the very reason I stumbled
over the signed zero because my program (Java) did exactly this.
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.
Of course I assume you are a standards committee member ? That's fine,
because if someone tells me that he is a compiler writer, a FP hardware
designer or a library routine author indicating that I am not one, I
will gladly ask him all my questions. He is an expert and he will never
ever tell me stupid errors and totally wrong answers because that
would be really embarassing for a pro, wouldn't it ? Especially (just
in case)
if the amateur realizes it and points it out.
I, in contrast, as an amateur may tell as many errors as I like because
I have much to learn yet.
Regards,
Thorsten