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

161–170 of 236 posts

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

#161

Post by throwawaymaths »

adgjlsfhk1 wrote: post #154
lolcatuser wrote: post #138

Earlier quoted context omitted.

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

this isn't true. floats don't have semantics of internals. they have semantics of exact points that do math with rounding (otherwise the result of subtracting 2 floats would sometimes be more than 1 float)

Moreover the spec defines rounding modes (rtnz, rtg, rtfz rtl) that are designed to exactly do interval arithmetic

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

#162

Post by kragen »

addaon wrote: post #108
regularfry wrote: post #47

Earlier quoted context omitted.

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

the second model is wishful thinking; the first model describes how ieee-754 arithmetic actually works

as you point out, the second model can be implemented

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

#163

Post by atemerev »

justeleblanc wrote: post #118
nequo wrote: post #81

Earlier quoted context omitted.

Do you just plan to save your money in dollar bills hidden inside a pillow until you retire? If you want to invest it in any way, you probably want to avoid floating point numbers for keeping track of it.

I'd prefer living in a world where social security is enough for me not to worry about things like "saving money".

[flagged]

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

#164

Post by kragen »

Dylan16807 wrote: post #98
atemerev wrote: post #60

Earlier quoted context omitted.

Well, I assume you want to sell your hard-earned stocks of civilization-helping companies sometimes...

High frequency traders effectively charge money to provide liquidity. But they provide far more than I need. I'm not worried about liquidity when I eventually sell those stocks, and if I could opt out of buying extra liquidity I definitely would.

more liquidity in a security drives spreads down, not up, so you have the effect backwards

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

#165

Post by kragen »

chubot wrote: post #52
flatline wrote: post #44

Earlier quoted context omitted.

It is 2023 and our tooling still encourages the same mistakes people were making 40 years ago. Can we really not have equality operators that do a comparison with a 1% tolerance or something as a sensible default equivalence instead of blatantly wrong bitwise comparison? I would even be happy with a default set of compiler warnings or errors, which I don’t believe I have ever seen.

From a user POV, I think == and === on floats should simply be undefined in any language. It should be a compile time or runtime error. There can be a separate function `float_equals()` with explicit args that does what people want The only reason to use the same syntax == is for POLYMORPHIC code that is actually correct. But it's not going to be correct with floats, because they don't obey the same algebraic laws ..…

what people want varies, but often what people doing numerical programming want is to write their monomorphic code in infix syntax so they can more easily see bugs in it

they're already familiar with rounding errors

from that perspective you're suggesting taking a step backwards from fortran i toward assembly language

the erlang compiler bug presented is not an example of what you're talking about because you're talking about arithmetic, and the buggy comparison operator it's using is not an arithmetic comparison operator

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

#166

Post by kragen »

stkdump wrote: post #66
bjourne wrote: post #65

Negative zero is very, very annoying because it means that many floating point identities flies out of the window. x + 0.0 != x, x * 0.0 != 0.0, etc. It makes it much harder for the compiler to optimize arithmetic. Thus, at least some SIMD circuits do not follow ieee754 to the letter because it would result in performance degradations.

Those identities do hold though, as long as zero and negative zero compare equal, which according to ieee754 they should. Performance degredations happen in other places such as denormals.

1/0!=1/-0

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

#167

Post by kragen »

munk-a wrote: post #107
codegeek wrote: post #27

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

it's important to distinguish them in programs written for those circuits and in compilers that transform those programs because they have significantly and intentionally different behavior

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

#168

Post by shultays »

bee_rider wrote: post #137
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?

It is not about being very close. IEEE says "Comparisons shall ignore the sign of zero" and erlang (or rather CPU instructions erlang outputs for float == float) respects that

While =:= is not something mandated by IEEE. Erlang implements such an operator on floats and it decides to compare false for 0.0 & -0.0. So it probably compares bits/does integer comparisons on same data

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

#169

Post by andreareina »

moonchild wrote: post #136
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…

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

That is a phenomenal title.

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

#170

Post by Dylan16807 »

kragen wrote: post #164
Dylan16807 wrote: post #98

Earlier quoted context omitted.

High frequency traders effectively charge money to provide liquidity. But they provide far more than I need. I'm not worried about liquidity when I eventually sell those stocks, and if I could opt out of buying extra liquidity I definitely would.

more liquidity in a security drives spreads down, not up, so you have the effect backwards

What in particular do you think I have backwards?

If I have a medium size order, then even though they lower the spread they also front-run and limit how much I can buy at that price. So I'd rather have them not be there.

If I have a tiny order, then I don't care what the spread is within reasonable bounds, and I still don't want them to be there.

Post reply on HN