purplesyringa

Thank you! I completely agree with this, floats are treated as a lot more magical than they actually are. I myself often rely on their exact guarantees for fun tricks (e.g. fast precise int<->float conversion: https://purplesyringa.moe/blog/fast-limited-range-conversion-between-ints-and-floats/). But while IEEE-754 is very precise, some subtleties arise when you add library functions to the mix -- many libm's and userland libraries don't guarantee 0.5 ulp precision for certain operations and don't document the guaranteed precision either, at which point you're left guessing and saying "well, I guess I should treat floats as magic in this case after all". I added "it's not imprecision" to step around this whole question.

> Then, when it fails [...], you can either poke it in the right ways or change your program in the right ways so that it works for you again. This is a horrible way to program; it’s all alchemy and guesswork and you need to become deeply specialized about the nuances of a single [...] implementation

In that post, the blanks reference a compiler’s autovectorizer. But you know what they could also reference? An aggresively opaque and undocumented, very complex CPU or GPU microarchitecture. (Cf. https://purplesyringa.moe/blog/why-performance-optimization-is-hard-work/.)

That feeling seems common in hindsight. Everything seems easier, once all the problems have been solved. Related, I enjoy the author's sense of humor:

> I made a prototype and, lo and behold, it was in fact slow, as predicted. (I’m smart.)

And in another article[0], describing an inefficient collision algorithm:

> Mojang’s decision never crossed my mind. I guess I’m not a real programmer.

[0]: https://purplesyringa.moe/blog/ru/minecraft-compares-arrays-in-cubic-time/