Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Table 4 proposal version 0.2...



On Thu, Mar 22, 2012 at 1:00 PM, Dan Zuras Intervals
<intervals08@xxxxxxxxxxxxxx> wrote:
>> Date: Thu, 22 Mar 2012 11:28:46 -0500
>> Subject: Re: Table 4 proposal version 0.2...
>> From: Lee Winter <lee.j.i.winter@xxxxxxxxx>
>> To: stds-1788@xxxxxxxxxxxxxxxxx
>> . . .
>>
>> But we know that under any vintage of 754 the mechanisms that produce
>> the 754 values called "infinities" do not produce true mathematical
>> infinity, but are artifacts of the finite-ness of the internal
>> representation.  All of the 754 mechanisms for producing a 754
>> "infinity" are really overflows.  That includes division by "signed
>> "zero", which is not a true mathematical zero, but is really an
>> underflow.

>        I'm sorry Lee, this is just not so.

Mindful of your vast expertise in the 754 development process, my
position is unchanged and will remain so in the face of arbitrarily
large amounts of aristotelean conflict.  I find only reason
persuasive.

>        From 754-2008, Clause 7.3 "The divideByZero exception shall be
>        signaled if and only if an exact infinite result is defined for
>        an operation on finite operands."

Disregarding the massive effort involved in producing and extending
the FP standard, what it SAYS is not always what it MEANS.

But I'll bite.  Does the term "exact Infinite result" that you quoted
refer to a 754-standard "infinity", which I would describe as an
overflow, or does it refer to a mathematical infinity such as Cantor's
aleph-one?

This question is key to the issue that is not copied into the above
quotations, that being a representable value that is greater than all
real numbers.  AFAICT no version of 754 has such a standard-defined
representable value.

For example, if x=REALMAX for some 754 format, then the expression
y=2*x is going to produce a 754 "infinity" in that format.  Clearly
the value of y should not be interpreted as a value greater than all
real numbers.

>
>        And from Clause 7.4 "The overflow exception shall be signaled
>        if and only if the destination format's largest finite number
>        is exceeded in magnitude by what would have been the rounded
>        floating-point result were the exponent range unbounded.
>        . . . and the inexact exception shall be signaled."

Not sure how this portion of the standard bears on the question of
interpreting 754 "infinites".  As I understand the standard the values
with exponent=all_ones and mantissa=all_zero, i.e. a 754 "infinity",
are produced when the overflow trap/exception/event is disabled and
the calculation proceeds.  So I consider that section of the standard
moot with respect to this discussion.

>        Whether you want to call it a "true mathematical infinity"
>        (whatever that means) or not is up to you.  But there are 2
>        ways of getting there.

OK, let define the term "true mathematical infinity".

1.  It is not a number.  Thus it could be encoded as a NaN.

2.  It is not the overflow of a finite representation.

3.  It is larger than any representable number, including overflow.

4.  It is larger than any real number.

5.  Most of the definitions of mathematical infinity with which I am
familiar are based on unbounded sequences.  The essence of the concept
of mathematical infinity is that unboundedness.

Then let's talk about ways of getting there.  There are two kinds of
calculation that can produce a y754 "zero".  The first kind is always
an underflow, thus inexact. There are many examples of such
calculations, both in the basic operations and in the functions.
Flush-to-zero is appropriate in many, probably most, calculations, but
there are nooks and crannies where the ability to distinguish
underflow from zero is critical.  IMHO interval arithmetic is one of
those nooks.

(Digression where is the 754 flag/mode that prevents flush to zero,
preferring subnorm_min over a fake zero?  The 754 exceptions are quite
ponderous in comparison with such a hardware mode flag).

>        However, zero really IS a "true mathematical zero" if there
>        ever was one.

Hardly.  As I understand it signed zeros are the left-overs from the
"three zeroes" proposal which suggested a pair of signed underflows
plus a true mathematical zero.

>  And there are both exact & inexact (underflow)
>        ways of getting there too.

There is only one way that I know of to calculate a true mathematical
zero in 754-compliant arithmetic.  That method involves an add/sub
operator and a pair of operands with identical exponent and mantissa
fields and odd parity over the three signs involved.  The result of
such a calculation is a true mathematical zero.  In 754 that result is
mapped not to any zero, but to 754 "positive zero".

All other calculations that I know of that produce a 754 "zero" are
actually underflows of a non-zero result.  Did I miss something?

The kludge about having 754 +0 and -0 compare as equal does not
indicate that they represent the same position on the number line --
so they do not represent the same number.  Their multiplicative
inverses are as far apart as one can get -- overflows of opposing
sign.

If 754's signed zeros were true mathematical zero then the
multiplicative inverse would be a NaN rather than an overflow because
there is no mathematical value that represents the result of
evaluating an expression with true zero in the denominator other than
a warning/error/abort procedure.

See what I mean?

Lee Winter
Nashua, New Hampshire
United States of America