Re: "Built upon 754"

[Lee Winter <lee.j.i.winter@xxxxxxxxx>]

On Tue, Feb 2, 2016 at 3:27 PM, Ian McIntosh <ianm@xxxxxxxxxx> wrote:

1788 has needs that are provided by some other but not all other floating-point designs:
- It needs representations of +Infinity and -Infinity, or some alternate way of indicating those are the bounds.

There is a clarity of terminology issue here.  The values that '754 calls infinity do not represent an unbounded sequence.  They represent a bound whose value is descended from a value too large to represent.  The accurate name for those values is overflow.

Both Lincoln and Lao Tze focus on the difference between what a thing is called and what a thing is.  Lincoln's example is the question "How many legs does a dog have it you call a tail a leg?".  The typical response of "Five" triggers the correction "Four -- calling a tail a leg does not make it a leg."

Similarly calling an unrepresentably large value infinity does not make it infinity.  Calling it overflow is naming it accurately.  (Technically it is a value desceended from overflow)

- It needs the ability to round towards either +Infinity or -Infinity or preferably both.
There are other floating-point formats that provide both of those (eg, Intel 80-bit double extended). There are also recent (eg, Cell SPU single precision, with no Infinities) and many older formats (eg, IBM hex) that do/did not.

While 1788 mentions the possibility of the bounds being a 754 format, it doesn't require that, so isn't exactly "built on 754". Instead it's "built on several features 754 provides".

There are other things 1788 does not need, like having exceptions set flags, not 754, and possibly trap as in most systems using 754. Implementations may benefit from the ability to suppress traps, which is not provided by some alternate formats (eg, IBM hex). It also isn't helped by 0 times Infinity = NaN, when what it needs is 0 times Infinity = 0 because an Infinity bound represents some almost infinite finite number.

The same terminology problem afflicts the otherwise meaningless negolism "signed zero".  In fact '754 does not have signed zeros.  It has values that are CALLED signed zeroes, but the name does no dictate the meaning.  Rather the meaning dictates an accurate name of underflow.  (Technically a value descended from underflow).

The reality is that '754 has NO representation that MEANs zero, which would correspond to what is decribed as "the origin of the number line". For reference see the Three Zeros proposal to the '74 working group.  The best I have been able to get out of Prof. Kahan was that said proposal was voted down by the committee.

My conclusion is that the committee was willing to tolerate two zeros so that series near the origin would have sensible properties, but was not willing to tolerate three zeros because none of them believed there could possibly be a reason for such nonsense.

Why were such perverse and misleading names used in '754?  They allow the "sale" of the '754 proposals to idio^H^H^H^hmanagers who have no clue about numerical rigor, but who would resists adopting a numerical system that contained error values such as overflow and underflow.  Renaming such values turned them from red flags into "salable" features.

The real tragedy is the confusion (in '754-ese) of "zero times infinity -> zero", when the operation under '754 (in non-deceptive-ese) is actually "underflow times overflow -> NaN".  Mapping "underflow times overflow -> underflow" is pure nonsense.  It only makes sense after one has drunk the presentation/sales kool-aid of infinity as a numeric value and distinguishable "signed zeros".

In some future revision we might want to be explicit about what floating-point features 1788 needs or benefits from, with 754 mentioned only as a good example of formats providing those features.

Honest terminology is at the very top of my list of features for a future 1788 as well as for a future 754.

Lee Winter

Nashua, New Hampshire

United States of America