Very few applications need "big" (in this case: > 2^53) integers.
So far, I only needed them once. I ported a big int micro benchmark a few months ago. Kinda meta. Not sure if that really counts.
So far, I only needed them once. I ported a big int micro benchmark a few months ago. Kinda meta. Not sure if that really counts.
And this isn't based on 'I've only hit one case where I needed them'; this is based on how many users of compilers like Emscripten and JSIL actively utilize 64-bit arithmetic - sometimes they use it so much that they demand high performance! A half-assed implementation that relies on doubles being 'good enough' is just not going to cut it.
Crypto needs 256 bit integers minimum, so 64 bit integers are usually convenient multiples, but not terribly helpful.
I'm not saying that 53-bit integers are good enough (although I certainly have never needed anything that large); I have no idea. But I don't see a huge number of applications that obviously need them. So I'm curious...
[1] According to http://en.wikipedia.org/wiki/Pluto, Pluto's maximum orbit is 7.31e9 km = 7.31e15 mm
[2] 120,000 ly = 120,000 ly * 9.5e15 m = 1.14e20 m = 1.14e18 m (http://en.wikipedia.org/wiki/Milky_Way)
[3] Each stars needs (x, y, z) and (v_x, v_y, v_z), probably also in 53-bit integers, so that is 6 * 53 bits = 318 bits = 40 bytes. 4e11 stars * 40 bytes = 1.6e13 bytes = approximately 14.6 TB.
In addition to the applications others mentioned, this is an issue in applications that don't need it, but run into it. If for example a program has a bug where a number is multiplied by 2 in a loop, then if it's a double it will eventually become infinity and stop changing, but if it is a bigint then it will continue to increase. This means that the bug will have different effects in those two cases.
While this is a bug, if the developer tests on only one of those platforms (say, the double), and the bug happens to not cause noticeable effects, it might go unfixed, but people on the other platform (with bigints) would get something broken (as a constantly growing bigint, eventually it will be extremely slow or run into some limit and give an exception).
The basic issue is that leaving numeric types to some extent undefined means you open yourself up to risks like this. How common it will be in practice is hard to say, of course, but I've seen such things happen in another language, so I think this can't be simply ignored out of hand.
>>> Math.pow(2,53) / Math.pow(10, 9) / 7
1286742.7506772846
For your contrived galaxy example, one thing you need to realize is that value ranges aren't the only thing that matters; value precision is just important, and variable precision is an absolute trainwreck in game development scenarios because it means that your game's physics are nondeterministic (due to precision variance depending on where you are). This is a real problem that affects real games. EVE Online happens to simulate a massive galaxy and massive solar systems, and it uses integers to represent coordinates precisely for this reason.
So crypto needs '256 bit integers' (why 256? why not 512? 2048? 4096?), thus it's okay that dart only offers 53 bits of integer precision, and somehow 64 bits wouldn't be better? Does your CPU have 256-bit integer registers? Last I checked, most integer registers only go up to 64 or 128 bits, and the registers bigger than that are for SIMD - i.e. they contain multiple integers, not one big one. I'm not even demanding that Dart implement arbitrary-precision integer arithmetic here - just actually get 64 bit integer arithmetic right, since VIRTUALLY EVERY real programming environment's VM offers it natively to begin with [0]. If you still insist that nothing less than arbitrary precision integer values are sufficient for crypto, then fine - what about 64-bit hashing algorithms (real; used in production)? What about applications that need to do I/O against files/buffers larger than 4GB? What about applications that need to do graphics rendering against image surfaces larger than 4GB? What about audio editing software that needs to operate on long audio recordings larger than 4GB? When 32-bit unix timestamps overflow in 2036, will 64-bit integers still be unimportant?
These are all real use cases. If you ignore them all and still argue that 64 bit integers don't matter, you don't seem to have the ability to imagine software beyond your experience.
[0] Yes, there are a few scripting runtimes without 64-bit integer values built-in. They are all insufficient for anything resembling numeric computation.