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

*To*: Charles Stevens <charles.stevens@xxxxxxxx>, "forieee@xxxxxxxxxxxxxx" <forieee@xxxxxxxxxxxxxx>*Subject*: RE: Payload length and interpretation in IEEE Std 754-2008*From*: Steven Hobbs <Steven.Hobbs@xxxxxxxxxxxxxxxx>*Date*: Fri, 29 Apr 2011 14:28:59 -0400*Accept-language*: en-US*Acceptlanguage*: en-US*Cc*: IEEE 754 <stds-754@xxxxxxxxxxxxxxxxx>, Robert Karlin <bobkarlin@xxxxxxxxxxxxxxxxx>, William Klein <wmklein@xxxxxxxxxxxxx>*In-reply-to*: <COL112-W253DF29EF2240683FEF09E839A0@phx.gbl>*List-help*: <http://listserv.ieee.org/cgi-bin/wa?LIST=STDS-754>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO%20STDS-754>*List-owner*: <mailto:STDS-754-request@LISTSERV.IEEE.ORG>*List-subscribe*: <mailto:STDS-754-subscribe-request@LISTSERV.IEEE.ORG>*List-unsubscribe*: <mailto:STDS-754-unsubscribe-request@LISTSERV.IEEE.ORG>*References*: <COL112-W540BDCCA00124B5C73C2AC839A0@phx.gbl>,<20110429153931.86D5F1212A0E@zuras.org> <COL112-W253DF29EF2240683FEF09E839A0@phx.gbl>*Sender*: stds-754@xxxxxxxx*Thread-index*: AcwGkoCyQEJvAtE2TH+hlKeXL+ydfQAAjjJQ*Thread-topic*: Payload length and interpretation in IEEE Std 754-2008

As someone who has just added IEEE FP to an implementation of the ANSI M language I recommend against saying much about NaNs in a language standard. All of our target platforms for ANSI M implement IEEE Std 754-1985 but almost none support IEEE Std 754-2008. IEEE Std 754-1985 only defined binary representations for floating point. It defined nothing about the payload of a NaN other than there must be at least one signaling NaN, at least one quiet NaN, and the sign bit cannot be used to differentiate between signaling versus quiet. IEEE Std 754-2008 says only a little bit more about NaNs. For decimal representation it defines a requirement that determines which payloads are quiet NaNs versus which payloads are signaling. But for binary representation it has a “recommendation” for which payloads are quiet versus signaling. (I assume this is a recommendation instead of a requirement so that existing implementations of IEEE 754-1985 that chose another quiet/signaling NaN representation could still comply with the standard.) We allow customers to move their data accessed by ANSI M between all our supported platforms. When we do arithmetic on NaNs the various platforms will modify the payloads in different ways. On some platforms even moving floating-point data can modify the bit pattern representing a NaN. The biggest issue is that quiet versus signaling is sometimes different on different platforms. Our solution was to say there is only one NaN (but it has lots of different binary representations). This one NaN works the same everywhere (regardless of its binary representation.) The IEEE FP standard requires that this one NaN never equals itself (even if two instances share the same internal binary representation.) We guarantee that if you give us a NaN as input or you do an arithmetic operation that results in a NaN then you will get one of the many binary representations of the one NaN value. If you give us a NaN generated externally and you retrieve that NaN without attempting to modify it then we do our best to avoid having the platform modify the bit pattern before we return it the external device that is the target of your retrieval. Nothing else is portable between platforms. Trapping on NaNs is not a feature of our language implementation because it is not portable. If you are willing to be platform dependent (I.e. nonportable) then we allow you to enable trapping on signaling NaNs but you can expect different platforms to give you different results. You can do arithmetic on floating point values and we can promise the results do whatever the underlying platform supports (including archaic things like extended register arithmetic) but we can never promise that all our platforms give the same bit patterns when NaNs are involved. We consider conversions between floating-point representation and other representation to be “sacrosanct” so we do not use conversions supplied by the platform but we do our own conversions with “infinite” precision. (I.e., we supply more accuracy than required by the previous IEEE 754-1985 standard.) We also do comparisons between mixed data type representations with infinite precision. All other operations are done with the accuracies supplied by the platform. If COBOL only supports decimal floating point then your language standard can promise that signaling and quiet NaNs are well defined separate classes of values; you can promise that values will be transferred between the classes in a well defined way. You really cannot easily define how operations choose between values in same class of NaN. It is best that your standard just says that choice of bit pattern for a signaling NaN and choice of bit pattern for a quiet NaN is either Implementation Defined (the implementation must document its choices) or Implementation Dependent (the implementation may make a choice without documenting it.) I recommend making it Implementation Dependent because some chip vendors have different model chips for the same architecture that transfer NaN values in different ways from each other. --Steve
PS: We also have the capability of converting a NaN in one IEEE format into another IEEE format (say, Binary128 to Decimal64) through the MOVE statement. |

**References**:**Payload length and interpretation in IEEE Std 754-2008***From:*Charles Stevens

**Re: Payload length and interpretation in IEEE Std 754-2008***From:*Dan Zuras IEEE

**RE: Payload length and interpretation in IEEE Std 754-2008***From:*Charles Stevens

- Prev by Date:
**Re: Payload length and interpretation in IEEE Std 754-2008** - Next by Date:
**Questions on data transfer and non-arithmetic handling rules** - Previous by thread:
**Re: Payload length and interpretation in IEEE Std 754-2008** - Next by thread:
**Questions on data transfer and non-arithmetic handling rules** - Index(es):