Revisiting Decimal (generic algorithms)

Allen Wirfs-Brock Allen.Wirfs-Brock at
Fri Jan 16 11:16:14 PST 2009

Returning to  Brendan's original question...

The problem I brought up at the Kona meeting was that the Decimal proposal did not consistently enable the writing of functions that implement generic numeric algorithms.  By this I mean algorithms that can be applied to either Number or Decimal arguments and produce a result that is of the same type as its inputs for example:

function add(a,b) { return a+b};
// ok in Kona proposal, add(1M,1M)==> 2m; add(1.0,1.0)==>2.0  (binary)

function max3(a,b,c) {return Math.max(a,b,c)}
// not generic in Kona proposal, max3(1m,2m,3m) ==> 3 (not 3m)
// no generic Math functions so user must explicitly code either Math.max or Decimal.max

function fuzz(a) { return a + 0.1}
//not generic in Kona draft, fuzz(1m) ===> 1.10000000000000008881784197001... (but see below)
//Kona spec. uses binary floating point for all mixed mode operations

The second case is fixable with some work by making the Math functions all be generic.

Sam says the third case is a bug in the Kona spec. whose fix had already been agreed upon at the Redmond meeting.  The fix, as I understand it, is that mixed mode arithmetic should be performed using decimal operations. However, that does not address my concern.  With that fix in place, the results of fuzz(1m) would be something like 1.1000000000000000888178419700125232338905334472656250m (<-- note "m").  That is because the literal 0.1 would be lexed as a Number (ie, binary floating point) literal, stored as a binary approximation, and that binary approximation would be dynamically converted to the decimal floating point equivalent of the binary approximation by the add operations.

This problem cannot be fixed simply by tweaking the coercion rules.  It probably requires that numeric literals be treated as generic values that are only interpreted situationally as either binary or decimal values in the context of a particular operations.

The design details of the integrations of multiple numeric data types (potentially not just Number and Decimal) and questions such as whether and how a dynamically typed language like ECMAScript should support such generic algorithms will have long lasting impact on the usability of the language.  My perspective in Kona, when we talked about Decimal, was that these are Harmony scale issues that must be carefully thought through and that they should not be prematurely and irrevocably resolved as a consequence of an accelerated effort to include Decimal in ES3.1.


>-----Original Message-----
>From: es-discuss-bounces at [mailto:es-discuss-
>bounces at] On Behalf Of Brendan Eich
>Sent: Friday, January 09, 2009 2:34 PM
>To: Waldemar Horwat; David-Sarah Hopwood; Sam Ruby
>Cc: es-discuss
>Subject: Re: Revisiting Decimal
>Sam's mail cited below has gone without a reply for over a month.
>Decimal is surely not a high priority, but this message deserves some
>kind of response or we'll have to reconstruct the state of the
>argument later, at probably higher cost.
>I was not at the Redmond meeting, but I would like to take Sam's word
>that the "cohort/toString" issue was settled there. I heard from Rob
>Sayre something to this effect.
>But in case we don't have consensus, could any of you guys state the
>problem for the benefit of everyone on this list? Sorry if this seems
>redundant. It will help, I'm convinced (compared to no responses and
>likely differing views of what the problem is, or what the consensus
>was, followed months later by even more painful reconstruction of the
>state of the argument).
>The wrapper vs. primitive issue remains, I believe everyone agrees.
>On Dec 4, 2008, at 2:22 PM, Sam Ruby wrote:
>> 2008/12/4 Brendan Eich <brendan at>:
>>> Sam pointed that out too, and directed everyone to his test-
>>> implementation
>>> results page:
>>> Indeed we still have an open issue there ignoring the wrapper one:
>>> [Sam wrote:] I think the only major outstanding semantic issue was
>>> wrapper
>>> objects; apart from that, the devil was in the detail of spec
>>> wording.[End Sam]
>>> No, the cohort/toString issue remains too (at least).
>> With a longer schedule, I would like to revisit that; but as of
>> Redmond, we had consensus on what that would look like in the context
>> of a 3.1 edition.
>> From where I sit, I find myself in the frankly surreal position that
>> we are in early December, and there are no known issues of consensus,
>> though I respect that David-Sarah claims that there is one on
>> wrappers, and I await his providing of more detail.
>>> /be
>> - Sam Ruby
>Es-discuss mailing list
>Es-discuss at

More information about the Es-discuss mailing list