31–40 of 55 posts
> 0.1 + 0.1 + 0.1 == 0.3 False I always tell my students that if they (might) have a float, and are using the `==` operator, they're doing something wrong.
But I regret not making an exception for the constant zero, because it's one of the cases where you probably should accept it. I.e. if (f != 0.0) {...}
Earlier quoted context omitted.
.125 + .375 == .5 You should be using == for floats when they're actually equal. 0.1 just isn't an actual number.
Are you saying that my students should memorize which numbers are actual floats and which are not? > 1.25 * 0.1 0.1250000000000000069388939039
Yes.
Earlier quoted context omitted.
That has more to do with decimal binary conversion than arithmetic/comparison. Using hex literals makes it clearer 0x1.999999999999ap-4 ("0.1") +0x1.999999999999ap-4 ("0.1") --------------------- =0x3.3333333333334p-4 ("0.2") +0x1.999999999999ap-4 ("0.1") --------------------- =0x4.cccccccccccf0p-4 ("0.30000000000000004") !=0x4.cccccccccccccp-4 ("0.3")
Absolutely nobody will think this is 'clearer', this is a leaky abstraction and personally I think that the OP is right and == in combination with floating point constants should be limited to '0' and that's it.
The only leaky abstraction here is our bias towards decimal. (Fun fact: "base 10" is meaningless, because every base calls itself base 10)
One thing that really did it for me was programming something where you would normally use floats (audio/DSP) on a platform where floats were abysmally slow. This forced me to explore Fixed-Point options which in turn forced me to explore what the differences to floats are.
Fixed point gave rise to the old programmers meme 'if you need floating point you don't understand your problem'. It's of course partially in jest but there is a grain of truth in it as well.
The gag here being that perhaps that isn’t the best dividing line for programming talent.
> 0.1 + 0.1 + 0.1 == 0.3 False I always tell my students that if they (might) have a float, and are using the `==` operator, they're doing something wrong.
I have a linter in my code that shouts at me if I use exact equality for floats. But I regret not making an exception for the constant zero, because it's one of the cases where you probably should accept it. I.e. if (f != 0.0) {...}
The linter wouldn't know where f came from, so it should flag all floating point equality cases, and have some way that you can annotate it for "yeah this one is okay."
Earlier quoted context omitted.
.125 + .375 == .5 You should be using == for floats when they're actually equal. 0.1 just isn't an actual number.
Are you saying that my students should memorize which numbers are actual floats and which are not? > 1.25 * 0.1 0.1250000000000000069388939039
> 0.1 + 0.1 + 0.1 == 0.3 False I always tell my students that if they (might) have a float, and are using the `==` operator, they're doing something wrong.
Earlier quoted context omitted.
.125 + .375 == .5 You should be using == for floats when they're actually equal. 0.1 just isn't an actual number.
Are you saying that my students should memorize which numbers are actual floats and which are not? > 1.25 * 0.1 0.1250000000000000069388939039
Earlier quoted context omitted.
.125 + .375 == .5 You should be using == for floats when they're actually equal. 0.1 just isn't an actual number.
Are you saying that my students should memorize which numbers are actual floats and which are not? > 1.25 * 0.1 0.1250000000000000069388939039
Earlier quoted context omitted.
I have a linter in my code that shouts at me if I use exact equality for floats. But I regret not making an exception for the constant zero, because it's one of the cases where you probably should accept it. I.e. if (f != 0.0) {...}
Zero shouldn't be an exception there. If f had been set from something like f = a - b, then you're in the same situation where f might be almost but not exactly zero. The linter wouldn't know where f came from, so it should flag all floating point equality cases, and have some way that you can annotate it for "yeah this one is okay."