Re: Table 4 proposal version 0.2...
On Thu, Mar 22, 2012 at 4:17 PM, Michel Hack <mhack@xxxxxxx> wrote:
> Lee Winter wrote:
>> 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?
>
> It refers to one of the ends of the affine completion (two-point
> compactification) of the Reals -- ONE of the many different mathematical
> infinities.
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 lots of calculations that produce
a number too large to represent in 754 formats, but none that produce
a true infinity, whatever definition you use to distinguish true
infinity from "mere" overflow.
Of course if some true transcendentals such as e, tau, or pi showed up
in some symbolic form, maybe encoded in a NaN, I'd be worried.
> Cantor's infinite Ordinal and Cardinal numbers are some of
> the others; the projective (one-point) compactification (most useful for
> Complex numbers) is another, and more closely related -- and there are
> others still. Besides, Aleph-one might not be the one relevant to the
> Reals anyway, or rather, it depends on whether your axioms include the
> Continuum Hypothesis or not.
>
> The problem here is that the 754 representations of Zero, Infinity
> (and also NaN) are overloaded.
754's zero is definitely overloaded. In fact I would say it is ambiguous.
NaN is arguable, especially in the wider formats, because there tend
to be "enough" of them for almost all tractable problems.
A comment about the ambiguity of 754's overflow/infinity. Only
infinity-as-inverse-of-zero causes problems. Once the ambiguity of
zero v. underflow is resolved the ambiguity of infinity v. overflow is
automatically resolved.
> For results, the flags can be used to distinguish the meanings,
I understand how to distinguish underflow from zero, but how do I
distinguish overflow from infinity via flags or exceptions?
> but inputs are considered exact by definition.
That definition is part of the problem. If I pass in an ambiguous
value such as a 754 underflow/zero or a 754 overflow/infinity, which
way do I expect it to be interpreted? I know what the standard says
and a lot of what it means, but implementations vary (!), so despite
the standard, I am still easy to confuse when attemptingmulti-platform
rigor.
>
> That was precisely the motivation for my IFP exploration mentioned
> in my earlier posts today.
I've read your exposition twice. It is a bit more ambitious than I
expected given the inclusion of uncertain signs, but I can see the
logic behind that expansion. I need to read it again and work out
some of the omitted examples before I comment.
Did you look at the possibility of a exactness flag or tag as opposed
to an embedded bit or two?
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'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.
Lee Winter
Nashua, New Hampshire
United States of America