Live data from Hacker News

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

erlangforums.com

101–110 of 236 posts

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

#101
post #83

Earlier quoted context omitted.

Every finite floating point value precisely represents an exact quantity. Arithmetic isn't lossless though. This isn't a special property of floats. Decimals behave the same way.

I was with you until the end First point: FPs are unique. Clearly true Second point: Combing FPs isn't lossless, across most/all arithmetic. Clearly true, the root of our discussion Third point: decimal arithmetic is lossy too. Strongly disagree. The system of representation is what is lossy - floating point. Arithmetic (between two decimal numbers) is clearly not lossy in and of itself, only as implemented with comp…

Decimal is only lossless if you track an indefinitely-growing suffix to your number with a big bar over it to indicate "repeating". It's basically working with rational numbers but more painful.

Decimal numbers with any limit on digits, even a hundred, are lossy.

Decimal numbers as used by humans outside of computers have limits on digits, so they are lossy.

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

#102
post #68

Earlier quoted context omitted.

What’s the use case for different values?

1/Infinity in 754 is 0. 1/(-Infinity) is -0. These numbers are not strictly equal in real number terms.

These numbers are inequal in terms of storage - in real number terms zero has no sign and thus -0 and +0 are the same number. The source of their distinction is also important as it's just a pure point of convenience at the bit level - there are two separate bit patterns for 0 but both numbers are the same number.

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

#103

Earlier quoted context omitted.

It's a natural consequence of the IEEE 754 standard for floating point numbers.

To be clear, it was added to the standard because there was user demand for it. Zero is already special cased in IEEE 754 (along with the rest of the denormals, because of the implied leading mantissa bit), the implementation would be no harder if you just only had a single zero. However, back when the standard was being created, when a single zero value was proposed there was pushback from people in the user communi…

> Many people think that negative zero is just an engineering artefact. This is not true, it is a feature that was asked for, debated, and then added...

Allowing zero to be represented with two bit patterns was a feature that was advocated for to make bit operations easier - it was not decided that both zeroes should be distinguishable. This absolutely is an engineering artifact but you're quite correct that it was quite intentional.

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

#104

Earlier quoted context omitted.

Or -0.0 / n, for what it's worth, at which point these zeroes will not be equal to one another.

Or 1e-100 / 1e300

Please refer back to "It's clear that neither the two quantities are 0 (no division can produce a result that is exactly zero!) but they approach the zero." because you just gave an example of how that rule is correct, not an exception.

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

#105

Earlier quoted context omitted.

By that logic there should be e.g. +4.0 and +4.0- (for when you go 4m forwards vs when you go 4m forwards but also turn around at the end).

In vector maths, this would just be +4.0.

And the same is true of zero.

Especially when you consider a two-dimensional vector. How would you encode/interpret facing in a complex zero?

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

#106
post #102

Earlier quoted context omitted.

1/Infinity in 754 is 0. 1/(-Infinity) is -0. These numbers are not strictly equal in real number terms.

These numbers are inequal in terms of storage - in real number terms zero has no sign and thus -0 and +0 are the same number. The source of their distinction is also important as it's just a pure point of convenience at the bit level - there are two separate bit patterns for 0 but both numbers are the same number.

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

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

#107

-0.0 = 0 +0.0 = 0 Hence -0.0 = +0.0 right ?

Yup - both of the bit patterns for 754 here were assigned the value of 0 and the standard instructed comparison operators to treat the two values as equal. The bit patterns for both -0.0 and +0.0 are assigned to the same real world value - there is no reason to distinguish them outside of circuits that actually execute floating point arithmetic.

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

#108
post #3

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

> I've always held that the numbers themselves are perfectly precise. It's the operations that don't do what you expect.

I think that this is an oversimplification, and misses a key point.

Floating point numbers can be interpreted in (at least) two distinct ways.

In one use model, floating point numbers allow a sparse representation of selected points on the (extended) real number line. In this model, the numbers themselves are perfectly precise, and the basic operations do exactly what you'd expect -- but because the result of the expected real-number operation may not be one of the selected representable points, each operation is potentially paired with a second, implicit, rounding operation, and the consequences of the cumulative effects of this rounding operation take some thought.

This first model is often comfortable for those who have done low-level numerical program with sized integers, which are likewise a selected sparse representation of selected points on the integer line. While rounding comes up in fewer operations here, and is simpler, wrap-around becomes an issue.

However, a second model of floating point numbers is that each possible bit sequence represents an /interval/ on the (extended) real number line. In versions of this model, while the set of representable intervals is still very restricted, every point on the real number line falls into a representable interval, which is a property that sometimes eases (and sometimes seems to ease) analysis. In exchange, the operations are much more complex, and their limitations are much more obvious -- in particular, not only can no disjoint intervals be represented, but for any given point on the real line only one interval that contains it is representable -- there's no way to represent intervals of different sizes containing (some of) the same points.

This second model is what people are mostly thinking of when they say that floating point arithmetic is "not precise." In particular, both the inputs and outputs of operations have imprecise interpretations -- that is, the input interval contains infinitely many indistinguishable points, and the output interval contains infinitely many indistinguishable points, even if a real number equivalent of the problem would have a single number in the desired range.

When extended to true interval arithmetic, the second model can be very useful for understanding error propagation and uncertainty, but sadly this is rarely done.

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

#109
post #100

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…

I don't think it's just that.

1/0 is infinity but 1/(-0) is -infinity

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

#110

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…

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.

Post reply on HN