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. |
The currently-proposed specification is that the payload is transferred intact, with trailing bit or digit truncation of the payload as needed if the capacity of the receiving data item does not allow for a payload of that size. If the payload is other than a "left-justified integer" in the sending operand, this might make the payload value in the receiving NaN. I'm trying to avoid that.
Clause 5.4.2 seems to allow this for NaNs, applying the rules of Clause 4 to imply that the end result is rounded if need be. For MOVE in COBOL, the only rounding mode is roundTowardZero, so that could be interpreted as applying what is currently proposed for COBOL.
I can always propose deleting "POSITIVE-NAN" from the keyword list for SET CONTENT OF, but that leaves what happens to a NaN on a long-to-short convertFormat operation unspecified if that's what the (compiler) implementor uses for the MOVE statement in this case.
> To: charles.stevens@xxxxxxxx
> CC: stds-754@xxxxxxxxxxxxxxxxx; bobkarlin@xxxxxxxxxxxxxxxxx; wmklein@xxxxxxxxxxxxx; forieee@xxxxxxxxxxxxxx
> From: forieee@xxxxxxxxxxxxxx
> Subject: Re: Payload length and interpretation in IEEE Std 754-2008
> Date: Fri, 29 Apr 2011 08:39:31 -0700
> 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 =