3 ms·

I am surprised that jwz wasn't aware of this. For the record, I think it was a reasonable decision. If you can't make something work well then at least make it

by halo 16y ago

I am surprised that jwz wasn't aware of this. For the record, I think it was a reasonable decision. If you can't make something work well then at least make it simple. JavaScript's treatment of numbers is extremely simple: every number is a double precision floating point number.

silentbicycle 16y ago
Yes. While I understand annoyance with floating point accuracy bugs (having been burned by inch/mm conversion and pi/radian bugs before), numbers over 2^53 are large enough that they aren't likely to appear unexpected - if your domain needs bignums, you'll probably know it - so it's a reasonable trade-off.
acqq 16y ago
I also don't understand what jwz's problem with the JS numbers is. Once you have bit operators, you can do bit arithmetic. So yes it's a bit slower than when having pure integer types, so what? The JS engines were something like 100 times slower up to recently, and nobody really, really cared until Google did V8. I really think Brendan was right in his decision and I don't get what jwz would like, except to maybe have explicit types in the language, like, hm, JScript.NET or ActionScript. But even there as far as I know ints are 32 bits. 64-bit OS use is still not so common, so at the time the languages were introduced it was the best engineering decision. jwz misses this time.
- grayrest 16y ago
  > nobody really, really cared until Google did V8 Tamarin and Squirrelfish were benchmark battling before Chrome was publicly released. I think the current focus on performance to be sparked by the CSS selector engine battle between the major JS frameworks.
  - BrendanEich 16y ago
    SpiderMonkey (TraceMonkey in August 2008) was battling SquirrelFish (SquirrelFishExtreme in fall 2008) on untyped JS (Taramin did well only if you added type annotations). V8 was "first" only behind Google's firewall, until Chrome released in early September 2008.
- BrendanEich 16y ago
  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?

by halo 16y ago

silentbicycle 16y ago

Yes. While I understand annoyance with floating point accuracy bugs (having been burned by inch/mm conversion and pi/radian bugs before), numbers over 2^53 are large enough that they aren't likely to appear unexpected - if your domain needs bignums, you'll probably know it - so it's a reasonable trade-off.

acqq 16y ago

I also don't understand what jwz's problem with the JS numbers is. Once you have bit operators, you can do bit arithmetic. So yes it's a bit slower than when having pure integer types, so what? The JS engines were something like 100 times slower up to recently, and nobody really, really cared until Google did V8. I really think Brendan was right in his decision and I don't get what jwz would like, except to maybe have explicit types in the language, like, hm, JScript.NET or ActionScript. But even there as far as I know ints are 32 bits. 64-bit OS use is still not so common, so at the time the languages were introduced it was the best engineering decision. jwz misses this time.

grayrest 16y ago
> nobody really, really cared until Google did V8 Tamarin and Squirrelfish were benchmark battling before Chrome was publicly released. I think the current focus on performance to be sparked by the CSS selector engine battle between the major JS frameworks.
- BrendanEich 16y ago
  SpiderMonkey (TraceMonkey in August 2008) was battling SquirrelFish (SquirrelFishExtreme in fall 2008) on untyped JS (Taramin did well only if you added type annotations). V8 was "first" only behind Google's firewall, until Chrome released in early September 2008.
BrendanEich 16y ago
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?