181–190 of 236 posts
There is a huge misconception here which really should be clarified in the title. Erlang has an "exactly equal" or strict equality operator, called =:=, which is different from just usual equality, which is ==. The usual equality operator will keep having +0.0 = -0.0, and floating point arithmetic will keep behaving as you would expect... It's that we no longer have +0.0 =:= -0.0, which is a very different thing (and…
Reading the article is what clarifies things. HN is full of people who think the world needs their hot take based on a headline, unfortunately.
As a general rule, if you find yourself comparing floating point numbers, that's probably not what you want. I'm wondering what they are going to do with other operators, >=, <= etc
It is 2023 and our tooling still encourages the same mistakes people were making 40 years ago. Can we really not have equality operators that do a comparison with a 1% tolerance or something as a sensible default equivalence instead of blatantly wrong bitwise comparison? I would even be happy with a default set of compiler warnings or errors, which I don’t believe I have ever seen.
Then it wouldn't really be an equality comparison any more. For instance according to your rule 1.0 and 1.01 are the same number, but they clearly are not. But if you want to do this regularly you could create a special type and overload the equality operator (if your language supports it, otherwise you'll have to call the function directly) that points to 'boolean about_equal(float f1, float f2, float epsilon)' or something equivalent where epsilon is the amount that you would allow f1 and f2 to deviate from each other to still call them equal. And you could define epsilon as ((abs(f1) + abs(f2)) / 100) .
The bitwise comparison isn't 'blatantly wrong', it's the expected behavior in just about every programming language. I'm not aware of any language that has a native float operator that does this but as you can see you can usually simply add one yourself if you really need it. But this need rarely comes up and usually indicates that you are doing something wrong.
I would have guessed that a backwards incompatible change like that is a big release thing. Even if it affects a tiny tiny group
As a general rule, if you find yourself comparing floating point numbers, that's probably not what you want. I'm wondering what they are going to do with other operators, >=, <= etc
We don't have fast hardware decimals, except on IBM mainframes. So, if you need fast financial calculations which are too complicated for integers (e.g. gasp division), you usually use decimally-normalized doubles and do it very very carefully. This is a sad state of affairs, but nobody was fixing this in the last 30 years, so there's that.
Earlier quoted context omitted.
> I've always held that the numbers themselves are perfectly precise. It's the operations that don't do what you expect. I think that this is an oversimplification, and misses a key point. Floating point numbers can be interpreted in (at least) two distinct ways. In one use model, floating point numbers allow a sparse representation of selected points on the (extended) real number line. In this model, the numbers the…
the problem is the second interpretation is wrong. for example, exp(x) would give a higher value than it does since the average value of the exponent of a range is higher than the exponent of it's center.
Earlier quoted context omitted.
I've always held that the numbers themselves are perfectly precise. It's the operations that don't do what you expect. Of course, that observation may be more or less useful, depending on circumstances.
How do you define numbers in a meaningful way without involving operators? Without operators, all you have is a set of objects which you can't tell apart.
Earlier quoted context omitted.
Somewhere in the distant past a second grade me is staring at his math homework and fuming over the frustratingly ambiguous meaning of the minus sign. Is it an operator? A property? Both?
We could make the minus sign go away if we adopted a balanced base (e.g. balanced ternary), that has both negative and positive digits. That way, just looking at the digits would make evident if a number is positive or negative, without any need for a minus sign.
Earlier quoted context omitted.
well you shouldn't expect much if you are comparing floats to doubles
True, but it's an easy mistake to make.
In Rust if we insist we want to compare an f32 (what C would call float) to an f64 (double), the language says it doesn't have a way to do that, highlighting our mistake. If we just try to compare an f32 with value 0.7 against 0.7, the type inference concludes 0.7 is also an f32 so it's equal, and if we do the same with an f64, this time by inference 0.7 is an f64 and so again it's equal.
Earlier quoted context omitted.
Do you just plan to save your money in dollar bills hidden inside a pillow until you retire? If you want to invest it in any way, you probably want to avoid floating point numbers for keeping track of it.
I'd prefer living in a world where social security is enough for me not to worry about things like "saving money".