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

141–150 of 236 posts

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

#141

Post by Kamq »

derefr wrote: post #122
2h wrote: post #120

Earlier quoted context omitted.

not sure what you hoped to accomplish with that. yes all documents are a byte array. this is not the same thing a the STRING type. this JSON document: 0 and this JSON document: 0.0 might compose a different stream of bytes, but by your own admission, they get parsed as the same type and value, 0. the only way to distinguish the difference in a parsed document, would be to present a string type as the input document:…

> so your comments have only proven that some strings are different than others Er... yes? What I'm trying to do here, is to provide an intuition for how IEEE754 bit patterns should be mentally modeled. They're byte-arrays that encode a semantic type, like a JSON document is a byte-array that encodes a semantic type. And, just like `"0"` and `"0.0"` are different encodings of the same JSON-semantic Number, IEEE754 -0…

> there's no such thing as "decoding" IEEE754 to something else.

Huh? You can totally take the raw bytes in an IEEE754 floating point number and parse them into something else (say, a decimal type) the same way you can take the raw bytes of a JSON document and parse it into a struct.

It's a lossy encoding for reals.

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

#142

Post by fijiaarone »

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

There is no negative zero

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

#143

Post by MarekKnapek »

What about NaN? Does Erlang have NaN? How does Erlang compare two variables containing a NaN (or expressions evaluating to a NaN)? There are (2^24)-2 different NaNs in a 32bit IEEE 754 float, and there are (2^53)-2 different NaNs in a 64bit IEEE 754 double. The IEEE 754 standard says, that a NaN value should compare to any other number (including any other NaN) as not equal. Yes, the expression `x == x` could return `false`.

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

#144

Post by klodolph »

MarekKnapek wrote: post #143

What about NaN? Does Erlang have NaN? How does Erlang compare two variables containing a NaN (or expressions evaluating to a NaN)? There are (2^24)-2 different NaNs in a 32bit IEEE 754 float, and there are (2^53)-2 different NaNs in a 64bit IEEE 754 double. The IEEE 754 standard says, that a NaN value should compare to any other number (including any other NaN) as not equal. Yes, the expression `x == x` could return…

Erlang has =:= and ==. Kind of like how Python has is and ==, JavaScript has == and ===, and Lisp has eq, eql, and equal.

The change in the article is about =:=, so NaN =:= NaN does not have to give the same answer as NaN == NaN.

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

#145

Post by pclmulqdq »

adastra22 wrote: post #130
pclmulqdq wrote: post #106

Earlier quoted context omitted.

+/-0 often indicates an underflow on one side of 0 or the other. Certainly in real terms 1/(infinity) != -1/(infinity).

You are overloading the word “real”. In terms of the mathematics of the reals, there is no difference. In terms of real-life pragmatics, 0 and -0 could be used to differentiate between different outcomes in a way that is sometimes useful.

Infinity and -0 are not in the real numbers, so the expression there makes no sense if you are thinking strictly in the real numbers. If you assign real number bounds to what the floating point numbers mean, the expressions make sense.

In floating point terms infinity tends to indicate overflow (any number that is too big to represent) and the 0's indicate underflows. So in more verbose terms,

1/(positive overflow) = (positive underflow)

While

-1/(positive overflow) = (negative underflow)

In this case, since the positive overflow isn't really infinity and the underflows aren't really 0, they are not equal. In practice, -0 and the 0 can both also arise from situations that produce 0 exactly, too, but this is not that case.

You may be thinking about how lim{x->inf}(1/x) = 0 = lim{x->inf}(-1/x), which is true. Infinity in floating point does not necessarily represent that limit, though, just any number that is too big.

You may also notice that the limit is not in the range of the functions inside the limit. For all real x, 1/x != 0

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

#146

Post by Conscat »

thr-nrg wrote: post #72
ChainOfFools wrote: post #67

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?

Math notation is to mathematics as poetry is to English. The only acceptable grammar for math is s-expressions.

Well, idiomatic C++23 is an acceptable math notation too.

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

#147

Post by spacechild1 »

bee_rider wrote: post #134
spacechild1 wrote: post #92

Earlier quoted context omitted.

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?

I can certainly imagine cases where this would make sense.

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

#148

Post by princeb »

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

1/0 is undefined and 1/-0 is also undefined.

what we have is lim(x->0+) 1/x = +inf and lim(x->0-) 1/x = -inf

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

#149

Post by layer8 »

Trufa wrote: post #68
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…

What’s the use case for different values?

Preserving the sign in case of arithmetic overflow/underflow.

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

#150

Post by adastra22 »

pclmulqdq wrote: post #145
adastra22 wrote: post #130

Earlier quoted context omitted.

You are overloading the word “real”. In terms of the mathematics of the reals, there is no difference. In terms of real-life pragmatics, 0 and -0 could be used to differentiate between different outcomes in a way that is sometimes useful.

Infinity and -0 are not in the real numbers, so the expression there makes no sense if you are thinking strictly in the real numbers. If you assign real number bounds to what the floating point numbers mean, the expressions make sense. In floating point terms infinity tends to indicate overflow (any number that is too big to represent) and the 0's indicate underflows. So in more verbose terms, 1/(positive overflow) =…

We are saying the same thing.
Post reply on HN