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

131–140 of 236 posts

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

#131

Post by fatneckbeard »

derefr wrote: post #113
2h wrote: post #110

Earlier quoted context omitted.

there is no such thing as -0. if you want to say "zero approaching from negative one", fine, say that. but that IS NOT the same thing as -0. zero is just zero, it doesn't have a sign. some people just want everything to fit in a nice neat box, and sometimes folks, life is not like that. this is an awful change, injecting meaning where there is no room for it.

-0 exists. It's just not a mathematical object. It's an IEEE754 signed-magnitude bit-pattern — one that is distinct from the IEEE754 signed-magnitude bit-pattern we call +0. Both of these bit-patterns encode the semantic meaning of the mathematical object 0; but that doesn't mean that the bit patterns are the same "thing." Compare/contrast: the JSON document "0" vs the JSON document "0.0". Both encode the same type (…

dealing with the same thing in rust, you can't use float in a lot of equality places where you can use ints, and they are moving to change match so you can't use floats in patterns there either.

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

#132

Post by distortedsignal »

sebzim4500 wrote: post #109
munk-a wrote: post #100

Earlier quoted context omitted.

Honestly - I rather dislike this change. I'd much rather have 0 & -0 be precisely equal to each other and have some obscure library function like `isNegativeZero` for the extremely rare cases they'd need to be differentiated. 0 and -0 being distinct values is honestly just an accident of convenience with how floats are stored - there are two bit patterns that result in a value of 0 but because they're different patte…

I don't think it's just that. 1/0 is infinity but 1/(-0) is -infinity

Shouldn't both of those be NaN? Does Erlang have a NaN?

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

#133

Post by franknord23 »

distortedsignal wrote: post #132
sebzim4500 wrote: post #109

Earlier quoted context omitted.

I don't think it's just that. 1/0 is infinity but 1/(-0) is -infinity

Shouldn't both of those be NaN? Does Erlang have a NaN?

IIRC division by zero throws an exception.

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

#134

Post by bee_rider »

spacechild1 wrote: post #92
stouset wrote: post #84

Earlier quoted context omitted.

> 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. Isn't it strictly faster to simply assign? No branching, no branch predictions, only one instruction in all cases.

A typically pattern is: float freq = getParameter(FILTER_FREQUENCY); float coeff; if (freq != mFreq) { coeff = calculateCoeffFromFrequency(freq); // expensive mFreq = freq; mCoeff = coeff; } else { coeff = mCoeff; // use cached value } // use coeff

Could you do some threshold-based comparison? What if freq is changed only a little tiny bit?

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

#135

Post by int_19h »

mamcx wrote: post #62
cubefox wrote: post #30

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

Business apps? Like all of them? As matter of fact, business apps are by far the longest portion of the apps. Just considering all spreadsheets, almost all RDBMS, etc alone. Binary Floating-point is what is ACTUALLY niche. And it not look like it just because is the default, similar how in certain niches "0" is "true".

Most business apps don't do anywhere near enough compute that it matters.

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

#136

Post by moonchild »

munk-a wrote: post #100
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…

Honestly - I rather dislike this change. I'd much rather have 0 & -0 be precisely equal to each other and have some obscure library function like `isNegativeZero` for the extremely rare cases they'd need to be differentiated. 0 and -0 being distinct values is honestly just an accident of convenience with how floats are stored - there are two bit patterns that result in a value of 0 but because they're different patte…

> 0 and -0 being distinct values is honestly just an accident of convenience with how floats are stored

That's not at all true. The inclusion of negative zero in ieee 754 was a deliberate design choice, and if it were considered desirable that zero should be unsigned, then the bit pattern assigned to -0 would not have been so assigned. See 'much ado about nothing's sign bit'[0], by one of the principal authors of ieee 754.

Whereas -0 and +0 are not operationally equivalent, operational equivalence is an important and useful relation; see the very pattern matching example linked from the OP[1].

0. https://people.freebsd.org/~das/kahan86branch.pdf

1. https://erlangforums.com/t/total-term-order/2477/41

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

#137

Post by bee_rider »

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…

So, in Erlang it will be the case that:

+0.0 == -0.0 is true, I guess because they are very close

+0.0 =:= -0.0 is false, I guess because they have different bits

A =:= B for two different numbers of course, because they have different bits

How does == work for other very close floating point values in Erlang? Is there some inconsistency here?

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

#138

Post by lolcatuser »

distortedsignal wrote: post #132
sebzim4500 wrote: post #109

Earlier quoted context omitted.

I don't think it's just that. 1/0 is infinity but 1/(-0) is -infinity

Shouldn't both of those be NaN? Does Erlang have a NaN?

The reason division by zero can be a number is that floating-point numbers aren't individual numbers but ranges of numbers. So 0.0 isn't really the integer 0, it is the range of numbers between 0 and the smallest representable non-zero number. So division by 0.0 may be division by zero, or it may be division by a very small number, in which case it would approach infinity.

The same goes for the floating-point infinity: it doesn't represent the concept of infinity, it is a placeholder for every number between the largest representable number and infinity. That's how dividing a very large number by a very small number can result in infinity, a number which is really not a number.

This is the philosophy by which IEEE floating-point numbers were designed, and it's the explanation behind which negative zeroes and infinities make sense in floating point.

The way I find it easiest to reason about is by taking a graph of an asymptote and rounding it to the nearest units. You somehow need a way to say "there is an asymptote here!" even though you might not have all the units, and so you introduce infinities and negative zeroes to maintain as much precision as possible.

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

#139

Post by longemen3000 »

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…

i don't use Erlang (mainly Julia), but this change makes a lot of sense. in Julia, there is the == operator (value equality) and the === operator (value egality). 0.0 == -0.0,because they have the same "value". but they aren't identical (the bits are different), so !(0.0 === -0.0).
Post reply on HN