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

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

Well, the issue here is this.  
In the latest proposals for the upcoming standard for COBOL, we have a construct SET CONTENT OF <IEEE-float)> TO POSITIVE-NAN. 
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.   
Now, I can always change "zero" in the rules to "a nonzero value defined by the implementor", but the problem with that is that from the COBOL standard's perspective, "the implementor" is the implementor of the COMPILER, which may have nothing to do with the implementor of the PLATFORM, particularly if the compiler is designed to run on multiple platforms. 
What I was hoping to come up with was a nonzero value to which the payload could be set WITHOUT stepping on the platform-implementor's toes, to indicate that the result was INDEED a NaN, but the payload was undetermined (because that particular payload COULDN'T be specified by an implementor), and for which the value was the same regardless of the format.  
For DECIMAL formats, the payload appears to be interpreted as (or interpretable as) an integer (3.5.2, bottom of page 10).  I don't see a similar specification for BINARY formats in 3.4 or 6.2.1. 
And it does concern me that the set of values permitted for a payload in, say, a Binary128 is MUCH larger than the set of values permitted in a Binary32, when it appears that the implementor would be dealing with the same set of conditions -- and thus the same set of payload values -- in both cases.  Why?  Eight-million-plus possibilities ought to be enough for ANY implementor! 
    -Chuck Stevens  
> 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
> Chuck,
> 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.
> Yours,
> Dan
> > 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