[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Payload length and interpretation in IEEE Std 754-2008


        I'm not sure where you are going with this observation
        but it must be admitted that, as far as the utility of
        payloads is concerned, NaNs have fallen far short of
        our goals for them over the years.

        They were orginally intended to contain diagnostic
        information beyond the fact that something invalid has
        happened.  Had there been a portable trap mechanism
        they might have fulfilled that goal.  As it is, the
        only times they have been useful have been limited to
        narrow applications on single implementations.

        Therefore, as a standards body, I think the best you
        can do is leave that small utility in place.  You will
        not be able to define anything for Cobol as a whole &
        get it to work.

        As for Ivan's attempt to patent something in this area,
        I wouldn't worry too much about that.  For the above
        reasons as much as anything else.



From: Charles Stevens <charles.stevens@xxxxxxxx>
To: IEEE 754 <stds-754@xxxxxxxxxxxxxxxxx>
CC: Robert Karlin <bobkarlin@xxxxxxxxxxxxxxxxx>,
 William Klein <wmklein@xxxxxxxxxxxxx>
Subject: Payload length and interpretation in IEEE Std 754-2008
Date: Fri, 29 Apr 2011 08:31:41 -0600

The payload seems to be provided to allow the implementor to specify diagno=
stic information about the operation that produced it=2C and I don't find m=
uch about how it should be encoded=2C what its limits are=2C and whether th=
ose limits are the same regardless of the width of the format.  

It also seems to me that it would be illogical for the implementor to speci=
fy payloads in=2C say=2C a decimal128 item that could not=2C on capacity gr=
ounds=2C be specified to the same degree of exactness in a binary32 item.

As I read it=2C to give two examples=2C the capacity limits (presuming a ri=
ght-justified integer) are 23 bits (numeric range 1 - 8=2C388=2C607) for bi=
nary32 and 33 digits (1 - 999=2C999=2C999=2C999=2C999=2C999=2C999=2C999=2C9=
99=2C999=2C999) for decimal128.  Even the least of these ought to provide e=
nough variations to allow the implementor to report whatever he felt was ap=
propriate.  Eight million potential "error codes" is a lot of error codes.=

It's also unclear to me how this payload value (or bit-pattern) in the trai=
ling significand is to be interpreted -- as a bit-pattern (even for decimal=
)=2C as a right-justified integer=2C as a left-justified integer=2C as a fr=
actional value=2C or as a canonic significand with the implied decimal/bina=
ry point after the first digit/bit.  Is this clearly specified somewhere? =

    -Chuck Stevens                                      =

754 | revision | FAQ | references | list archive