3 ms·
I thought this was going to be about NaNs, signed zeros or other things that are fundamentally different between floats and integer types. I don't really unders
by AlotOfReading 2y ago
I thought this was going to be about NaNs, signed zeros or other things that are fundamentally different between floats and integer types. I don't really understand why accepting implied or overspecified zeros is deeply problematic here. 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. The minor ambiguity with type inference (let b = 1) can be resolved in favor of integers without surprising anyone.
- 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.