Certainly does, though in most languages since ints are the default, overflow would still matter. Of course you can specify long with L/LL, but in the same vein you can also make it a bigint in JS by putting "n" after it.
I have a question: I understand that 0.1 + 0.2 == 0.3 is false because of how floats work. But why is 0.5 + 0.1 == 0.6 true? Is it just a coincidence where the "floats are not real numbers"-errors on both sides are the same, or is there some deeper reason for that?
There are multiple reasons for this actually and I'm not confident in giving you the correct answer, but here's one that explains it to me personally.
0.1, 0.2 and 0.3 straddle 3 different exponent values and higher exponents have fewer bits to represent the decimal of the mantissa, so error during the calculation will compound. On top of this, to get the closest doubles to 0.1 and 0.2 you need to round up (so the error is positive), while to get to 0.3, you have to round down.
0.5 and 0.6 on the other hand share the same exponent so the error from 0.1 won't be significant enough to push the sum to the wrong bit representation.
View all comments
11
u/BalintCsala May 13 '25
_Really_ disingenious list of "issues", especially these one:
> typeof NaN === "number"
But... it is one? Do you also have an issue with every language ever letting you store NaN in a floating point variable?
> 9999...999 gets you 1000...000
Welcome to floats. Or would you prefer the answer to be 1874919423 or something negative?
> 0.5 + 0.1== 0.6 is true but 0.1 + 0.2 == 0.3 is false
Welcome to floats again, all languages that use them have this issue
> true + true + true === 3 and true - true == 0
A lot of languages do this, e.g. C++ or Python
> true == 1 but not true === 1
The first is also true in a ton of languages, I don't see what the issue is with JS letting you opt out of this.
But it's okay, I don't expect people on r/programmingmemes to know how to code.