757
Stop using floats
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Feb 2024
757 points (95.8% liked)
Programmer Humor
19564 readers
605 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
I have been thinking that maybe modern programming languages should move away from supporting IEEE 754 all within one data type.
Like, we've figured out that having a
nullvalue for everything always is a terrible idea. Instead, we've started encoding potential absence into our type system withOptionorResulttypes, which also encourages dealing with such absence at the edges of our program, where it should be done.Well,
NaNisnullall over again. Instead, we could make the division operator an associated function which returns aResult<f64>and disallowf64from ever beingNaN.My main concern is interop with the outside world. So, I guess, there would still need to be a IEEE 754 compliant data type. But we could call it
ieee_754_f64to really get on the nerves of anyone wanting to use it when it's not strictly necessary.Well, and my secondary concern, which is that AI models would still want to just calculate with tons of floats, without error-handling at every intermediate step, even if it sometimes means that the end result is a shitty vector of
NaNs, that would be supported with that, too.Nan isn't like null at all. It doesn't mean there isn't anything. It means the result of the operation is not a number that can be represented.
The only option is that operations that would result in nan are errors. Which doesn't seem like a great solution.
It doesn't have to "error" if the result case is offered and handled.
Float processing is at the hardware level. It needs a way to signal when an unrepresented value would be returned.
My thinking is that a call to the safe division method would check after the division, whether the result is a
NaN. And if it is, then it returns an Error-value, which you can handle.Obviously, you could do the same with a
NaNby just throwing an if-else after any division statement, but I would like to enforce it in the type system that this check is done.I feel like that's adding overhead to every operation to catch the few operations that could result in a nan.
But I guess you could provide alternative safe versions of float operations to account for this. Which may be what you meant thinking about it lol
I would want the safe version to be the default, but yeah, both should exist. ๐