Re: Motion P1788/M0029.01: Level-3-interface-only --- discussion period begins
On Sat, Nov 19, 2011 at 9:33 AM, Nate Hayes <nh@xxxxxxxxxxxxxxxxx> wrote:
>> However they also support an interchange medium at the binary level. One
>> can't specify this for a "general" T assuming only what's in the
>> Explicit/Implicit motion 19, but for each 754-conforming type we can
>> easily define its interchange format (should it be "interchange type"?) as
>> follows:
>> - Nonempty xx=[xlo,xhi] is represented by bits(xlo) + bits(xhi).
>> - Empty xx is represented, say, by bits(NaN) + bits(NaN).
>> Here bits(x) is the bit-string of an F-number x (as described in the 754
>> standard), and + means concatenate.
>>
>> The resulting bit-string, call it interchange(xx), is to exist at a level
>> above details like whether the machine is big- or little-endian, so we
>> ignore those.
>>
>> One must decide various things such as: Is bits(x) canonicalized, e.g. is
>> 0 always represented as +0? And are payloads of NaNs preserved on writing
>> and reading? But basically the idea is simple.
>
> This sounds good to me (I like Dan's suggestion, as well).
>
> Nate
>
> P.S. On a related tangent:
>
> Dan and Michel have noted in the past that there are currently no
> standards for propagating NaN payloads. So when it comes time for a motion
> to make some of these decisions about a standard interchange format, for
> Empty xx we may wish to consider a scheme something like this:
> bits(NaN) + bits(NaN) // No P1788-specific payload
> bits(NaN) + bits(payload) // P1788-specific payload
> bits(payload) + bits(NaN) // P1788-specific payload
> where bits(payload) is a bit-string reserved for any P1788-specific payload
> data (e.g., a bare decoration represented as an integer). The actual
> payloads of the NaNs can then be reserved for use according to existing (and
> possibly future) IEEE 754 standards. This way we potentially save ourselves
> from being at odds or cross-purposes with IEEE 754 implementations and
> standards.
This strikes me as far too complicated. There is no need to
distinguish NaN values from numeric values. Given a 754-formatted
datum there are only three values that need to be represented; the
sign, the exponent, and the mantissa (SEM). The fact that those
fields encode a zero, a denormalized number, a normal number. an
overflow, or an non-numeric value is not relevant to the problem of
how to encode the datum for transmission to the recipient. Thus it
appears to me that we need only be concerned with representing the
fields of the SEM format. The more the standard deals with the
complexities of the meaning of the encoded values the less useful the
standard will be.
At a more detailed level, the "payload" of a NaN value is fully
enclosed within the mantissa field. In fact it includes all but a
couple bits which are used to distinguish NaNs from overflows and
quiet from signalling NaNs. So the idea of extracting the "payload"
and representing it separately is kind of pointless.
On that note I recommend that the values representing the SEM fields
be encoded as simple unsigned integers. Such an approach will not
harm communication between 754-based systems but will enhance
communication involving non-754-based systems. I prefer that the
integers be represented in decimal because it is the default base that
trivializes the necessary IO routines.
Lee Winter
NP Engineering
Nashua, New Hampshire
United States of America (NDY)