ES Decimal status

Sam Ruby rubys at intertwingly.net
Fri Sep 12 16:53:03 PDT 2008


On Fri, Sep 12, 2008 at 7:01 PM, David-Sarah Hopwood
<david.hopwood at industrial-designers.co.uk> wrote:
> Sam Ruby wrote:
>> On Fri, Sep 12, 2008 at 4:02 PM, David-Sarah Hopwood
>> <david.hopwood at industrial-designers.co.uk> wrote:
>>> Sam Ruby wrote:
>>>> Description of ES 3.1m decimal support
>>>>
>>>>      number and decimal are distinct primitive data types.  The
>>>>      former is based on IEEE 754 binary 64 floating point, the latter
>>>>      is based on IEEE 754r decimal 128 floating point.
>>> [...]
>>>>      Conversion from number to decimal is precise and will round trip.
>>> Conversion of number to decimal is not precise.
>>
>> I chose my words carefully :-)
>>
>> http://en.wikipedia.org/wiki/Accuracy_and_precision
>
> I agree that decimal has a precision greater than number, but you said
> that "Conversion from number to decimal is precise" without qualification.
> 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".

Independent of how it is described, do you or anybody see any specific
results in the following that seems inconsistent with ECMAScript:

http://intertwingly.net/stories/2008/09/12/estest.html

Any other tests I should add?

>>> 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 interpretation/
> profile of it) specify that NaN payloads shall be preserved in a way that
> 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.

> --
> David-Sarah Hopwood

- Sam Ruby


More information about the Es-discuss mailing list