ES Decimal status

Sam Ruby rubys at
Thu Sep 25 07:50:47 PDT 2008

On Thu, Sep 25, 2008 at 10:24 AM, Mike Cowlishaw <MFC at> wrote:
> OK, and also liorean says:
>> I'm of the opinion that decimal128 and binary64 should behave
>> identically in as many areas as possible.
> That's a valid model.  I suppose I see strings and decimals as being
> 'closer' in concept, and in both "what you see is what you get".  But for
> arrays, I see the problem.  In that case 'reduce to shortest form, that is
> strip trailing zeros, might be the right thing to do for decimals used as
> array indices.  That function is in Sam's implementation (it's called
> 'reduce').

Reduce is subtly different.  Decimal.reduce(1000m) produces 1e+3m.  I
believe that what is desired is that foo[1e+3m] be the same slot as
foo["1000"].  But as Brendan clarified yesterday, I think that's only
necessary for decimal values which happen to be integers which contain
16 digits or less (16 digits integers being the upper bound for
integers which can be exactly stored using a binary64 floating point

> Brendan summed up:
>> Ignoring === as faux eq, the only issue here is d.toString() for decimal
> d: should it preserve scale and stringify trailing zeroes and funny
> exponents?
> Are there any other cases like array indices where toString of a number is
> used in a way such that "1.000" is materially different than "1"?
> Certainly toString could reduce, and there could be a differently-spelled
> operation to produce the 'nice' string, but the principle that toString
> shows you exactly what you have got is a good one.  (And it would be
> goodness for ES to behave in the same way as other languages' toString for
> decimals, too.)
> In particular, when dealing with currency values, the number of decimal
> places does correspond to the quantum (e.g., whether the value is cents,
> mils, etc., and similarly for positive exponents, it indicates that one is
> dealing in (say) $millions).
> If the 'business logic' calculates a value rounded to the nearest cent
> then the default toString will display that correctly without any
> formatting being necessary (and if formatting were applied then if the
> business logic were later changed to round to three places, the display
> logic would still round to two places and hence give an incorrect result).
>  In short: the act of converting to a string, for display, inclusion in a
> web page, etc., should not obscure the underlying data.  If there's some
> path in the logic that forgot to quantize, for example, one wants to see
> that ASAP, not have it hidden by display formatting.

The issue is that ToString is the basis for both toString (the method)
and the way that operations such as array's work.  My intuition is
that business logic also rarely requires scientific notation for small

I believe that we have a solution that everybody might not find ideal,
but hopefully can live with, which I will outline below with examples:

typeof(1m) === "decimal"
1.1m === 1.10m
(1.10m).toString() === "1.10"
(1e+3m).toString() === "1000"

Additionally, there will be another method exposed, say toSciString,
which will produce a value which will round trip correctly, using
scientific notation when necessary.

> Mike

- Sam Ruby

More information about the Es-discuss mailing list