Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

erlangforums.com

Post reply on HN
Print view View original

231–236 of 236 posts

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#231

Post by kragen »

spacechild1 wrote: post #226
tialaramex wrote: post #189

Earlier quoted context omitted.

It's an easy mistake to make in C (and C++) because of their lackadaisical approach to type safety. 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 wit…

Rust's behavior makes so much more sense! IMO, implicit conversions is one of C++ biggest weaknesses. Yes, it may save some keystrokes, but it can easily lead to subtle (or not so subtle) bugs.

agreed

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#232

Post by chubot »

kragen wrote: post #205
chubot wrote: post #202

Earlier quoted context omitted.

Fortran would be an interesting case, because say C++ is polymorphic, and so are all dynamic programming languages with more than 1 type (x == y could be a string or float comparison) But I would still say that floating point equality is a vanishingly rare operation I can't think of any real use case for it, other than maybe some (bad, incomplete) unit tests that assert 1.0 == x and assert 1.0 == y And that use case…

i gave some examples in https://news.ycombinator.com/item?id=35883963 , though arguably those are not very concrete. also i pointed out there why unit tests that use exact comparison on floats are not necessarily bad: ieee-784 specifies bit-exact results for the five fundamental arithmetic operations, and if your compiler is introducing rounding errors, you want your tests to fail. (or introducing nonerrors, in the c…

Thanks for actually going and looking! I would say that this supports the idea of float_equals(x, 0.0) or even float_equals_zero(x) :)

It wouldn't be too surprising to me if 90% of float equalities in real code are comparisons to 0.0 or 1.0 or -1.0 (that's what I meant in my original post, there was a typo)

The point about x >= 0 and x ---

The other point is that it looks like the Fortran code isn't actually using == or x.eq.zero polymorphically!

So the first point is that I would want to understand conceptually where float equality would be equal. You mentioned fixed points, although there I also suspect that abs(x - y) The second point is -- would any of those situations be polymorphic with int and float, or string and float? It depends on the language, but it seems vanishingly unlikely in most languages, and in particular in say in C++

I would probably go look at the equivalent Eigen code if it mattered with respect to Oil, but it probably doesn't

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#233

Post by kragen »

chubot wrote: post #232
kragen wrote: post #205

Earlier quoted context omitted.

i gave some examples in https://news.ycombinator.com/item?id=35883963 , though arguably those are not very concrete. also i pointed out there why unit tests that use exact comparison on floats are not necessarily bad: ieee-784 specifies bit-exact results for the five fundamental arithmetic operations, and if your compiler is introducing rounding errors, you want your tests to fail. (or introducing nonerrors, in the c…

Thanks for actually going and looking! I would say that this supports the idea of float_equals(x, 0.0) or even float_equals_zero(x) :) It wouldn't be too surprising to me if 90% of float equalities in real code are comparisons to 0.0 or 1.0 or -1.0 (that's what I meant in my original post, there was a typo) The point about x >= 0 and x --- The other point is that it looks like the Fortran code isn't actually using ==…

yeah, i also wrote a cube root routine using newton's method yesterday and came to the conclusion that |x - x'| i agree that prefix notation is not as bad for these as i had thought before looking

i think there are plausible cases where your float might be polymorphic with double, complex, a vector, a matrix, or an element of a galois field, but i think it would only be polymorphic with int in cases like stopping change propagation when an observable value gets recomputed to the same value from new inputs, and in those cases what you need is exact bitwise equality, not arithmetic equality

an awk-like thing might be better with fixed-point, like tex and metafont; you could call the data type 'btc` and represent it as a 64-bit integer that's multiplied by 10*-8 for output

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#234

Post by tialaramex »

kragen wrote: post #227
tialaramex wrote: post #224

Earlier quoted context omitted.

> no pattern could ever match a term containing a floating point number? No equivalence matching on floating point numbers seems like a much healthier approach, yes. I don't expect people to have huge problems with "x greater than 0.0" or "z less than 16.35" but "p is exactly 8.9" suggests muddled thinking. The floats are very strange. While machine integers are already a bit weird compared to the natural numbers we…

as documented in https://news.ycombinator.com/item?id=35889463 this would prevent you from translating lapack into your ideal language you have to get rid of order comparisons too, though, or people will just replace a == b with a >= b && a also it seems like a compiler attempting to determine whether two pieces of code are equivalent (so it can throw one away) needs to be able to test whether two constants in them c…

My fear isn't about floating point equality but about equivalence. As we discussed repeatedly, nothing changed for equality, -0.0 = 0.0 just as -0 = 0 in integers. Equality works fine, though it may be surprising in some cases for floating point values because sometimes a != a and b + 1 == b.

"Exact-bitwise-equality" is yet a further different thing from equivalence. Is this what Erlang's =:= operator does? Erlang's documentation described it as "Exactly equal to" which is a very silly description (implying maybe == is approximately equal to), presumably there's formal documentation somewhere which explains what they actually meant but I didn't find it.

Presumably Exact-bitwise-equality is always defined in Erlang? In a language like Rust or C++ that's Undefined in lots of cases so this would be a terrible idea. I still think it's better not to prod this particular dragon, but you do you.

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#235

Post by dang »

freddie_mercury wrote: post #119
ComplexSystems wrote: post #54

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.

"Please don't sneer, including at the rest of the community." It's reliably a marker of bad comments and worse threads.

https://news.ycombinator.com/newsguidelines.html

Re: In Erlang/OTP 27, +0.0 will no longer be exactly equal to -0.0

#236

Post by epgui »

atemerev wrote: post #204
justeleblanc wrote: post #196

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Communism

Well, prepare the firing squads! What the world definitely needs is more fire squads, I presume.

I’m not a fan of the response either, but that’s a bit disingenuous.
Post reply on HN