Earlier quoted context omitted.
Because they are equal in real math
Floats are not real numbers though
[deleted]
In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
41–50 of 236 posts
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#42Earlier quoted context omitted.
In case of floating points, since they are an approximation, zero is not zero. Zero is a quantity approaching to zero. In fact dividing by zero with floats is entirely possible! (it leads to infinite, positive or negative depending on the sign). For example, the quantity (try it in Python): 0.1 ** 100 / 1000**100 evaluates to 0.0 while the quantity 0.1 ** 100 / (-1000**100) evaluates to -0.0 It's clear that neither t…
> no division can produce a result that is exactly zero Except 0 / n
Or -0.0 / n, for what it's worth, at which point these zeroes will not be equal to one another.
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#43This feels like a bad idea. Treating +0 and -0 as unequal because they have different bit patterns is no more correct than treating two NaNs as equal because they have the same bit pattern. Zero is zero.
What Every Programmer Should Know About Floating-Point Arithmetic
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#44As 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.
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#45Earlier quoted context omitted.
Because they are equal in real math
Floats are not real numbers though
They are a way of approximating Real (the set not as an adjective) numbers, though. Real numbers are exact when they are equal to an integer or a rational, because, depending on how you construct them, either that's what the cut contains or that's where the series converges.
And also because that's what the most common spec demands.
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#46Earlier quoted context omitted.
Are there even any applications where one needs a) decimal precision and b) fast computation? Financial calculations don't need to be fast.
Algorithmic trading, of course. High-frequency trading in particular. But any trading, in fact, when you run simulations for thousands of instruments and search among millions of parameters. Or when you implement an exchange, or route orders between exchanges according to their complicated criteria. Or when you do options pricing. Basically, everything in this field.
[deleted]
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#47As 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
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.
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#48As 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
I'm assuming you mean equality comparison, rather than comparison in general!
but is there a better algebraic structure to use when thinking of floats? like, in terms of limits, or something that tracks significant digits and uncertainty? how do formal methods handle these?
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#49As 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
Since they're not changing ==, I wouldn't think == would change. Note, Erlang has a no arrow looking comparison rule, so [1] https://www.erlang.org/doc/reference_manual/expressions.html...
Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0
#50As 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.
The problem with defining an “epsilon” (1% in your case) is that there is no value that would please everyone. For some, 1% will be fine, but others may need 0.0001%.
The solution is to either use decimal floats if they suit your need (and eat the performance penalty), or to use a linter that flags float comparisons by equality.