Re: "Built upon 754"
I agree with most of what you said and am neutral on the rest, and I apologize for loose terminology.
I was the one who suggested several years ago that not just 1788 but also 754 needs two "values" +Overflow and -Overflow, with the property that multiplying either by zero gives zero. The bit patterns I would use would be those of the current maximum finite values.
I would leave the Infinities because in some situations they are useful, and not the same as the Overflows.
If I were designing 754 (with the massive benefit of hindsight, and with the understanding that many people disagree with many of my ideas) I would also include two "values" +Underflow and -Underflow, using the bit patterns of the smallest subnormals. I would leave two representations of zero defined to be semantically equivalent, because replacing them with a single unsigned zero slightly complicates circuitry which may hurt performance for little benefit. I would recommend that software never print or care about the sign of a zero.
("Values" is in quotes because clearly these bit patterns represent sets of values. Of course so do most floating-point values. With separate Underflows, zero should be the inverse - a set of two bit patterns representing one value, instead of one bit pattern representing a set of values rounded to it.)
While I was at it, I would define NaNs to use the uppermost non-hidden significand bit to distinguish Signaling from Quiet NaNs (I think all existing implementations do that) but the opposite of most - a 1 would mean Signaling and a 0 would mean Quiet. That would mean that regardless of the precision, setting all bytes of "uninitialized" variables and array elements would be a negative Signaling NaN, so using an uninitialized value would trigger an exception and help find bugs.
Other than that, I'm pretty happy with what's in 754, but might would add a few things.
I am still waiting patiently for the time machine I ordered years ago to be delivered !
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
All these opinions are of course just mine, not my employer's.
Lee Winter ---2016-02-02 04:15:51 PM---On Tue, Feb 2, 2016 at 3:27 PM, Ian McIntosh <ianm@xxxxxxxxxx> wrote: > 1788 has needs that are prov
From: Lee Winter <lee.j.i.winter@xxxxxxxxx>
To: Ian McIntosh/Toronto/IBM@IBMCA
Date: 2016-02-02 04:15 PM
Subject: Re: "Built upon 754"
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