3 ms·
> to make floats less scary for the common people? The obvious thing would be making sure that it's easy to get a unambiguous, natural representation of what a
by a1369209993 3y ago
> to make floats less scary for the common people?
The obvious thing would be making sure that it's easy to get a unambiguous, natural representation of what a float value actually is. (Similar to what C printf %a specifiers produce, rather than something like Ryu float-to-decimal, which is useful for what a float value means for human-readable purposes.)
0X1.999999999999AP-4
+0X1.999999999999AP-3
=0X1.3333333333334P-2
≠0X1.3333333333333P-2
is ugly (and could be improved[0]), but far more understandable (and less superstition-inspiring) than:
0.1 + 0.2 = 0.30000000000000004 ≠ 0.3
0: At the very least, please make it easy to get "0xA.BCDEFp+1", with capital "ABCDEF" and lowercase "xp", so the digits look like digits and the punctuation looks like punctuation.
- zokier 3y agoI agree, although strictly speaking I think conventional decimal representation should be unambiguous, i.e. there is always one float that is closest to the decimal value
- a1369209993 3y agoStrictly speaking, unambiguous decimal representation - such as Ryu and its less-efficient predecessors - is unconventional, but I agree that it's correct and should be the default. (That's the "0.1 + 0.2 = 0.30000000000000004 ≠ 0.3" in my comment.) My point is that it should also be easy to get a natural representation that corresponds closely to the actual bits of the float, in rouchly the same way that 0xAAAB corresponds closely to the actual bits of (int16_t)-21845, and so gives you a chance to notice that something weird is going on when, for example, you encounter a multiplication by -21845. (Something like hex(*(uint64_t*)&x) can work, but makes printf %A look beautifully readable by comparison. Also most languages - especially interpreted ones - manage to be inferior to C in this respect.)