564 karma · joined March 29, 2013
Internally it uses the same algorithm, Grisu, (with some additional optimizations) so there shouldn't be any difference in output.
If it's easier to use for you, just go with it!
I'm guessing the double-conversion library is a bit more flexible, but I could be wrong.
These algorithms (Grisu, Ryu, ...) all satisfy the "internal identity requirement", which means that they can print a double and read it back in to the same double.
The harder part is to also produce the shortest of all possible string-representations. (And then picking the closest if there are many).
It's really surprising, how long it took to find the most efficient algorithms for double-conversions. In 1980 Coonen already published a good algorithm, but that one was kind-of lost.
For a long time Steele & White's algorithm was the state-of-the-art (with some improvements here and there over time).
Now, Ryu is by far the fastest algorithm out there, but that took ages...
Unfortunately, there doesn't seem to be an easy-to-use, complete library for Ryu yet.
The Grisu library (https://github.com/google/double-conversion) is probably still the go-to library if you don't want to implement it again...
It's almost sad that Massachusetts switching wouldn't even make it into that document... (too normal)
- better type promotion (`if (x is! A) throw "not A"; useAsA(x);`.
- Optional new/const.
- Allowing named arguments at any position at the call site.
These are all easier to specify and implement, and reach more users.
We intend to work on it at a later point again.
Currently, we are not spending resources on parallel execution (with isolates), either. There are other easier features that have more impact.
Eventually, we will revisit this topic, and see if we can make things easier. Multithreading itself is extremely unlikely, but there are other ways we can make parallel execution better; for example with easier data sharing between isolates.
However, it's still on the list of features we would like to work on. Adding it later gets harder (because we don't want to break our users), but we hope that we can find a good migration path.
Brad Green already posted a follow-up post on the omission of Dart on his slides: http://angularjs.blogspot.dk/2017/04/official-languages-at-g...
(I work on Dart.)
It's based on http://florian.loitsch.com/publications/dtoa-pldi2010.pdf
I'm obviously biased, but I think the API is easier, and the algorithm is faster.
However, it's in C++ (which might not suit your needs), and it requires more code (especially with the precomputed constants).
Grisu is also proven to be always correct. As mentioned in another comment: you have to define "correct". Grisu is always accurate, but may bail out if you need the shortest or closest result.
Basically: Grisu will always print a number that reads back to the input. However, it may not be able to print the shortest or closest number (when two decimal outputs have the same shortest length). In that case, it knows this, though, and can tell the user.
I would say that the combination of Grisu and Errol is currently the state of the art.
Errol is not the fastest, nor is it (afaik) proven to always return the closest result.
However, combining Grisu with Errol (as fallback) would probably yield the fastest complete algorithm.
Grisu is accurate, but not always optimal. However, it figures out when that happens and lets you bail out to a slower algorithm when that happens. If you want full speed you should use Grisu, and then use Errol as a bailout.
A bit more context: there are 3 important properties when printing floating-point numbers.
- accurateness: you want the printed number to read back to the same number.
- shortness: often you want the shortest decimal representation: "0.3" and not "0.2999999999999999889". The latter is more precise, but reads back to the same number as "0.3".
- closeness: given two decimal representations of the same length, you prefer the one that is closer to the actual number.
I call the combination of these three properties "optimal".
Note that shortness and closeness are not always crucial. For example, a json-encoder could easily drop those, if the encoding is faster without them. Also, some languages drop shortness in favor of printing something closer to the input.
Grisu always produces accurate results. However, it sometimes can't tell if it already has the shortest and closest number. However (by being conservative) it can tell the user when that happens. In that case, one can fall back to another complete algorithm.
The double-conversion library (http://github.com/google/double-conversion) does exactly that. It uses the slower bignum algorithm in these cases.
Same repo: projects in Google are encouraged to use other project's code. You can only do that if the versions of their dependencies match. The general guideline is that all projects use the latest version and move in sync.
Breaking Changes: I have never been involved in such a huge breaking change, but I would expect that the conversion is done gradually. Ideally, some teams are also helping in the migration (or sign up as guinea pigs to test the latest versions).
Automatic refactoring: These refactorings are done with a tool called Rosie. Search for "Google refactoring, Rosie" to find some papers/documents about it. One of the first hits was this document: http://cacm.acm.org/magazines/2016/7/204032-why-google-store...
Things get more complex if you want to implement the double/integer distinction that exists in Dart. That would either require to box integers or doubles, or to come up with some kind of tagging.
The Dart language and its spec are independent of dart2js (which is just an implementation striving to implement the spec). Clearly there is a huge connection between both (same team, ...), but in the end we decided to accept the non-conformance for the benefit of a better language. On the server Dart developers can already enjoy the more complete number-hierarchy, and, even if it takes time, I still have the hope that client-side we will eventually be able to enjoy Dart VMs everywhere. (Call me "optimist" ;)
Wrt debugging: the VM has a mode where it detects incompatibilities. For example when a number exceeds the 53bits of JS. This should reduce the difficulties in developing cross-platform tremendously.
I was part of the team that started Dart (right place at the right time :), and helped design the language. Obviously we have some emotional binding to the language and would like to drive it into the right direction, but most of us are perfectly happy with others taking the relay.
We still have some ideas and proposals that we have worked on and that we want to champion, but all in all I just hope that the TC52 members will do a good job.
Dart2js is not conformant. You could, maybe, twist the meaning of the spec this way, but it goes against the spirit of the sentence and the spec.
Tbh we never implemented a fully compliant dart2js backend. We have seen how slow the output is when some of our optimizations don't trigger (i.e. when we have bugs) and numbers are not correctly inferred.
Eventually we would like to give it a try, but there are much more important and useful issues we want to fix first.
In practice, numbers are a surprisingly small problem. Programmers have learned to look out for big numbers, and, while a nuisance, they are rarely the source for bugs.
These hidden classes are built on the fly: say you add `x` to a instance to get an object with a configuration that was never seen before. In that case, the engine creates a new description with that new field and remembers the transition (so that further objects with similar configurations can reuse the same hidden class).
Keeping track of these hidden classes takes time and space. If you actually use the JS object as a hashtable, then there will be lots of unnecessary hidden classes, that will never be used again. However, there is a trick to tell the engine that an object is actually a hashtable (and shouldn't be optimized as if it was an instance of a class): when deleting a field from an object v8 (and probably all other engines) assume that the object is used as a hashtable and don't create these hidden classes anymore.
Dart2js uses this trick to avoid this cost some important big hashtables (`B`, `C`, ...).
The dart2js team is one of the teams with the most developers on it. There is a huge effort going into it.
Dart2js generally does a good job, but a few features (like mirrors) that are still in beta-quality, are currently a constant source of grieve for the developers. We would have liked to delay their release until they were more stable, but several customers really, really needed them.
Things are getting better, though, and I hope that dart2js will fade into the background (as a simple working tool) soon.
Edit. you can see the announcement here: https://plus.google.com/109866369054280216564/posts/XbjvN5QV...
Edit2. Removal of the feature: https://code.google.com/p/dart/issues/detail?id=16425
- it adds overhead. Being able to write JSON.encode(customer) would mean that every class needs to retain its field names. Minification could still work if this information is stored on the side, but it would add overhead.
- it doesn't make sense to automatically encode elements that cannot be decoded. You should have: x =~= JSON.decode(JSON.encode(x)). (where x =~= y means that the two objects are Json-equivalent).
- The Dart-Editor already provides a quick-fix to write a toJson for you. To be honest I'm not really a fan of it, since I believe that serialization information should be outside the object, and not in the object (that's what "toEncodable" is for), but that's another story.
- It's extremely easy to get the behavior you want. Just use (or write, if none exists yet) a package that has your intended behavior. This is really a one-line change... This way you pay the price when you want to, and don't force it on all users.
The discrepancy between Dart and JS numbers is mostly an issue for the developers. When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle).
After 2 years of Dart development, numbers have rarely been an issue in practice. Developers know when they deal with numbers > 32/53bits and work around it.