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

*To*: <scanon@xxxxxxxxx>*Subject*: RE: Payload length and interpretation in IEEE Std 754-2008*From*: Charles Stevens <charles.stevens@xxxxxxxx>*Date*: Fri, 29 Apr 2011 11:43:34 -0600*Cc*: <forieee@xxxxxxxxxxxxxx>, IEEE 754 <stds-754@xxxxxxxxxxxxxxxxx>, Robert Karlin <bobkarlin@xxxxxxxxxxxxxxxxx>, William Klein <wmklein@xxxxxxxxxxxxx>*Importance*: Normal*In-reply-to*: <7B8EEAF9-3DB6-4161-8B26-500C3DE81B2D@apple.com>*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-W5257CD1588F587E2BAD7A5839A0@phx.gbl>,<F0F25B52-F0CA-44DA-AC1F-C8D2177A10A4@apple.com>,<COL112-W615E7BB488715FCC5D4ED4839A0@phx.gbl>,<7B8EEAF9-3DB6-4161-8B26-500C3DE81B2D@apple.com>*Sender*: stds-754@xxxxxxxx

Excellent! Thanks again! Missed that one. -Chuck > Subject: Re: Payload length and interpretation in IEEE Std 754-2008 > From: scanon@xxxxxxxxx > Date: Fri, 29 Apr 2011 10:39:30 -0700 > CC: forieee@xxxxxxxxxxxxxx; stds-754@xxxxxxxxxxxxxxxxx; bobkarlin@xxxxxxxxxxxxxxxxx; wmklein@xxxxxxxxxxxxx > To: charles.stevens@xxxxxxxx > > 6.2.1 NaN encodings in binary formats: > > "If the first bit of the trailing significand field is 0, some other bit of the trailing significand field must be non-zero to distinguish the NaN from infinity." > > - Steve > > On Apr 29, 2011, at 10:37 AM, Charles Stevens wrote: > > > Forgot which way the "signaling-vs.-quiet" thing went. > > > > For binary formats, in all three cases under consideration, the exponent field is all-bits-on. > > > > Infinity has all zeroes in the trailing significand field. > > Quiet NaN has a 1 in the leading bit of the trailing significand field; the remainder of that field is the payload defined by the implementor. > > Signaling NaN has a 0 in the leading bit of the trailing significand field; the remainder of that field is the payload defined by the implementor. > > > > What's the distinction, then, between a canonic infinity in that representation and a *signaling* NaN with a payload of zero? > > > > Is there a specification somewhere that says that the payload may not be zero? > > > > -Chuck Stevens > > > > > Subject: Re: Payload length and interpretation in IEEE Std 754-2008 > > > From: scanon@xxxxxxxxx > > > Date: Fri, 29 Apr 2011 10:12:27 -0700 > > > CC: forieee@xxxxxxxxxxxxxx; stds-754@xxxxxxxxxxxxxxxxx; bobkarlin@xxxxxxxxxxxxxxxxx;wmklein@xxxxxxxxxxxxx > > > To: charles.stevens@xxxxxxxx > > > > > > On Apr 29, 2011, at 10:01 AM, Charles Stevens wrote: > > > > > > > The way the COBOL rules are stated now, the result of this action is a positive quiet NaN with a payload of ZERO. The payload might or might not be modified later. > > > > > > > > What I have since realized is that the bit-pattern that results, in a BINARY interchange format (but not a DECIMAL format), is exactly the same as that of a positive infinity. We have "class tests" for the two infinities and for a NaN, and COBOL doesn't "do" infinity arithmetic, so all three are considered non-numeric in COBOL rules. > > > > > > If you're following the IEEE-754 recommended practice, the resulting bit pattern is *not* a positive infinity. In particular, you say "the result of this action is a positive *quiet* NaN with a payload of ZERO". Clause 6.2.1 reads: > > > > > > "A quiet NaN bit string should be encoded with the first bit (d1) of the trailing significand field T being 1." > > > > > > So, if you follow the recommended practice, your "quiet NaN with a payload of ZERO" looks like this: > > > > > > sign: 0 > > > exponent: 111…11 > > > significand: 100….00 > > > > > > and does not have the same encoding as positive infinity. To be fair, this is recommended, not required, and COBOL does not need to follow this convention. But it would be wise to do so. > > > > > > - Steve > > > > |

**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

**Re: Payload length and interpretation in IEEE Std 754-2008***From:*Stephen Canon

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

**Re: Payload length and interpretation in IEEE Std 754-2008***From:*Stephen Canon

- Prev by Date:
**RE: Payload length and interpretation in IEEE Std 754-2008** - Next by Date:
**Re: Payload length and interpretation in IEEE Std 754-2008** - Previous by thread:
**Re: Payload length and interpretation in IEEE Std 754-2008** - Next by thread:
**Re: Payload length and interpretation in IEEE Std 754-2008** - Index(es):