[zokier]

What do you think programming languages/libraries/tools could do to make floats less scary for the common people? I feel there is lot of superstition around floats, some of it more well deserved than others, but it leads people to approach fp with great distrust.

Of course herbie is already good step here, but it is still somewhat niche.

[a1369209993]

> 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]

I 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]

Strictly 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.)

[aSanchezStern]

Huh, good question. I think having a herbie-style error visualization graph built into an IDE would go a long way. In practice I think dynamic sampling is pretty good at capturing error behavior, and immediate visual feedback on the floating point code you're writing would make it a lot easier to trust the working code you have, and understand the problems with the error-prone computations. Something like https://github.com/herbie-fp/odyssey, but analyzing the fp expressions in the code files you're editing.