On: NPM and Left-Pad: Have We Forgotten How to Program?

[nbzklr]

That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.

[PeCaN → nbzklr]

How does that help? Besides they overflow to doubles if they get bigger than 2^31-1 anyway.

The problem with a naive average like this is that if you're averaging a bunch of big numbers there is a very high chance of overflow when you're summing, so even if all the numbers fit in 32 or 53 bits your calculation will be off.

If you're not averaging thousands of large numbers, why are you even using a package instead of nums.reduce((a,b)=>a+b) / nums.length anyway?

[colanderman → nbzklr]

How does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?

[esailija → colanderman]

53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?

[colanderman → esailija]

Who said anything about 64 bits?

[esailija → colanderman]

The complaint was that JavaScript doesn't have 64-bit integers but only 53.

[e12e → colanderman]

Clearly 2^32+2^32 < 2*53, so there is no problem ;-)

[Too → nbzklr]

Source? I find this very hard to believe. 1. How does the engine know of it should be an integer or not? 2. Why would they have a special case for this, it won't benefit accuracy and treating them in a special way probably hurts performance more than just always keeping it as doubles.

[other_herbert → nbzklr]

As long as everything used is really an integer and that everyone you work with is careful to keep things as ints (oring with 0 and such)