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

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

Well, I can only speak for our implementation, but one of the reasons for leaving payload undefined in the standard was to leave open the possibility for imaginative architectural use. The programming model implied by the standard is simple sequential, which is one of its problems; modern machines are anything but sequential. So, for example, when the platform has fanned a single loop across ten  thousand CPUs, the user might find it of use to know which CPU produced the NaN, as opposed to which one got in trouble using it much later. If the implementer would also like to suggest that the source of the problem was line 543 of file frob.c on the 123,456th iteration then eight million possibilities start to look rather small.

We have finessed the compiler vs. platform difference by defining NaN as an executable operation in hardware, where "user requested" is one of the error codes and the rest of the info in the resulting payload refers to the point at which the operation was executed. Systems lacking such an operation can use the standard mechanism for for dealing with compiler vs. platform issues, namely by adding the value to the platform's runtime system.

As I recall, the group once considered at least defining a set of error codes, but it quickly became apparent that no single set would be convenient for all present architectures (much less future ones), and a union superset approach would both inject glaring target dependencies into the standard (like "extended") while being unextendable for the needs of future architectures.

For COBOL, may I recommend taking the same approach that Unix does with its OS error codes: define an opaque, platform dependent error code enumeration and operations to extract an such an enum value from a NaN and to construct a new NaN with such an extracted value; also define a function taking one of the enum values and producing a string, for use in diagnostics.

Dan is right about patent; you need not worry about our efforts in that vein. As I understand it, it's not possible to patent a format anyway, only specific methods and apparatus to produce and use data in that format. Consequently our patent (assuming it makes it out of triage) is for the hardware our architecture uses to generate a NaN, which has nothing to do with either IEEE754-2008 or anything COBOL might want to do.

Ivan Godard

On 4/29/2011 10:01 AM, Charles Stevens wrote:
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