4 ms·

jwz is a Lisp hacker, and he pretty clearly wants bignums, not explicit types.

acqq 16y ago
Thanks! So he'd prefer slower execution but with less chance of accidentally losing the least significant bits? Protecting the programmer from himself? Or just having bignums for... what actually? Playing with new crypto algorithms? Why does that have to be in the core language? It's still the question of the engineering trade-off, certainly not so clear as he presents it. In the light of the trend of always bigger importance of small devices, the best direction to take is probably the one that will most often use less of battery power, no matter what programmer's ideals can be.
- BrendanEich 16y ago
  See https://bugzilla.mozilla.org/show_bug.cgi?id=5856 https://bugzilla.mozilla.org/show_bug.cgi?id=5856, the most-dup'ed JS bug in bugzilla.mozilla.org. Or this fun blog post from 2004 that blames Apple ("Apple Flunks First Grade Math"): http://www.mikeindustries.com/blog/archive/2004/08/apple-calculator http://www.mikeindustries.com/blog/archive/2004/08/apple-cal... Finite binary floating point representations do not handle powers of five well. It takes much greater precision (bignums under the hood) to round the last digit properly when converting from binary to decimal (see the David M. Gay and Guy Steele paper and code for dtoa.c). Without hints from the JS hacker (Number.prototype.toFixed) the bad rounding shows up -- try javascript:alert(.1 + .2). bignums (among alternative solutions) fix this bug. bignums also are not necessarily a whole lot slower than doubles, since you can optimize to fixnums for common cases. JITs can do pretty well. It's not as if double is so fast, even with SSE4, that int doesn't still win. But the main bug to fix is the rounding or powers-of-five inexpressiveness issue. It's a real usability problem.
  - acqq 16y ago
    Of course I know about mentioned effects and about dtoa.c. Still thanks, it's important for the context. I'm biased as I actively use floating point calculations and I don't know the convenient representation which would be fast enough like that one which is directly supported by hardware -- you can really get one FP addition per processor cycle(!) on modern x86 processors, potentially more on arrays. That is really as fast as ints (not considering the additional adders and shifters which are there for address calculations and can be used in parallel). But I'd also think mobile CPU's should be considered too in something as widely used as JS. Anyway, from my perspective fast indexable arrays are missing in a lot of modern languages and I think AS3 did something about that. And I believed bignums are lists of integers, so still not enough for .1 + .2, I believed for that we'd need rationals or decimal FP?
    - BrendanEich 16y ago
      Yes, SSE4 has some great -- and parallel as mentioned by both of us now -- bandwidth to throw at adds. FP still hurts if you have to cross the channel from the CPU and back again, and you do with common JS. Mobile is much worse. We disable SoftFP in SpiderMonkey by requiring modern-enough ARM, but Adobe can't in Tamarin (we both use the Nanojit back end). Really slow. Even real FP is not nearly the same as on SSE4.x. Indeed bignum is a bit int format, but since there's no finite precision limit, you can do as someone in jwz's blog comments suggested, and use milli-cents or whatever for currencies, and never suffer rounding. But you do have to scale. EDIT: so to be clear, I agree that bignums don't solve the .1 + .2 problem. IBM favored IEEE754r to handle that case, but no one could agree on the exact integration or worthiness of that finite-precision decimal format. Sam Tobin-Hochstadt's "fast, precise, rational: pick two" conclusion (cited by me in jwz's LJ in reply to someone pushing ratnums as all three) still holds. I think a case can be made for bignums on this two-out-of-three basis, but you'd still want double and you might even want decimal. This need for several numeric types led us to work on value types, so library authors can extend the language with new numeric types (including operator and literal support), and the TC39 committee is not the bottleneck and the one-size-fits-nothing-well decider.

acqq 16y ago

Thanks! So he'd prefer slower execution but with less chance of accidentally losing the least significant bits? Protecting the programmer from himself? Or just having bignums for... what actually? Playing with new crypto algorithms? Why does that have to be in the core language? It's still the question of the engineering trade-off, certainly not so clear as he presents it. In the light of the trend of always bigger importance of small devices, the best direction to take is probably the one that will most often use less of battery power, no matter what programmer's ideals can be.

BrendanEich 16y ago
See https://bugzilla.mozilla.org/show_bug.cgi?id=5856 https://bugzilla.mozilla.org/show_bug.cgi?id=5856, the most-dup'ed JS bug in bugzilla.mozilla.org. Or this fun blog post from 2004 that blames Apple ("Apple Flunks First Grade Math"): http://www.mikeindustries.com/blog/archive/2004/08/apple-calculator http://www.mikeindustries.com/blog/archive/2004/08/apple-cal... Finite binary floating point representations do not handle powers of five well. It takes much greater precision (bignums under the hood) to round the last digit properly when converting from binary to decimal (see the David M. Gay and Guy Steele paper and code for dtoa.c). Without hints from the JS hacker (Number.prototype.toFixed) the bad rounding shows up -- try javascript:alert(.1 + .2). bignums (among alternative solutions) fix this bug. bignums also are not necessarily a whole lot slower than doubles, since you can optimize to fixnums for common cases. JITs can do pretty well. It's not as if double is so fast, even with SSE4, that int doesn't still win. But the main bug to fix is the rounding or powers-of-five inexpressiveness issue. It's a real usability problem.
- acqq 16y ago
  Of course I know about mentioned effects and about dtoa.c. Still thanks, it's important for the context. I'm biased as I actively use floating point calculations and I don't know the convenient representation which would be fast enough like that one which is directly supported by hardware -- you can really get one FP addition per processor cycle(!) on modern x86 processors, potentially more on arrays. That is really as fast as ints (not considering the additional adders and shifters which are there for address calculations and can be used in parallel). But I'd also think mobile CPU's should be considered too in something as widely used as JS. Anyway, from my perspective fast indexable arrays are missing in a lot of modern languages and I think AS3 did something about that. And I believed bignums are lists of integers, so still not enough for .1 + .2, I believed for that we'd need rationals or decimal FP?
  - BrendanEich 16y ago
    Yes, SSE4 has some great -- and parallel as mentioned by both of us now -- bandwidth to throw at adds. FP still hurts if you have to cross the channel from the CPU and back again, and you do with common JS. Mobile is much worse. We disable SoftFP in SpiderMonkey by requiring modern-enough ARM, but Adobe can't in Tamarin (we both use the Nanojit back end). Really slow. Even real FP is not nearly the same as on SSE4.x. Indeed bignum is a bit int format, but since there's no finite precision limit, you can do as someone in jwz's blog comments suggested, and use milli-cents or whatever for currencies, and never suffer rounding. But you do have to scale. EDIT: so to be clear, I agree that bignums don't solve the .1 + .2 problem. IBM favored IEEE754r to handle that case, but no one could agree on the exact integration or worthiness of that finite-precision decimal format. Sam Tobin-Hochstadt's "fast, precise, rational: pick two" conclusion (cited by me in jwz's LJ in reply to someone pushing ratnums as all three) still holds. I think a case can be made for bignums on this two-out-of-three basis, but you'd still want double and you might even want decimal. This need for several numeric types led us to work on value types, so library authors can extend the language with new numeric types (including operator and literal support), and the TC39 committee is not the bottleneck and the one-size-fits-nothing-well decider.