Re: Why decimal?
On Wed, Jun 24, 2009 at 13:46, Mark Millererig...@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. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why 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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
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? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
2009/6/23 Brendan Eich bren...@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. http://www2.hursley.ibm.com/decimal/ The most-duplicated JS bug in bugzilla.mozilla.org is https://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.1399 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. /be ___ 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
Re: Why decimal?
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. https://mail.mozilla.org/pipermail/es-discuss/2009-June/009553.html /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
Erik Corry wrote: 2009/6/23 Brendan Eich bren...@mozilla.com mailto:bren...@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: http://speleotrove.com/decimal/decifaq.html http://speleotrove.com/decimal/ - Sam Ruby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
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? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
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? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why 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: https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html 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: http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope 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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Why decimal?
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. 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. -- Christian ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 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 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/ The most-duplicated JS bug in bugzilla.mozilla.org is https://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.1399 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. /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
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: http://wiki.ecmascript.org/doku.php?id=strawman:strawman Mark M. took the action to write the spec, he already posted his operator proposal to this list, here: https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html 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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
