Comment by prewett | Hacker News Reader

Comment by prewett | Hacker News Reader

Parent Full thread

Ok, you've got me really curious what these applications are. 2^53 is 3.67e18, which is about 500 times larger than the number of millimeters from the sun to Pluto's maximum orbit [1] allowing an accurate model of a solar system. It is more kilometers than the diameter of the Milky Way [2], allowing accurate models of a galaxy (given the size of stars, 1 km is pretty accurate). I'm guessing that the 15 TB storage requirement of 400 billion stars [3] is going to be a problem long before the integer precision. So I'm not really seeing how games or graphics are going to need more than this precision...

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.

> Ok, you've got me really curious what these applications are.

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.

Ok, I can think straight up of one huge use case. With 64 bit integers, I can blend all four colour channels of a pixel in one hit. For graphics operations this is a huge performance boost. (For those unfamiliar with the concept, you allocate 16 bits of the integer to each of rgba, which are only 8 bit values. The extra 8 bits per channel allows you to handle overflow on operations, which means you can do an op in all four channels simultaneously).

Any time you multiply two 32-bit numbers, you need 64 bits out to prevent overflow. Sometimes cleverly splitting and rearranging an operation will avoid the overflow, but it's much cheaper in developer time to have 64 bit ints available for intermediate parts of calculations.

Bit sets for 64 element or 8x8 things. One example are chess programs (the board is represented as several 64bit integers called bit boards) but there are many others. Everything is going to be way slower if you suddenly need split your bit set in two.

Yet twitter ids are bigger than 53 bits (they return string ids now).

There weren't more than 9 quadrillion tweets though.

    >>> Math.pow(2,53) / Math.pow(10, 9) / 7
    1286742.7506772846

Over a million tweets per person? Certainly not.

If you think 'modelling the entire milky way' is an average use case you don't know very much about graphics or game engines, and you should stop extrapolating based on your horribly inadequate knowledge in order to draw faulty conclusions. Again, I have end-users building games and other types of software that are using 64-bit integers right now and have told me they actually need 64 bits of precision. In one case they were actually using pairs of 64-bit integers for 128 bits of precision.

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.

Reply on news.ycombinator.com