🚀 go-pugleaf

In article <1990May31.023244.12359@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>IEEE 754 section 5.6 says
>	When rounding to nearest, conversion from binary to decimal and back to
>	binary shall be the identity as long as the decimal string is carried
>	to the maximum precision specified in Table 2, namely 9 digits for
>	single and 17 digits for double.
>In other words, print a binary floating-point number, then read it back in:
>you'll get the original bit pattern, so long as you use enough digits and use
>the default rounding mode.

Digression:  No.  You have to use EXACTLY the right number of digits.
(Assuming that the quotation of section 5.6 is the complete binding
specification for this issue.)  If you use too many, it might be rounded
differently on re-reading.

>To satisfy this requirement, -0.0 and 0.0 must have
>different external forms, since their internal forms differ.

For IEEE 754, yes.

>the wording for strtod() (ANSI C 4.10.1.4) provides for the
>distinction between 0.0 and -0.0:
>	If the subject sequence has the expected form, [it, minus any sign,]
>	... is interpreted as a floating constant....  If the subject
>	sequence begins with a minus sign, the value resulting from the
>	conversion is negated.
>Thus on an IEEE 754 host, strtod("-0.0",NULL) computes 0.0 and then negates it,
>yielding -0.0.

Yes, it seems that (ANSI C plus IEEE 754) yields essentially this result.
(Digression:  it seems legal for a perverse implementation to reverse the
signs just for the values of 0.0 and -0.0.)
However, this result is only required for two-way conversions in a single
implementation.  It still is not necessary for a parser at compile-time
to distinguish -0.0 from 0.0.

inews fodder
inews fodder
inews fodder
inews fodder
inews fodder
-- 
Norman Diamond, Nihon DEC     diamond@tkou02.enet.dec.com
Proposed group comp.networks.load-reduction:  send your "yes" vote to /dev/null.