Re: YES P1788/M0029.02:Level3-InterfaceOnly, *BUT*
On Fri, Dec 30, 2011 at 9:30 AM, Michel Hack <hack@xxxxxxxxxxxxxx> wrote:
> Lee Winter replied:
>> > I suppose you mean two infinities of the same sign. Infinities may
>> > indeed be the result of containing overflow, but they can also simply
>> > mean "unbounded".
>>
>> What IEEE-754 operation produces an "unbounded" result from numeric
>> inputs? AFAIK there are none.
>
> Division of finite by zero yields infinity without raising overflow.
The statement above is ambiguous because the terms zero and infinity
have distinct meanings in mathematics and
floating point. IEEE-754 requires that division of a numeric value by
underflow yields overflow. They just use the misleading terms signed
zero and infinity for the values underflow and overflow.
But in mathematics division by zero does not yield infinity. First of
all infinity is not a value. It is an abstract concept. And it is
not part of R. But most importantly mathematical division by a
mathematical zero does not have a result because it is undefined in
mathematics.
> This is arithmetic in R* -- extended reals.
No, it is arithmetic over IEEE-754 values, thus two levels aleph less
than the extended reals. Many people _call_ the IEEE-754 extended
number line R*, but that does not mean the IEEE-754 number line _is_
R*.
> It is true that 754 does
> not have a concept of "unbounded", as it deals with individual numbers.
> A given number is finite or infinite, but only a set can be unbounded.
I believe there is no such thing as a marthematical number that is
mathematically infinite. The term "number" denotes an entity with a
specific numeric value and there is no number that corresponds to a
mathematcially infinite value.
The IEEE-754 value with maximum exponent and zero mantissa denoted as
IEEE-754 infinity is not a number. In fact it is a NaN with specific
utility within the IEEE-754 arithmetic.
> In any case, we are talking about 1788, which does have the concept
> of unbounded.
Not if the underlying arithmetic is IEE754. See Prof. Rump's
submission of a few weeks ago.
It would be useful to support unbounded values within 1788. But that
would require an extension to the IEEE-754 arithmetic to support true
mathematical infinity as opposed to overflow.
Note that the Hansen&Walster interval arithmetic proposal contains
just such an extension to the underlying number line including a true
mathematical zero and true mathematical infinities.
> Intervals ARE sets of finite numbers. (Cf. Motion 3)
Numeric intervals are composed of finite numbers. Non-numeric
intervals will include things other than finite numbers. But
implementation on the full IEEE-754's arithmetic requires that the
underlying number line include overflow and underflow and exclude
mathematical zero and mathematical infinity (unbounded).
>
>> > Decorations should tell these cases apart. (In 754
>> > it is the overflow flag that does the job -- unfortunately globally.)
>>
>> By the term "overflow flag" do you mean the overflow exception?
>
> Setting the overflow flag is the result of the 754 default action for
> the overflow exception. The flag and the exception are related but
> not the same. But I could just as well have said "overflow exception"
> because a non-default handler could in fact set a local flag that is
> attached to the result, just as 1788 decorations are. In fact, some
> numeric packages do just that (e.g. Mike Cowlishaw's DecNumber).
Yes, but overflow exception handling is a fairly ponderous process.
It is based on an "out of band" representation, which is incompatible
with sane interval arithmetic. The IEEE-754 exception exists to
support fragile systems that cannot cope with the limits of the
underlying arithmetic. Many mathematical systems assume that they are
working in R when in fact they are working on something finite in both
magnitude and precision, not even as powerful as the integers, much
less the reals. Any time such fragile systems encounter the limits of
the underlying arithmetic they have to deal with the situation as an
exception to the premises of the math they want to implement.
Division by zero, underflow, overflow, and nonsense expressions (NaN)
are all problems that fragile systems cannot handle "in band".
The special IEEE-754 values provide a mechanism to internalize the
handling of the the exceptional situations by providing a
representation of the exception in a well defined manner.
The 754 overflow flag itself is awkward to deal with because it is
sticky. One must explicitly clear the flag before beginning any
operation whose result one wants to protect. And even with a full
exception handler there is a limited ability to handle exceptional
values. For example, an overflow exception handler is passed an
argument representing the actual result value, but with the exponent
reduced by a constant amount, thus rendering the result representable.
But that kludge does not generalize. It suffices for most of the
operations specified in IEEE-754, but if the magnitude of the overflow
exceeds the extra range provided by the adjustment constant, the
actual value cannot be obtained by the exception handler.
IMHO it is far better to design 1788 to handle those exceptions as a
matter of course than to require users of 1788 to provide their own
kludges to handle the limits of 1788.
> As for Siegfried Rump's Dec 5 posting: I did not get it. I lost access
> to stds-1788 from Nov 23 through Nov 28 and have no posts dated Nov 23
> through Dec 2, but lots of Dec 3 posts; no Dec 4 but a couple of Dec 5.
> I had asked whether I had missed anything, but got no reply, and the
> listserver's index function does not work. I see now that the archive
> serves that function (but requires web access), and found Siegfried's
> posting; I can also check what I missed...
That paper is relevant to these topics as a more realistic (and more
robust) alternative to the approach based on the assumption that
intervals are composed of elements taken from the extended reals.
However, the basis for many of these issues is the proper
interpretation of terms used in 754. In particular the 754 infinity
and zero need closest scrutiny to determine their actual meaning. I
submit that they are drastically distinct from mathematical infinity
and mathematical zero.
Lee Winter
NP Engineering
Nashua, New Hampshire
United States of America