this post was submitted on 26 Feb 2024
748 points (95.7% liked)

Programmer Humor

19817 readers
878 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

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
748
Stop using floats (lemmy.world)
submitted 10 months ago by nifty to c/[email protected]
85 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 6 points 10 months ago (2 children)

Well, that is what I meant. That NaN is effectively an error state. It's only like null in that any float can be in this error state, because you can't rule out this error state via the type system.

Why do you feel like it's not a great solution to make NaN an explicit error?

[–] [email protected] 2 points 10 months ago (1 children)

Theres plenty of cases where I would like to do some large calculation that can potentially give a NaN at many intermediate steps. I prefer to check for the NaN at the end of the calculation, rather than have a bunch of checks in every intermediate step.

How I handle the failed calculation is rarely dependent on which intermediate step gave a NaN.

This feels like people want to take away a tool that makes development in the engineering world a whole lot easier because "null bad", or because they can't see the use of multiplying 1e27 with 1e-30.

[–] [email protected] 1 points 10 months ago (1 children)

Well, I'm not saying that I want to take tools away. I'm explicitly saying that a ieee_754_f64 type could exist. I just want it to be named annoyingly, so anyone who doesn't know why they should use it, will avoid it.

If you chain a whole bunch of calculations where you don't care for NaN, that's also perfectly unproblematic. I just think, it would be helpful to:

  1. Nudge people towards doing a NaN check after such a chain of calculations, because it can be a real pain, if you don't do it.
  2. Document in the type system that this check has already taken place. If you know that a float can't be NaN, then you have guarantees that, for example, addition will never produce a NaN. It allows you to remove some of the defensive checks, you might have felt the need to perform on parameters.

Special cases are allowed to exist and shouldn't be made noticeably more annoying. I just want it to not be the default, because it's more dangerous and in the average applications, lots of floats are just passed through, so it would make sense to block NaNs right away.

[–] [email protected] 1 points 10 months ago

What do you do about a dataset which contains 11999 fine numbers, but one of them is NaN because George called in sick that week? Throw away the whole dataset because it doesn't fit the data type?

[–] [email protected] 1 points 10 months ago

idk if you ever had to actually work with floats,

but in statistics, you deal with NaNs all the time. Data is absent from the data set. If it would be an error every time, you wouldn't get anything done.