3 ms·

Please, inform me, if you are not trolling on the cheap. https://www.dartlang.org/articles/numeric-computation/ https://www.dartlang.org/articles/numeric-compu

Please, inform me, if you are not trolling on the cheap. https://www.dartlang.org/articles/numeric-computation/ https://www.dartlang.org/articles/numeric-computation/ http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html http://docs.oracle.com/javase/7/docs/api/java/math/BigIntege... Both arbitrary precision immutable integer types. If some corner case differs, my point stands. Google has more than enough engineers on Dart to do the work of writing a bignum library in JS, if they can't find one to use that someone already wrote. /be

spankalee 13y ago
I'm definitely not trolling. I truly thought you would understand the basic difference. Big integer support in Dart is not an issue of writing a bignum library. That's already been done. The difficulty is in supporting the single integer type in a way that's performant for numbers < 2^53 Java has fixed width ints, Dart has infinite precision ints. In Java when dealing with ints, you're always in the int domain, and when dealing with BigIntegers you're always in the BigInteger domain. In Java operations on ints can overflow. In Dart operations on ints don't overflow - internally, if the result doesn't fit in an machine int a bigint is returned. In JavaScript you have a few choices when implementing infinite precision ints: 1) Use a single bigint type for all ints, which will be incredibly slow. 2) Use two types for ints, the built-in number and a BigInteger class. This means a lot of expensive type and overflow checks that slow down basic numeric operations. 3) Don't implement infinite precision ints. Compile-to-JS languages can use static analysis to do better. dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases.
- pcwalton 13y ago
  > dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases. Couldn't you just have changed Dart to fix the semantics? This is a big issue (no pun intended) that essentially means that dart2js is broken. I predict that, absent some solution to this issue, if Dart takes off, there will be sites that break in non-Chrome browsers when (for example) 64 bit hashing algorithms are involved due to authors only testing in Chrome and not testing the dart2js version.
- BrendanEich 13y ago
  "I truly thought" you would not raise a question to which V8/Dart people already know the answer. Range prop is not the only solution. Use JIT techniques to speculate profitably that most ints fit in JS doubles. This can be done in JS-hosted VMs, just as in machine-code-generating native VMs. Again, this is extremely old hat to the Dart/V8 folks. See, e.g. http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-in-js http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-... In SpiderMonkey, we augment JIT techniques with online type inference that distinguishes int from double. The same type inference could add bignum to the speculative tower. See http://rfrn.org/~shu/drafts/ti.pdf‎ http://rfrn.org/~shu/drafts/ti.pdf‎ This avoids most of those checks that you assume are too expensive (and by assuming, so casually fork Dart semantics). Here is a JS version of [Hackett&Shu, PLDI 2012], from @pcwalton: https://github.com/pcwalton/doctorjsmm/ https://github.com/pcwalton/doctorjsmm/ Can the full JIT+TI approach to bignum/double/int perform well enough for dart2js? Better find out, because forking semantics is just the wrong thing. Another road not taken: we hear "can't wait for JS to get better", but Dart started at least by 2010, possibly earlier. http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums could have been proposed and actually worked into ES6 by now, but the Dart team was in stealth mode (Dash) for too long. Still, better late than never. There's time for ES7. Who from Google will actually do the work in V8 and with Ecma TC39? /be
  - spankalee 13y ago
    This is sounding less and less like just plugging GWTs BigInteger implementation into Dart, which is exactly my point when I said you must know the difference.
    - kevingadd 13y ago
      Using a GWT BigInteger for all dart2js integers would work just fine and provide correct semantics, but if it doesn't meet their performance bar, that's a failure of design - not an excuse for cutting corners and shipping a dart2js that produces wrong behavior. This could have been accounted for with a better language design, but it wasn't.

spankalee 13y ago

I'm definitely not trolling. I truly thought you would understand the basic difference. Big integer support in Dart is not an issue of writing a bignum library. That's already been done. The difficulty is in supporting the single integer type in a way that's performant for numbers < 2^53 Java has fixed width ints, Dart has infinite precision ints. In Java when dealing with ints, you're always in the int domain, and when dealing with BigIntegers you're always in the BigInteger domain. In Java operations on ints can overflow. In Dart operations on ints don't overflow - internally, if the result doesn't fit in an machine int a bigint is returned. In JavaScript you have a few choices when implementing infinite precision ints: 1) Use a single bigint type for all ints, which will be incredibly slow. 2) Use two types for ints, the built-in number and a BigInteger class. This means a lot of expensive type and overflow checks that slow down basic numeric operations. 3) Don't implement infinite precision ints. Compile-to-JS languages can use static analysis to do better. dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases.

pcwalton 13y ago
> dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases. Couldn't you just have changed Dart to fix the semantics? This is a big issue (no pun intended) that essentially means that dart2js is broken. I predict that, absent some solution to this issue, if Dart takes off, there will be sites that break in non-Chrome browsers when (for example) 64 bit hashing algorithms are involved due to authors only testing in Chrome and not testing the dart2js version.
BrendanEich 13y ago
"I truly thought" you would not raise a question to which V8/Dart people already know the answer. Range prop is not the only solution. Use JIT techniques to speculate profitably that most ints fit in JS doubles. This can be done in JS-hosted VMs, just as in machine-code-generating native VMs. Again, this is extremely old hat to the Dart/V8 folks. See, e.g. http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-in-js http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-... In SpiderMonkey, we augment JIT techniques with online type inference that distinguishes int from double. The same type inference could add bignum to the speculative tower. See http://rfrn.org/~shu/drafts/ti.pdf‎ http://rfrn.org/~shu/drafts/ti.pdf‎ This avoids most of those checks that you assume are too expensive (and by assuming, so casually fork Dart semantics). Here is a JS version of [Hackett&Shu, PLDI 2012], from @pcwalton: https://github.com/pcwalton/doctorjsmm/ https://github.com/pcwalton/doctorjsmm/ Can the full JIT+TI approach to bignum/double/int perform well enough for dart2js? Better find out, because forking semantics is just the wrong thing. Another road not taken: we hear "can't wait for JS to get better", but Dart started at least by 2010, possibly earlier. http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums could have been proposed and actually worked into ES6 by now, but the Dart team was in stealth mode (Dash) for too long. Still, better late than never. There's time for ES7. Who from Google will actually do the work in V8 and with Ecma TC39? /be
- spankalee 13y ago
  This is sounding less and less like just plugging GWTs BigInteger implementation into Dart, which is exactly my point when I said you must know the difference.
  - kevingadd 13y ago
    Using a GWT BigInteger for all dart2js integers would work just fine and provide correct semantics, but if it doesn't meet their performance bar, that's a failure of design - not an excuse for cutting corners and shipping a dart2js that produces wrong behavior. This could have been accounted for with a better language design, but it wasn't.