3 ms·
That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.
by nbzklr 11y ago
That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.
- other_herbert 11y agoAs 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)
- colanderman 11y agoHow does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?
- e12e 11y agoClearly 2^32+2^32 < 2*53, so there is no problem ;-)
- esailija 11y ago53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?
- colanderman 11y agoWho said anything about 64 bits?
- esailija 11y agoThe complaint was that JavaScript doesn't have 64-bit integers but only 53.
- PeCaN 11y agoHow 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?
- Too 11y agoSource? 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.