ES Decimal status

Mike Cowlishaw MFC at
Fri Sep 12 23:55:02 PDT 2008

> >>>>      Conversion from number to decimal is precise and will round 
> >>> Conversion of number to decimal is not precise.
> >> I chose my words carefully :-)
> >>
> >
> > I agree that decimal has a precision greater than number, but you said
> > that "Conversion from number to decimal is precise" without 
> > In the case of a deterministic conversion rather than a measurement, I
> > think it is quite unclear to use the term "precise" in this context
> > (as opposed to "repeatable" or "reproducible"), and I don't think that
> > the spec should express it in that way.
> This was just my summary.  When people see Decimal(1.1) produces
> 1.100000000000000088817841970012523m, they are likely to react "boy
> that's... um... precise".

:-).  'correctly rounded' would be a good way to describe it.
> >>> I'm also not sure whether the round-trip property covers all NaNs
> >>> (preserving payload), denormal, or unnormal values.
> >>
> >> NaN payloads should be preserved (decimal has quite a few more bits).
> >>
> >> The results, however, wouldn't preserve the "normalness" (or lack
> >> there of) of the original input.
> >
> > Thanks for the clarification. Does IEEE 754r (or the ES3.1m 
> > profile of it) specify that NaN payloads shall be preserved in a way 
> > round-trips?
> My understanding is that IEEE 754r merely encourages the payloads to
> be preserved, but I haven't looked recently.  Whether we decide to go
> beyond the requirements of the specification is up to us.

IEEE 754-2008 could only go as far as using Shoulds for propagation of 
payloads, because of the varied implementations of binary formats 
(different ways of distinguishing signaling NaNs, for example).  The 
relevant subclause is:

6.2.3 NaN propagation
 An operation that propagates a NaN operand to its result and has a single 
NaN as an input should produce a
 NaN with the payload of the input NaN if representable in the destination 

 If two or more inputs are NaN, then the payload of the resulting NaN 
should be identical to the payload of 
 one of the input NaNs if representable in the destination format. This 
standard does not specify which of the
 input NaNs will provide the payload. 

 Conversion of a quiet NaN from a narrower format to a wider format in the 
same radix, and then back to the
 same narrower format, should not change the quiet NaN payload in any way 
except to make it canonical.

 Conversion of a quiet NaN to a floating-point format of the same or a 
different radix that does not allow the
 payload to be preserved, shall return a quiet NaN that should provide 
some language-defined diagnostic

 There should be means to read and write payloads from and to external 
character sequences (see 5.12.1).


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Es-discuss mailing list