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

221–230 of 236 posts

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

#221

Post by alerighi »

2h wrote: post #111
alerighi wrote: post #24

Earlier 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…

> Zero is a quantity approaching to zero no, its not. zero is zero, its nothing. "a quantity approaching to zero" is "a quantity approaching to zero". its easy to remember because zero is not a quantity, its a lack of quantity, by definition. these are two distinct concepts, which some people mistake as the same item.

Not with floating point numbers.

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

#222

Post by kragen »

nawgz wrote: post #214
kragen wrote: post #211

Earlier quoted context omitted.

you seem to be confusing the decimal system of representation with platonic abstract numbers, which is what gives rise to the apparent disagreement

Do I? I think people are speaking shockingly imprecisely in this thread. here's my claim: > Arithmetic (between two decimal numbers) is clearly not lossy in and of itself, only as implemented with computers Counterarguments are basically on the level of "you cant represent Pi as a finite decimal number", which I find uninteresting.

that's slightly incoherent and reflective of the same confusion i identified; there is strictly speaking, no such thing as a decimal number, only a decimal numeral. normally the difference is subtle, but in this case it's the essence of the issue

'decimal' means 'base 10'

numbers, the abstract entities we do arithmetic on, are not decimal or in any other base; it is correct that arithmetic on them is not in any sense lossy

decimal is a system of representation that represents these abstract numbers as finite strings of digits; these are called 'numerals'. it can represent any integer, but only some fractions, those whose denominator has no prime factors other than 2 or 5. such fractions arise non-lossily as the result of the arithmetic operator of division when, for example, the dividend is 3. representing these in decimal requires rounding them, so decimal is lossy

binary floating point is lossy in the same way, with the additional limitation to only being able to represent fractions whose denominator is a power of 2, whose numerator does not have too many significant bits (53 most often), and which are not too positive, too negative, or too small

there are other systems of represention for numbers that are not lossy in this way. for example, improper fractions, mixed numbers, finite continued fractions, and decimal augmented with overbar to indicate repeated digits

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

#223

Post by kragen »

tialaramex wrote: post #219
kragen wrote: post #209

Earlier quoted context omitted.

it's using the =:= operator you say it should be using, not the == operator you incorrectly say it is using however, that operator was originally defined incorrectly, and now they are fixing that bug

So far the only example I've been given of this operator is that it's what the compiler uses to decide equivalence, which is a situation where the correct answer was categorically no. The belief seems to be that this code is fine if we mistakenly unify cases where we think the IEEE floating point number had the same representation, and I don't buy that this is better than unifying -0.0 and 0.0 in the example, I think…

i think the belief is rather that the compiler needs to reliably distinguish between -0 and +0 except where it explicitly invokes arithmetic comparison, and so the semantics of both =:= and unification should change to distinguish -0 from +0

i don't know what it would mean to not unify cases where the ieee floating point number had the same representation, assuming that by 'unify' you mean 'paattern-match) (erlang doesn't have full bidirectional unification where run-time data can contain variables which could be instantiated with constants from a pattern). what would the semantics of unification be then? no pattern could ever match a term containing a floating point number?

or perhaps you aren't aware that 'unify' means 'pattern-match' (prolog style) and we are discussing a pattern-matching bug, and by 'unify cases' you just mean 'remove one of two cases'. i think it's very likely that the compiler needs to remove redundant cases that fall out of its optimizer in order to get decent performance, and if the user puts them in their code it's probably a bug

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

#224

Post by tialaramex »

kragen wrote: post #223
tialaramex wrote: post #219

Earlier quoted context omitted.

So far the only example I've been given of this operator is that it's what the compiler uses to decide equivalence, which is a situation where the correct answer was categorically no. The belief seems to be that this code is fine if we mistakenly unify cases where we think the IEEE floating point number had the same representation, and I don't buy that this is better than unifying -0.0 and 0.0 in the example, I think…

i think the belief is rather that the compiler needs to reliably distinguish between -0 and +0 except where it explicitly invokes arithmetic comparison, and so the semantics of both =:= and unification should change to distinguish -0 from +0 i don't know what it would mean to not unify cases where the ieee floating point number had the same representation, assuming that by 'unify' you mean 'paattern-match) (erlang do…

> 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 learned in school, the floats are much stranger so I expect code which is trying to test equivalence on these values is going to keep running into trouble.

We know that humans, including human programmers, do not appreciate how weird floats really are, so I think telling programmers they just can't perform these matches will have a better outcome than confusing them by allowing this and then it rarely has totally unexpected consequences because a+epsilon was equivalent to b even though mathematically a+epsilon != b

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

#225

Post by spacechild1 »

kragen wrote: post #160
spacechild1 wrote: post #79

Earlier quoted context omitted.

In general, this is good advice. However, there are cases where comparing floating point numbers for equality works just fine. For example, if you have a variable 'v' and want to update it to a new value 'f', you can do 'if (v == f)' to check if the variable would change. Or if you have a sentinel value -1.0, it is perfectly ok to do 'if (a == -1.0)' In general, if you look for a number 'f' in variable 'v', you can s…

cesaref's comment is not good advice, it's not advice at all, it's a snarky take on how floating point is trickier than it looks almost invariably floating-point calculations end up in some kind of comparison; if they didn't we'd probably do the calculations in a galois field or something instead even equality comparison of floats is useful; there are an abundance of seminumerical algorithms which use it correctly on…

> almost invariably floating-point calculations end up in some kind of comparison

I'm pretty sure OP meant comparison for equality, not comparison in general (which would be absurd, indeed).

> even equality comparison of floats is useful

That's exactly what I tried to point out. However, these are really special cases and you need to be careful and know what you are doing.

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

#226

Post by spacechild1 »

tialaramex wrote: post #189
spacechild1 wrote: post #177

Earlier quoted context omitted.

True, but it's an easy mistake to make.

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.

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

#227

Post by kragen »

tialaramex wrote: post #224
kragen wrote: post #223

Earlier quoted context omitted.

i think the belief is rather that the compiler needs to reliably distinguish between -0 and +0 except where it explicitly invokes arithmetic comparison, and so the semantics of both =:= and unification should change to distinguish -0 from +0 i don't know what it would mean to not unify cases where the ieee floating point number had the same representation, assuming that by 'unify' you mean 'paattern-match) (erlang do…

> 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 could ever produce different computational results; this is important for code-movement optimizations and for reunifying the profligate results of c++ template expansion

similarly, a dataflow framework like observablehq needs to be able to tell if an observable-variable update needs to propagate (because it could change downstream results) or not; for that purpose it needs to even be able to distinguish different nans. like the compiler, it needs the exact-bitwise-equality relation rather than ordinary arithmetic equality

where i think we agree is that floating-point arithmetic is probably a bad default for most people most of the time because it brings in all kinds of complexity most programmers don't even suspect

your comment reads to me as 'i don't understand floating point equality and therefore no human does so no human should have access to it'

but there are more things in heaven and earth than are dreamed of in your philosophy, tialaramex

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

#228

Post by kragen »

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…

see also https://news.ycombinator.com/item?id=35902861 for more examples

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

#229

Post by kragen »

kragen wrote: post #222
nawgz wrote: post #214

Earlier quoted context omitted.

Do I? I think people are speaking shockingly imprecisely in this thread. here's my claim: > Arithmetic (between two decimal numbers) is clearly not lossy in and of itself, only as implemented with computers Counterarguments are basically on the level of "you cant represent Pi as a finite decimal number", which I find uninteresting.

that's slightly incoherent and reflective of the same confusion i identified; there is strictly speaking, no such thing as a decimal number, only a decimal numeral. normally the difference is subtle, but in this case it's the essence of the issue 'decimal' means 'base 10' numbers, the abstract entities we do arithmetic on, are not decimal or in any other base; it is correct that arithmetic on them is not in any sense…

this should read 'when, for example, the divisor is 3 and the dividend is an integer not divisible by 3'

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

#230

Post by kragen »

spacechild1 wrote: post #225
kragen wrote: post #160

Earlier quoted context omitted.

cesaref's comment is not good advice, it's not advice at all, it's a snarky take on how floating point is trickier than it looks almost invariably floating-point calculations end up in some kind of comparison; if they didn't we'd probably do the calculations in a galois field or something instead even equality comparison of floats is useful; there are an abundance of seminumerical algorithms which use it correctly on…

> almost invariably floating-point calculations end up in some kind of comparison I'm pretty sure OP meant comparison for equality, not comparison in general (which would be absurd, indeed). > even equality comparison of floats is useful That's exactly what I tried to point out. However, these are really special cases and you need to be careful and know what you are doing.

i think he was snarkily making an absurd comment for the humor value
Post reply on HN