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.
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
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
> To: charles.stevens@xxxxxxxx
> CC: stds-754@xxxxxxxxxxxxxxxxx; bobkarlin@xxxxxxxxxxxxxxxxx;
> From: forieee@xxxxxxxxxxxxxx
> Subject: Re: Payload length and interpretation in IEEE Std
> 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
> > 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
> > 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 -
> > 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
> > ry point after the first digit/bit. Is this clearly
specified somewhere? =
> > -Chuck Stevens =