Re: True and false infinities and zeros (was: Table 4 proposal...)
On Thu, Mar 22, 2012 at 5:13 PM, Michel Hack <mhack@xxxxxxx> wrote:
> 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:
No there are not.
> conversion of a literal <inf>
Assignment/ or nitialization of a variable with a special value does
not PRODUCE that value. It merely propagates it. The test form of
infinity is an infinity as much as the numeric form is an infinity..
> division of nonzero by zero
As previously discussed, 754 does not have value that means zero. It
has two values that are named signed zeros, but in practice are signed
underflows. And those values are overloaded/ambiguous as previously
described.
N.B., in my lexicon the unverse of underflow is overflow. The only
quibble on that subject is subnormals (originally denormals) whose
inverses are also overflow.
> and various arithmetic operations with infinite arguments.
754 does not have infinite arguments. It has overflows.
> 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.
Look at the rest of the standard. In what sense is a 754 "infinity"
infinite? Not in any that I understand. It does not represent "the
rest of the number line". In fact I think there is a declaration that
every representable non-NaN FP value represents a single numeric value
rather than a range of such values.
>> 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.
OK. Do you have a preference re internal or external?
>
>> 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 would require a lot of close attention to get right and probably
isn't viable in software.
> That however risks progressive and
> perhaps pathological widening, and needs more thought...
Agreed. But it looks like a rabbit hole, so I ain't going down it.
>> 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!
Sure. In a bounded representation the bounds and the midpoint
accessors would probably suffice..
Lee Winter
Nashua, New Hampshire
United States of America