It is not explicitly stated in 754, but clear from 754 Definitions 2.1.24 and 2.1.25, from 754¤3.2, and the definition of the arithmetic operations, that a "floating-point number" (that is, any floating-point datum that is not NaN) *is* a member of R^*.

Of course, non-754 systems can provide such functions.

What about a hardware that is IEEE 754-2008 compliant, but an environment on top of it (compiler and/or operating system) that is not IEEE 754-2008 compliant?

Page vii, line 45, need a reference to the system of Rump Page ix, line 27, "IEEE 754" should be either "IEEE 754-1985" or "IEEE 754-2008" (or "IEEE 754-1985 and 754-2008").

(BTW: Jonathan Goldberg explained to me the difference between "IEEE 754", "IEEE Std 754" and "IEEE Std 754-2008", and I think I have it right, above.)

IEEE 754 did not reject this requirement.

Many people _call_ the IEEE-754 extended number > line R*, but that does not mean the IEEE-754 number line _is_ R*.

The main disadvantage would be incompatibility with 754, but 754 users could benefit from it too so maybe it might become part of a future 754-201x?

LIST=STDS-754 >, < mailto:LISTSERV@LISTSERV.IEEE.ORG?

All of the 754 mechanisms for producing a 754 > >> "infinity" are really overflows.  

Note: Here, IEEE 754 is IEEE 754-2008 (currently the latest version of the IEEE 754 standard).

Note: Here, IEEE 754 is IEEE 754-2008 (currently the latest version of the IEEE 754 standard).

The right solution would be to "fix" the IEEE 754 implementation.

This abstract set (754 Table 3.1) is where one should, and 754 does, define the FP computational operations, independent of representation issues for the most part.

D1. "754-conforming system".

Interchange representations for non-754 interval types, and on non-754 systems, are implementation-defined.

Interchange formats for non-754 interval formats, and on non-754 systems, are implementation-defined.

Thus it is immaterial how IEEE-754 defines log(0).

Interchange formats for non-754 interval formats, and on non-754 systems, are implementation-defined.

We were going to have additional requirements > > for joint compliance with 1788 and 754 *if* a 754-type was supported, > > but I thought it was going to be possible to be 1788-compliant without > > using 754-types. > > > > I realise that the "Scope" is (I think) not really normative, but this > > should (if *unintended*) probably be rephrased, e.g. > > > > ...and at least one fully-specified numeric type > > such as an IEEE-754/2008 floating-point type.

LIST=STDS-754 >, < mailto:LISTSERV@LISTSERV.IEEE.ORG?

We were going to have additional requirements >>> for joint compliance with 1788 and 754 *if* a 754-type was supported, >>> but I thought it was going to be possible to be 1788-compliant without >>> using 754-types. >>> >>> I realise that the "Scope" is (I think) not really normative, but this >>> should (if *unintended*) probably be rephrased, e.g. >>> >>> ...and at least one fully-specified numeric type >>> such as an IEEE-754/2008 floating-point type. > > I have the same objection as Michel.

Interchange formats for non-754 interval formats, and on non-754 systems, are implementation-defined.

But in such a case, I'm not sure that it could claim conformance to IEEE 754 (while we are in the context of IEEE 754).

Maclaren Date: Sun, 2 Jan 2011 10:15:55 -0500 (EST) Re: Conflicts between C standard and 754-2008 From : Rick Regan Date: Sat, 1 Jan 2011 19:35:25 -0500 (EST) Re: Conflicts between C standard and 754-2008 From : Michel Hack Date: Sat, 1 Jan 2011 17:47:41 -0500 (EST) Re: Conflicts between C standard and 754-2008 From : Michel Hack Date: Sat, 1 Jan 2011 17:44:27 -0500 (EST) Re: Conflicts between C standard and 754-2008 From : N.M.