Dart 2.0 feature chopping block: arbitrary precision integers for keeps?!

[Patrice Chalin]

On the topic of Dart 2.0 in the 2015-08-26 DEP Committee Meeting minutes it is written that:

start talking about Dart 2.0 ... discuss what things we think could or should be removed from Dart in 2.0.

Given that there will soon be discussions about language features that could be removed from Dart, and given the (minor?) challenges faced due to the mismatch between JS integers and Dart integers, I am still hoping that the arbitrary precision-ness of Dart ints is not one of the features heading to the chopping block.

This is a minor point, but given the increased importance of JS interop, I am worried that the mismatch between Dart and JS ints may be perceived as more problematics that it is.

Maybe such a removal is not under consideration, but if it is, I would much rather see, e.g., added support for integral subrange types (a la Ada) than seeing the unconditionally return of (silent) numeric over/underflows.

Cheers

--

Patrice   

[Alexandre Ardhuin]

I would not be a big fan this change. Especially because an implementation of decimal numbers based on arbitrary precision int is more simple (it can be done by rational representation) and efficient compared to an implementation on limited ints (eg. Java BigInteger and BigDecimal classes). Decimals are really important in financial computations.

Perhaps bignums will one day land in ecmascript (again mentioned in http://fr.slideshare.net/InfoQ/new-in-ecmascript-2016-javascripts-first-yearly-release). But, from a performance point of view, I don't know if Dart int should be always compiled to bignum.

If the removal of arbitrary precision-ness is accepted, it could be worth to add a new bignum type under num and benefit from this compilation target.

Alexandre

--
You received this message because you are subscribed to the Google Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to core-dev+u...@dartlang.org.

[Lasse R.H. Nielsen]

I haven't personally heard any plans to remove arbitrary precision integers (not that that necessarily proves anything).

One problem with removing arbitrary precision integers is that you then have to decide which precisions to support. Then you quickly get into having all of int8, uint8, int16, uint16, int32, uint32, int64, uint64, int128, uint128, int256, uint256 - along with rules about what happens if you add or multiply them with each other, and the need for literals and casts of each type.

/L

--

Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Paul Brauner]

I'd rather keep bignums and fight for bignums in js than to have "integers" that aren't closed under addition, substraction, multiplication, ...

[Seth Ladd]

On Tue, Sep 1, 2015 at 4:50 PM, Patrice Chalin <pch...@gmail.com> wrote:

On the topic of Dart 2.0 in the 2015-08-26 DEP Committee Meeting minutes it is written that:

start talking about Dart 2.0 ... discuss what things we think could or should be removed from Dart in 2.0.

Given that there will soon be discussions about language features that could be removed from Dart, and given the (minor?) challenges faced due to the mismatch between JS integers and Dart integers, I am still hoping that the arbitrary precision-ness of Dart ints is not one of the features heading to the chopping block.

This is a minor point, but given the increased importance of JS interop, I am worried that the mismatch between Dart and JS ints may be perceived as more problematics that it is.

I'm curious to know the impact that arbitrary precision ints has on pre-compiling Dart into native code.

 

Maybe such a removal is not under consideration, but if it is, I would much rather see, e.g., added support for integral subrange types (a la Ada) than seeing the unconditionally return of (silent) numeric over/underflows.

Cheers

--

Patrice   

--

[Bob Nystrom]

On Wed, Sep 2, 2015 at 1:12 AM, 'Lasse R.H. Nielsen' via Dart Core Development <core...@dartlang.org> wrote:

Then you quickly get into having all of int8, uint8, int16, uint16, int32, uint32, int64, uint64, int128, uint128, int256, uint256 - along with rules about what happens if you add or multiply them with each other, and the need for literals and casts of each type.

As soon as you want to interoperate with a lower-level platform like iOS, Android, native C/C++, etc. you have to worry about those anyway.

Personally, I have always felt big integers were a mistake to specify. The number of real-world programs and real-world users that rely on the functionality is tiny. The positive benefit is very small. In return for that we got:

• A ton of bad PR because dart2js doesn't support it so the VM is incompatible and we're "breaking the web".
  
  
• A much nastier testing story because the VM and dart2js actually are incompatible and code that works on the VM may not work on dart2js. Now your developer iteration loop is slower and less reliable because code that works right in your normal fast Dartium cycle may break when you do a slower compile to dart2js.
  
  
• Surprising performance degradation when what you thought was a simple addition happens to overflow into bigint territory and now your perf tanks. Worse, this doesn't tend to show up on tests because those use shorter runs and smaller data sets.
  
  In most Dart code I've seen, implementations of things like hashCode are either (1) a performance landmine waiting to be stepped on or (2) written by someone who knows about this trap and correctly using something like & 0xffffffff to keep the number from going too big. You'll note that in the latter case, users are manually implementing the exact kind of number semantics Dart is designed to not give.
  
  
• To burn the resources required to implement, test, maintain, and optimize a big integers in the VM. That's time we could have spent on things users care much more about.
  
  
• Confusing features few people know about like --throw_on_javascript_int_overflow.

Even after all of this, code that does want to use big integers generally can't. Because Dart was designed to be a client-side web language, almost all production Dart code runs compiled to JavaScript which doesn't support bigints anyway. If you need bigints, you're right back to needing a library-level implementation written in Dart, the whole thing we ostensibly wanted to avoid.

Whether you like big integers in principle or not, we have clear evidence that they are a misfeature for Dart and the platforms it is targeting. We specified a feature without ever having a concrete plan on how to implement it in the main deployment platform for the language.

If we were designing a language for doing mathematics on desktop machines, sure bigints all the way. But for a language whose primary job is to put the right pixels on screen on a memory- and CPU-constrained client device, it's a drain on resources.

Even if you do want to have bigints on that device, a library implementation of them that actually works on all platforms and can meet whatever other requirements you have (big rationals? units of measure?) is a better solution.

- bob

[Patrice Chalin]

Alexandre, thanks for the link to the ES 2016 talk, I had not seen that yet. Nice to see the list of features being worked on.

[Patrice Chalin]

Thank you all, that is valuable feedback. Bob, you are right, these are real problems, and the current situation is unsatisfactory (like sitting on a fence).

In a separate thread on "Ensuring continued innovation in Dart. Or: where are the roadmap & vision statement?" you wrote:

On Tue, Sep 1, 2015 at 5:31 AM, Erik Ernst <eer...@google.com> wrote:

As soon as you have that I'm sure you can use it to provide a very well performing `int` etc.,

Well, we've had consistent, well-understood semantics for Dart for a long time now, and we still don't have great performance around numbers on all of the implementations. Still waiting on that Sufficiently Smart Compiler™. :(

Compiler optimizations are easier to design when given appropriate developer guidance --- e.g., non-null types help the compiler know when a developer intends a type to be non-null. I think that we have the right basis for a workable approach: keep the base int type as arbitrary precision and then let developers provide guidance to the compiler, as needed, via subrange types that are application specific: e.g., (let me just invented some notation)

typedef [1..12] Month;

Most consistent with the current Dart philosophy would be to treat Month as an int with extra runtime checks in checked mode. A compiler can then do a much better job at figuring out how to optimally represent a Month.