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.
Allen
>-----Original Message-----
>From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
>boun...@mozilla.org] 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.
>
>/be
>
>On Dec 4, 2008, at 2:22 PM, Sam Ruby wrote:
>
>> 2008/12/4 Brendan Eich <bren...@mozilla.com>:
>>>
>>> Sam pointed that out too, and directed everyone to his test-
>>> implementation
>>> results page:
>>> http://intertwingly.net/stories/2008/09/20/estest.html
>>> 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@mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
