Why decimal?
On Jun 23, 2009, at 12:18 AM, Christian Plesner Hansen wrote:
I've been looking around on the web for reasons why decimal arithmetic should be added to ES. The most extensive page I could find was speleotrove.com/decimal/decifaq.html. If anyone know other good sources of information about decimal and its inclusion in ES please follow up.
Mike Cowlishaw's pages on decimal have lots of arguments for it:
www2.hursley.ibm.com/decimal/decifaq.html, www2.hursley.ibm.com/decimal
The most-duplicated JS bug in bugzilla.mozilla.org is
bugzilla.mozilla.org/show_bug.cgi?id=5856
Here's a typical naive JS user complaining that his computer his
broken because it can't calculate correct differences:
"... I typed in: 9533.24-215.10
… and here is the garbage Apple babbled back at me: 9318.139999999999"
He blamed Apple. Naive users often blame hardware for software bugs.
The strongest argument seems to be financial: binary arithmetic is approximate in a way that makes it unsuitable for financial calculations. I buy this argument in general -- I would definitely want my bank to use some form of decimal arithmetic rather than binary -- but less so in the context of ES.
Do you consider that naive user's calculator example to be
"financial"? I do not.
The problem is worse for non-experts. The experts can cope.
Anyway, decimal is not being pushed into JS at this point. At the last
face-to-face TC39 meeting, we changed direction to explore
generalizing value type support (including operators and literals if
we can) so that libraries could add first class number-like types.
Whether any new value type would be native or self-hosted, and whether
it would be included in the core standard, are issues we want to defer
until later, ideally until there are de-facto standards to codify.
The counter-argument articulated at the meeting by Sam was that it's
rare for users to download binary extensions to JS for browsers (Flash
is the only exception, and it's not primarily a JS extension). So
users won't get decimal unless it is part of the normative core spec,
so the usability bug reported as Mozilla bug 5856 won't get fixed.
I think Sam has a point; lack of a standard could be a problem. But
whatever we do about it, the committee agreed to work on value types
first. They're on the Harmony agenda.
On Tue, 23 Jun 2009 09:18:16 +0200, Christian Plesner Hansen <christian.plesner.hansen at gmail.com> wrote:
I've been looking around on the web for reasons why decimal arithmetic should be added to ES. The most extensive page I could find was speleotrove.com/decimal/decifaq.html. If anyone know other good sources of information about decimal and its inclusion in ES please follow up.
The strongest argument seems to be financial: binary arithmetic is approximate in a way that makes it unsuitable for financial calculations. I buy this argument in general -- I would definitely want my bank to use some form of decimal arithmetic rather than binary -- but less so in the context of ES. A while ago we (the v8 team) asked around within google and were unable to find anyone who would want to do financial calculations client-side.
Java/ECMAScript is not only run inside a web browser. wiki.mozilla.org/ServerJS
Personally I am entierly ambivelent to decimal.
I'd rather it was possible to do operator overloading such that decial or what ever else could be implemented natively (in a self hosting JS) but I can also accept that this (operator overloading) is unlikely to happen.
On Jun 23, 2009, at 9:28 AM, Ash Berlin wrote:
I'd rather it was possible to do operator overloading such that
decial or what ever else could be implemented natively (in a self hosting JS)
but I can also accept that this (operator overloading) is unlikely to
happen.
Au contraire, as I noted in reply to Christian -- it's on the Harmony
agenda:
Mark M. took the action to write the spec, he already posted his
operator proposal to this list, here:
I'm signed up to help Mark (as time allows, definitely in July; new
baby at home).
Do you consider that naive user's calculator example to be "financial"? I do not.
I don't know, the user doesn't say why this inaccuracy is a problem. It sounds like he's just generally unhappy that arithmetic is approximate. Decimal is approximate too. Unless the example is set in a context where we know we'll stay in base 10, such as financial, decimal arithmetic will only give you less accuracy per bit.
The counter-argument articulated at the meeting by Sam was that it's rare for users to download binary extensions to JS for browsers (Flash is the only exception, and it's not primarily a JS extension). So users won't get decimal unless it is part of the normative core spec, so the usability bug reported as Mozilla bug 5856 won't get fixed.
As far as I can see none of the reports collected under 5856 ask for decimal, what they ask for is accurate arithmetic. Decimal doesn't provide that. If people were asking for decimal arithmetic because they needed it for some particular financial or scientific application then that would be different.
I think Sam has a point; lack of a standard could be a problem. But whatever we do about it, the committee agreed to work on value types first. They're on the Harmony agenda.
Are there any other uses planned for value types than decimal?
On Jun 23, 2009, at 10:10 AM, Christian Plesner Hansen wrote:
Do you consider that naive user's calculator example to be
"financial"? I do not.I don't know, the user doesn't say why this inaccuracy is a problem. It sounds like he's just generally unhappy that arithmetic is approximate. Decimal is approximate too.
That's true at very extreme margins only! Decimal does not fail to
round power-of-five products so badly, and I think you know this.
13+ years ago, I got a bug report about this calculation:
js> 79.46-39.96
39.49999999999999
This was before we founded mozilla.org, it was about Netscape 2 or 3.
So the bug report prefigured bug 5856.
These dollars and cents calculations are quite common, and decimal
handles them correctly with full precision and no rounding errors.
Unless the example is set in a context where we know we'll stay in base 10, such as financial, decimal arithmetic will only give you less accuracy per bit.
Why are you talking about "bits" here?
Base 2 and base 5 are different, and finite precision in the latter
(or base 10) can represent numbers exactly, for which no exact
representation exists or can be rounded nicely using base 2 with any
finite precision.
As far as I can see none of the reports collected under 5856 ask for decimal, what they ask for is accurate arithmetic. Decimal doesn't provide that. If people were asking for decimal arithmetic because they needed it for some particular financial or scientific application then that would be different.
See above. I think you are missing something fundamental about the
problem reported at that bug. Decimal does fix it for the use-cases
reported there and in dups.
Are there any other uses planned for value types than decimal?
Sure: point, rational, complex, RGBA color, quaternion, .... Some of
these are esoteric, scientific programmers may care (game programmers
too). Others are pretty common on the web.
On 23 Jun 2009, at 17:59, Brendan Eich wrote:
On Jun 23, 2009, at 9:28 AM, Ash Berlin wrote:
I'd rather it was possible to do operator overloading such that
decial or what ever else could be implemented natively (in a self hosting JS)
but I can also accept that this (operator overloading) is unlikely to
happen.Au contraire, as I noted in reply to Christian -- it's on the
Harmony agenda:Mark M. took the action to write the spec, he already posted his
operator proposal to this list, here:I'm signed up to help Mark (as time allows, definitely in July; new
baby at home)./be
Awesome. I noticed that after I'd already send my previous response.
This doesn't get said enough: good work guys.
Mark's proposal is very close to something I proposed long ago, but was rejected. It has been implemented in Adobe's ExtendScript dialect, with a slight variation (instead of ['reverse+'], a second Boolean argument to the overload implementation indicates reverse operation).
Funny how things keep popping up.
Michael
I don't know, the user doesn't say why this inaccuracy is a problem. It sounds like he's just generally unhappy that arithmetic is approximate. Decimal is approximate too.
That's true at very extreme margins only! Decimal does not fail to round power-of-five products so badly, and I think you know this.
I know, and just after what you quoted I said "unless we know we'll stay in base 10". It's a fact that if you venture outside of base 10 you'll get more accurate results using k-bit binary than k-bit decimal.
13+ years ago, I got a bug report about this calculation:
js> 79.46-39.96 39.49999999999999
A single approximate calculation doesn't say anything about how the user would like arithmetic to behave generally. Using any type of floating-point numbers properly is not easy and the right solution depends on your setting. If this is dollar amounts maybe calculating with integer cents is a better solution. It's impossible to tell from one isolated calculation what the right solution is since we don't know why the inaccuracy is a problem. We can guess that maybe decimal is the solution this user is looking for. Our experience from asking around within google, and looking at the one decimal library available, says that the interest in decimal is very limited in practice.
These dollars and cents calculations are quite common, and decimal handles them correctly with full precision and no rounding errors.
In which contexts do people perform these casual dollars-and-cents calculations in JS? I would expect the vast majority of dollars-and-cents calculations to happen in the kind of setting I argued in my original mail would most likely take place on the server even if there was decimal support on the client.
Unless the example is set in a context where we know we'll stay in base 10, such as financial, decimal arithmetic will only give you less accuracy per bit.
Why are you talking about "bits" here?
To signify that I'm comparing 64-bit binary with 64-bit decimal or 128-bit ditto, but not 64-bit binary and 128-bit decimal.
As far as I can see none of the reports collected under 5856 ask for decimal, what they ask for is accurate arithmetic. Decimal doesn't provide that. If people were asking for decimal arithmetic because they needed it for some particular financial or scientific application then that would be different.
See above. I think you are missing something fundamental about the problem reported at that bug. Decimal does fix it for the use-cases reported there and in dups.
Which kind of arithmetic is appropriate depends on what your setting is. Hardly any of these bug reports give any context so there is no way to tell if decimal will solve people's problems. Here's a few dups where it definitely won't:
bugzilla.mozilla.org/show_bug.cgi?id=356566 "The Javascript modulus arithmetic has gross errors when large numbers are used "
bugzilla.mozilla.org/show_bug.cgi?id=369803 "When doing lots of small scale and translation equations I start getting rounding errors."
That's true at very extreme margins only! Decimal does not fail to round power-of-five products so badly, and I think you know this.
I know, and just after what you quoted I said "unless we know we'll stay in base 10". It's a fact that if you venture outside of base 10 you'll get more accurate results using k-bit binary than k-bit decimal.
Just to avoid confusion: when I say base 10 I mean numbers like 0.1 and 1343.41 as opposed to 1/3 and pi.
People generally expect math to work how they've been taught in school. When javascript violates their expectations, that is the very definition of a bug.
It is true that binary might be more precise for certain kinds of applications, and if it's a native machine type there's performance advantages.
These are facts that a novice programmer does not know or care about in the slightest. All they know is that even their desktop calculator can do this work properly, it must be javascript, or apple, or whatever that is broken. This is obvious to anyone that doesn't look at the world through nerd colored glasses. It's a fact so painful that microsoft even went to the trouble of pouring in an epic amount of research and development into their calc.exe so it doesn't display this broken looking behavior, as it displayed in earlier versions. A programmer might take the trouble to learn these esoteric computer facts, but end users won't.
A less informed programmer might not even notice anything is wrong, until some unsuspecting user comes across it. Depending on the programmer, they may not know how to deal with it.
And finally, it's highly likely that javascript will be used more and more on the server side in years to come, so javascript being a "client side" language no longer works as a credible excuse.
People generally expect math to work how they've been taught in school. When javascript violates their expectations, that is the very definition of a bug.
School math is accurate, there are no approximations at all. Neither binary nor decimal are accurate, both will violate people's expectations of accuracy. If you do (1.0 / 3.0) * 3.0 neither binary nor decimal give you 1.0.
These are facts that a novice programmer does not know or care about in the slightest. All they know is that even their desktop calculator can do this work properly, it must be javascript, or apple, or whatever that is broken. This is obvious to anyone that doesn't look at the world through nerd colored glasses. It's a fact so painful that microsoft even went to the trouble of pouring in an epic amount of research and development into their calc.exe so it doesn't display this broken looking behavior, as it displayed in earlier versions. A programmer might take the trouble to learn these esoteric computer facts, but end users won't.
If you're doing a calculator application you can use a decimal library. I'm not saying that decimal can't ever be useful, what I'm saying is: it's not useful enough that we want to force all implementations to include it.
And finally, it's highly likely that javascript will be used more and more on the server side in years to come, so javascript being a "client side" language no longer works as a credible excuse.
Server side JS is a different situation and much easier. On the server you control the implementation you use. Since JS lacks any way to interact with its surroundings out of the box you're already more or less forced to extend your implementation to be able to do something meaningful. If you want decimal arithmetic on the server you're free to add it, either as a library or as a native extension.
School math is accurate, there are no approximations at all. Neither binary nor decimal are accurate, both will violate people's expectations of accuracy. If you do (1.0 / 3.0) * 3.0 neither binary nor decimal give you 1.0.
D'oh! I just tried this and it actually gives 1.0 using both 32-bit and 64-bit binary arithmetic. But it's easy to construct examples where none of the systems are accurate, for instance
x = 2/3 print((0.5 + x) - x);
This gives, depending on which arithmetic system you use:
128-bit decimal: 0.5000000000000000000000000000000003 64-bit binary: 0.4999999999999999 64-bit decimal: 0.5000000000000003 32-bit binary: 0.50000006
Using school math you would expect that adding and then subtracting the same number would get you back where you started. Decimal is a counter-intuitive as binary in that respect.
Breton Slivka wrote:
People generally expect math to work how they've been taught in school. When javascript violates their expectations, that is the very definition of a bug.
Truly. The issue isn't "Why decimial?" It is "How decimal?" and perhaps "Which decimal?"
On Jun 24, 2009, at 1:49 AM, Christian Plesner Hansen wrote:
I don't know, the user doesn't say why this inaccuracy is a problem. It sounds like he's just generally unhappy that arithmetic is approximate. Decimal is approximate too.
That's true at very extreme margins only! Decimal does not fail to
round power-of-five products so badly, and I think you know this.I know, and just after what you quoted I said "unless we know we'll stay in base 10". It's a fact that if you venture outside of base 10 you'll get more accurate results using k-bit binary than k-bit decimal.
If a computation favors base 3 or base 7, you're right -- no one radix
fits all cases when precision is finite. But people have 10 fingers,
and they expect sums and differences to work the way they learned on
paper.
Your mode of argument makes it sound like each radix is equally likely
to be best, that base 10 is not privileged in everyday practice -- or
from your "k-bit binary" remark, that Shannon's ghost is whispering
"base e is best, approximate with base 2 or 3!" :-P
Most users do not know and do not care about information theory
optimality, they just want sums and differences to "work".
On 2009-06-24, at 11:08EDT, Brendan Eich wrote:
Most users do not know and do not care about information theory
optimality, they just want sums and differences to "work".
Don't most users really want rational numbers, plus a way to present
them to a certain level of precision?
On Jun 24, 2009, at 8:16 AM, P T Withington wrote:
On 2009-06-24, at 11:08EDT, Brendan Eich wrote:
Most users do not know and do not care about information theory
optimality, they just want sums and differences to "work".Don't most users really want rational numbers, plus a way to present
them to a certain level of precision?
Could be, which is why we are pursuing value types with extensible
operators and literal notation.
I have concluded that it's too late to "fix" anything by adding
decimal. It's clearly to late to change the number type from binary to
decimal. So we are going to let library authors cater to users, and
get TC39 out of this hopeless business.
On Wed, Jun 24, 2009 at 8:21 AM, Brendan Eich <brendan at mozilla.com> wrote:
I have concluded that it's too late to "fix" anything by adding decimal. It's clearly to late to change the number type from binary to decimal. So we are going to let library authors cater to users, and get TC39 out of this hopeless business.
+1
I have concluded that it's too late to "fix" anything by adding decimal. It's clearly to late to change the number type from binary to decimal. So we are going to let library authors cater to users, and get TC39 out of this hopeless business.
Sorry for being slow but I'm a little unclear on what that means. Does it mean that you're not in favor of including decimal in harmony?
2009/6/23 Brendan Eich <brendan at mozilla.com>
On Jun 23, 2009, at 12:18 AM, Christian Plesner Hansen wrote:
I've been looking around on the web for reasons why decimal arithmetic should be added to ES. The most extensive page I could find was speleotrove.com/decimal/decifaq.html. If anyone know other good sources of information about decimal and its inclusion in ES please follow up.
Mike Cowlishaw's pages on decimal have lots of arguments for it:
www2.hursley.ibm.com/decimal/decifaq.html, www2.hursley.ibm.com/decimal
I'm afraid both these links seem to have broken.
On Jun 24, 2009, at 9:58 AM, Christian Plesner Hansen wrote:
I have concluded that it's too late to "fix" anything by adding
decimal. It's clearly to late to change the number type from binary to
decimal. So we are going to let library authors cater to users, and get TC39 out
of this hopeless business.Sorry for being slow but I'm a little unclear on what that means. Does it mean that you're not in favor of including decimal in harmony?
The second message in this thread, my first reply to your head-of- thread message, said:
"Anyway, decimal is not being pushed into JS at this point. At the
last face-to-face TC39 meeting, we changed direction to explore
generalizing value type support (including operators and literals if
we can) so that libraries could add first class number-like types."
Erik Corry wrote:
2009/6/23 Brendan Eich <brendan at mozilla.com <mailto:brendan at mozilla.com>>
On Jun 23, 2009, at 12:18 AM, Christian Plesner Hansen wrote:I've been looking around on the web for reasons why decimal arithmetic should be added to ES. The most extensive page I could find was http://speleotrove.com/decimal/decifaq.html. If anyone know other good sources of information about decimal and its inclusion in ES please follow up.Mike Cowlishaw's pages on decimal have lots of arguments for it: http://www2.hursley.ibm.com/decimal/decifaq.html http://www2.hursley.ibm.com/decimal/I'm afraid both these links seem to have broken.
The content can now be found on Mike's site:
speleotrove.com/decimal/decifaq.html, speleotrove.com/decimal
- Sam Ruby
The second message in this thread, my first reply to your head-of-thread message, said:
"Anyway, decimal is not being pushed into JS at this point. At the last face-to-face TC39 meeting, we changed direction to explore generalizing value type support (including operators and literals if we can) so that libraries could add first class number-like types."
I am just as unsure of how to read that. Does "at this point" mean that it's off the table altogether for harmony or only that it's been postponed until later in the process?
On Jun 24, 2009, at 12:08 PM, Christian Plesner Hansen wrote:
The second message in this thread, my first reply to your head-of- thread message, said:
"Anyway, decimal is not being pushed into JS at this point. At the
last face-to-face TC39 meeting, we changed direction to explore
generalizing value type support (including operators and literals if we can) so
that libraries could add first class number-like types."I am just as unsure of how to read that. Does "at this point" mean that it's off the table altogether for harmony or only that it's been postponed until later in the process?
Why do you want a for-all-time declaration from me?
We can only focus on what's next. Our covenants the proscribe certain
features are few: no ES4-style namespaces (Common Lisp packages), nor
packages built on them.
If we standardize extensible value types and a decimal extension
becomes so popular it should be part of the normative core language
(as JSON is now, different kind of extension but same rationale for
making it part of the normative core), then why would we not include
decimal?
On Jun 24, 2009, at 12:13 PM, Brendan Eich wrote:
We can only focus on what's next. Our covenants the
s/the/that/
proscribe certain features are few: no ES4-style namespaces (Common
Lisp packages), nor packages built on them.
I reviewed the Harmony announcement message:
The other proscribed feature was "early binding" in the sense of
static checking that made name binding and optional type annotation
judgments when compiling, and enforced them by failing compilation.
But this is either too vague or, if taken too literally, undesirable.
For Harmony we are looking at opt-in lexical scope, which would make
free variable uses into static errors:
As this wiki page says, the syntax is not crucial, but the idea of
removing the global object from the scope chain, of having only
lexical frames, is very much on the Harmony agenda. In such an opt-in
regime, early binding is possible and may be indistinguishable from
any binding.
The other kind of "early binding" ES4 did was of standard constructor
names in the global object when used as type annotations, by
implicitly opening the intrinsic namespace. This also early-bound
method names such as charAt on a statically typed string variable, or
a string literal.
This kind of early binding of names, creating an evaluation model that
is different from the usual one for names in expressions, is really
what the Harmony message meant to proscribe. TC39 agrees now to make
any optional type annotations evaluate dynamically (implementations
may partially evaluate as an optimization).
I admit it is hard to make precise statements that ban certain areas
of extension from ever being entertained by TC39, but I think that's a
good sign that we shouldn't close our minds excessively. The main
agreements were about getting controversial ES4 ideas, which were
already being removed from ES4 (packages went in April 2008), off the
table.
Again, there is no reason for us to "ban" decimal forever. That would
be wrong on several levels, most obviously because we would
standardize a popular decimal value type library if it emerged.
On Jun 24, 2009, at 12:13 PM, Brendan Eich wrote:
On Jun 24, 2009, at 12:08 PM, Christian Plesner Hansen wrote:
I am just as unsure of how to read that. Does "at this point" mean that it's off the table altogether for harmony or only that it's been postponed until later in the process?
Why do you want a for-all-time declaration from me?
Sorry, I overreacted and changed timeframe from your "harmony" to "all- time".
For Harmony, which is also ill-defined but may mean exactly ES6, I
would be surprised if we both standardize value types and see a
decimal library become so popular it merits inclusion in the core
language.
If Harmony [Middle English armonie, from Old French, from Latin
harmonia, from Greek harmoniā, articulation, agreement, harmony, from
harmos, joint.] extends beyond ES6 in some way we should rename it.
Of course we hope that the committee will operate harmoniously for a
good long time, but we have other musical tropes to abuse ;-).
So let's say ES6 is Harmony. Once again I do not wish to "ban" decimal
from ES6 but it is not on the committee's agenda, and members do not
want to standardize it in a "hardcoded" fashion, so value types come
first, and may be the only extension relevant to decimal in ES6.
On Jun 24, 2009, at 12:37 PM, Brendan Eich wrote:
So let's say ES6 is Harmony.
Last message from me on this topic today, I promise.
I wanted to encourage the use of "Harmony" for what's next, over
against "ES6". The ES3.1 -> ES5 experience, and of course many
software release renumbering adventures from our collective
professional and open source lives, teach us to avoid burning numbers
in SiO2 prematurely. Ecma wants whole edition numbers, ISO tracks
those. There could be a reason to do a fast ES6 that is not "Harmony".
So don't early-bind to ES6 :-P.
Good thing you caught me before I'd sent my reply :-P.
If decimal isn't being actively pursued I'll give the anti-decimal propaganda machine a break. And if it does turn out that decimal becomes a popular extension I'll happily accept that I've been proven wrong and be all for including it in the language.
On Wed, Jun 24, 2009 at 12:43 PM, Brendan Eich <brendan at mozilla.com> wrote:
On Jun 24, 2009, at 12:37 PM, Brendan Eich wrote:
So let's say ES6 is Harmony.
Last message from me on this topic today, I promise.
Aha! Carte blanche to have the last word of the day! Better seize while it's hot. Just kidding ;)
I wanted to encourage the use of "Harmony" for what's next, over against "ES6". The ES3.1 -> ES5 experience, and of course many software release renumbering adventures from our collective professional and open source lives, teach us to avoid burning numbers in SiO2 prematurely. Ecma wants whole edition numbers, ISO tracks those. There could be a reason to do a fast ES6 that is not "Harmony".
So don't early-bind to ES6 :-P.
As I think Allen first suggested (please correct if I misattribute or misconstrue), I have been using "Harmony" to label the trajectory that the Harmony agreement set us on. I have been using "ES6" to name whatever the next concrete spec edition will be that emerges from our agreed trajectory. No matter how fast or slow ES6 is, many of the things currently hoped for under the Harmony banner will not make it into the next concrete edition.
On Wed, Jun 24, 2009 at 13:46, Mark Miller<erights at gmail.com> wrote:
As I think Allen first suggested (please correct if I misattribute or misconstrue), I have been using "Harmony" to label the trajectory that the Harmony agreement set us on. I have been using "ES6" to name whatever the next concrete spec edition will be that emerges from our agreed trajectory. No matter how fast or slow ES6 is, many of the things currently hoped for under the Harmony banner will not make it into the next concrete edition.
I want to second that. The list of features we agreed on at the last F2F was a bit too long for my liking. I think it is more reasonable to do the new spec (with a RI) and just add a few of those features in a faster iteration. I have my opinion on which those features are but l would rather save that discussion for the next face to face meeting.
On Jun 25, 2009, at 9:56 AM, Erik Arvidsson wrote:
On Wed, Jun 24, 2009 at 13:46, Mark Miller<erights at gmail.com> wrote:
As I think Allen first suggested (please correct if I misattribute or misconstrue), I have been using "Harmony" to label the trajectory
that the Harmony agreement set us on. I have been using "ES6" to name
whatever the next concrete spec edition will be that emerges from our agreed
trajectory. No matter how fast or slow ES6 is, many of the things currently
hoped for under the Harmony banner will not make it into the next concrete
edition.I want to second that. The list of features we agreed on at the last F2F was a bit too long for my liking. I think it is more reasonable to do the new spec (with a RI) and just add a few of those features in a faster iteration. I have my opinion on which those features are but l would rather save that discussion for the next face to face meeting.
You're right, the Harmony agenda is big enough that in all likelihood
it won't fit into one edition.
I was arguing against coupling to editions for several reasons, but I
backed off on calling this outcome because of the tension between
integrated design and triage to fit a standards process.
To argue against the extreme point at risk here, we want more than
barely treading water by switching to a new spec formalism.
Standardization overhead is high enough that amortizing the real work
over too many editions makes for too little progress relative to
chunkier editions.
Plus, smaller path-dependent hops can paint us into corners that we
can't get out of due to progressive compatibility constraints.
I hate to say more without data, so let's proceed and see how it goes.
On the spec formalism / reference implementation front, the good news
is that we will have help from Dave Herman and Sam Tobin-Hochstadt (www.ccs.neu.edu/home/samth
).
I've been looking around on the web for reasons why decimal arithmetic should be added to ES. The most extensive page I could find was speleotrove.com/decimal/decifaq.html. If anyone know other good sources of information about decimal and its inclusion in ES please follow up.
The strongest argument seems to be financial: binary arithmetic is approximate in a way that makes it unsuitable for financial calculations. I buy this argument in general -- I would definitely want my bank to use some form of decimal arithmetic rather than binary -- but less so in the context of ES. A while ago we (the v8 team) asked around within google and were unable to find anyone who would want to do financial calculations client-side. Financial calculations are sensitive and keeping it on the server makes it possible to maintain consistency, accountability, testability and reproducibility. So while I'm all for decimal in languages that run server side it's much less relevant for a language that runs almost exclusively on the client.
Another data point is that the one decimal library that exists for JS, a direct translation from Java's BigDecimal, hasn't been updated since 2000, during which time a number of bugs have been fixed in Java BigDecimal. If there had been a broad interest in using a JS decimal library I would expect there to be a well-maintained one around.
I found a handful of blog posts supporting decimal from an accuracy standpoint -- essentially "0.1 + 0.2 should be equal to 0.3". The argument looks compelling but is somewhat misleading. All floating point arithmetic is approximate. K-bit decimal arithmetic trades smaller but conspicuous inaccuracies for greater but less conspicuous ones when compared with k-bit binary. In some contexts, financial again for instance, the accuracy argument makes sense but not as a general statement without qualification. Nonetheless, far as I can tell this is the source of a large portion of the requests for supporting decimal. Furthermore, decimal itself is counter-intuitive in a number of ways: the difference between 1e2 and 100, for instance, is counter-intuitive in many contexts. I know the most obvious differences have been removed from the ES proposal; I'm not sure if there are less obvious differences left (like with +/-0).
Another problem is that the standard is closed: I can't even read it without paying for it. Granted, that also holds for the specification of double but with double there is universal native support, we don't have to maintain an implementation ourselves. That's not the case for decimal. We as implementers of the language would have to potentially create or at least maintain an implementation of a closed standard.
Finally, the usefulness of decimal either a native implementation or a library would have to be weighed against the increase in the size of the implementation. The fact that JS is becoming increasingly popular on limited devices speaks against adding a large decimal library.