True and false infinities and zeros (was: Table 4 proposal...)
Lee Winter replied to me:
> Yes, but a "true" infinity. Now what terminating calculation under
> 754 produces such a result? AFAICT there are none in 754's basic
> operations or functions.
There are several: conversion of a literal <inf>, division of nonzero by
zero, and various arithmetic operations with infinite arguments. This is
of course all under the assumption of "exact inputs", which (as Lee points
out later) is itself an issue. But that's what the standard specifies.
> I understand how to distinguish underflow from zero, but how do I
> distinguish overflow from infinity via flags or exceptions?
The fact that Inexact is not being reported -- same as for zero/underflow.
It is of course not really practical except in debugging mode, because
of the need to reset the sticky flag before every operation. But we are
talking about the principle here.
> Did you look at the possibility of a exactness flag or tag as opposed
> to an embedded bit or two?
Sure -- by extending the format to a bigger size. The point of the
exercise was to see what could be done without changing format size,
and basically to provide a format that is as compatible as possible
with normal use. The exercise becomes easier when the representation
is already a structure with spare bits, as with decNumber or mpfr.
> Did you consider adding openness indicators which allow true, exact,
> unsigned zero (AKA the origin) to be distinguished from +0 and -0
> because (-0, +0) is an efficient interval representation for true
> zero?
I was considering individual numeric datums, not intervals. It would
indeed be useful to distinguish open and closed intervals, and with
IFP numbers this becomes possible in principle, but does require a
few additional conventions. An exact endpoint would denote closure
on that side, and an inexact endpoint would denote openness, but the
actual bound would have to be 1 ulp away from the nominal value in
order to preserve containment. That however risks progressive and
perhaps pathological widening, and needs more thought...
> I've often wondered whether an interval arithmetic taking something
> like the current P1788 proposals, replacing any FP return values
> with singleton intervals (but not necessarily singletons in the
> gnarly cases) would be much simpler to specify for the purposes of
> standardization.
Now there's an interesting idea! It would solve a number of quandaries
raised by trying to define mid and rad for strange formats. Ultimately
however we need SOME functions that return plain FP results, or we could
never leave the Interval world!
Michel.
---Sent: 2012-03-22 22:40:11 UTC