On Mar 29, 2:12 pm, Steve <stephentyr...@gmail.com> wrote:
> >From the IEEE-754 (1985) / IEC559 (1989) spec:
>
> "3.3. Extended Formats
> The single extended and double extended formats encode in an
> implementation-dependent way the sets of values in 3.1 subject to the
> constraints of Table 1."
>
> Those requirements actually boil down to: precision of at least 64
> bits, exponent range of at least [-16382, +16383], exponent width of
> at least 15 bits, and a total encoding width of at least 79 bits.
> These requirements are obviously satisfied by the Intel 80 bit format
> (indeed, the standard was written with that format in mind).

Coincidentally, the minimum requirement of each extended format is an
exponent range just greater than the next power of ten and precision
equal to the encoding width of its base.

Whatever consideration was paid to Intel behind the scenes, it wasn't
mentioned in the standard. To me it sounds like certain numbers are
convenient to everyone. Intel did make the unusual decision to waste
the extra bit rather than extend range or precision.

> The standard further requires that correctly rounded basic operations
> be provided for any arithmetic type.  The x87 FPU hardware provides
> said operations for the 80-bit (with some library support for certain
> conversions).
>
> The C++ spec says that is_iec559 is "true if and only if the type
> adheres to IEC 559 standard."  It does *not* say "is a basic format of
> the IEC559 standard".  The 80-bit type adheres to the IEC 559 standard
> as an extended type, and therefor is_iec559 correctly returns true for
> that type.

It would also correctly return true if double implemented extended-
single. GNU simply sets "is_iec559 = has_infinity && has_quiet_NaN &&
has_denorm == denorm_present." As specified, is_iec559 is redundant
and misleading. If it were restricted to basic types, it would
usefully identify encodings.

As it is, sizeof(long double) == 16 on my system, making Intel 80 look
a lot like quad precision. One workaround would be to parameterize on
numeric_limits<>::digits, max_exponent, and min_exponent. But that's
tedious and doesn't guarantee bit order, as any permutation of quad
still implements extended double.

> Note that none of this changes in the 2008 revision of the IEEE-754
> document.  The 80-bit format satisfies the requirements of an extended
> format associated with the binary64 format, and as such "adheres to
> the standard".

If I thought my implementation were buggy, I wouldn't have posted
here. I think the standard is defective.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 31, 9:51 pm, Potatoswatter <pot...@gmail.com> wrote:

> It would also correctly return true if double implemented extended-
> single

Rightly so.

> GNU simply sets "is_iec559 = has_infinity && has_quiet_NaN &&
> has_denorm == denorm_present." As specified, is_iec559 is redundant
> and misleading.

If the GNU tools indeed define is_iec559 that way for all formats on
all machines, I would argue that there is bug in the GNU
implementation; IEC559 places requirements not only on the available
values in a format, but also requires that operations are correctly
rounded, that the four basic rounding modes are supported, that edge
cases produce specified results, and that certain means to handle
exceptional conditions are provided.  For example, the somewhat
obscure 16 byte "double-double" (or "dirty-double") head-tail format
should not have is_iec559 == true despite the fact that it has
encodings for infinity, quiet NaN and denormals, as operations are not
correctly rounded (in typical implementations).

> If it were restricted to basic types, it would usefully identify
encodings.

As I understand it, the intent is not to uniquely identify encodings,
but rather to indicate that a type supports all the standardized
IEC559 features to allow users to take advantage of them in a more
portable fashion.  If you want unique type identifiers, I think you
really want the standard to define a header like <cstdint> that
provides typenames along the lines of "float32_t", "float64_t" and
"float128_t" that are explicitly bound to the IEEE-754 (2008)
binary32, binary64, and binary128 types (and probably names for the
new decimal floating-point types as well).


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

My implementation reports numeric_limits<long double>::is_iec559 == true for
the Intel 80-bit format. Intel 80 is not defined by or related to IEC 559; an
alternative 128-bit format is.

Perhaps one source of this issue is the grandfather clause in C99   F.2/1
footnote 307:

     Extended     is IEC 60559  s double-extended data format. Extended refers to
both the common 80-bit and quadruple 128-bit IEC 60559 formats.

This would seem to be trying to change the very content of IEC 559!

However, to put this in context, note that C99 provides the user with much
less information about the implementation. From   F.1/1:

 An implementation that defines _ _STDC_IEC_559_ _ shall conform to the
specifications in this annex.

There is one macro and no other compliance information. If Intel 80 were
considered non-compliant, it would preclude its use entirely on IEC 559
compliant C implementations. C++ does not have this issue: the user queries FP
types for compliance individually. I believe this justifies an exception to
the trend of deferring numeric decisions to the C spec.

Moreover, no C++ standard explicitly refers to C FP at all. The definition of
is_iec559,   18.2.1.2/52, says simply

 52 True if and only if the type adheres to IEC 559 standard.

This is ambiguous enough to allow Intel 80 if you consider IEC 559's provision
for arbitrary formats adhering to the principles and features of the
explicitly defined formats. But that interpretation would make is_iec559
meaningless: other members of numeric_traits<> already describe the features
of a FP type that would contribute to compliance besides binary format. So
there is really no other information for it to convey.

 - Cheers,
 David

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

>From the IEEE-754 (1985) / IEC559 (1989) spec:

"3.3. Extended Formats
The single extended and double extended formats encode in an
implementation-dependent way the sets of values in 3.1 subject to the
constraints of Table 1."

Those requirements actually boil down to: precision of at least 64
bits, exponent range of at least [-16382, +16383], exponent width of
at least 15 bits, and a total encoding width of at least 79 bits.
These requirements are obviously satisfied by the Intel 80 bit format
(indeed, the standard was written with that format in mind).

The standard further requires that correctly rounded basic operations
be provided for any arithmetic type.  The x87 FPU hardware provides
said operations for the 80-bit (with some library support for certain
conversions).

The C++ spec says that is_iec559 is "true if and only if the type
adheres to IEC 559 standard."  It does *not* say "is a basic format of
the IEC559 standard".  The 80-bit type adheres to the IEC 559 standard
as an extended type, and therefor is_iec559 correctly returns true for
that type.

Note that none of this changes in the 2008 revision of the IEEE-754
document.  The 80-bit format satisfies the requirements of an extended
format associated with the binary64 format, and as such "adheres to
the standard".

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]