2 ms·
> You're already allowing the user to omit the 14+ zeros of precision actually represented in the underlying value and there's no confusion about what the corre
by Someone 2y ago
> You're already allowing the user to omit the 14+ zeros of precision actually represented in the underlying value and there's no confusion about what the correct answer is in either case
In json, there’s considerable confusion possible, as you don’t know how much precision is “actually represented”. For example, is “1.3” meant as a float, as a double, as a big decimal? In most languages, (double)1.3f prints as 1.299…, and is different from 1.3
- AlotOfReading 2y agoThat would be a good reason to be careful about floats, but it's not the issue described. There's just one implementation for the author's language with just two types: some kind of integer and some kind of real called "number". Any choice they make for the latter would have the issue in the article, but wouldn't have the issue you're describing, because there'd be a single nearest value in the chosen representation.