Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How does your programming language handle “minus zero” (-0.0)?

lemire.me

Post reply on HN
Print view View original

211–219 of 219 posts

Re: How does your programming language handle “minus zero” (-0.0)?

#211

Post by fiedzia »

kingkonz1 wrote: post #184
TorKlingberg wrote: post #60

I feel like floating point is a completely separate branch of programming that a lot of coders never use. When they do it's often a mistake, like for currency. Yet floating point is very useful for scientific calculations and simulations, which is what computers were all about for the first couple of decades. I have a suspicion that on a fundamental level, floating point isn't actually good for games or machine learn…

What better alternative is there for handling currencies? Multiplying the original amount by 100 and casting to an int? ($3.50 -> 350)?

Use decimal type for that

Re: How does your programming language handle “minus zero” (-0.0)?

#213

Post by patrec »

dnautics wrote: post #197
phkahler wrote: post #40

Earlier quoted context omitted.

Posits handle this by using the smallest non-zero number where floating point would go to zero. They also use the largest represent able number instead of infinity. These exist for both positive and negative numbers. At least that's the way I read it.

Co-inventor of posits here, this is basically correct, there still is "infinity" in posits, it's strictly reachable by inverting 0 directly.

Having a single (unsigned) infinity (and a single zero!) seems cleaner in some ways (and I dimly seem to recall that some pre-ieee754 floating point hardware worked that way). On the other hand, having e.g. a neutral element for both max and min also seems pretty nice to have, although without infinities, the maximal and minimal floating point value will equally do the trick in most cases.

How do inequalities work for posit infinity? Is posit infinity both larger and smaller than any other posit?

Re: How does your programming language handle “minus zero” (-0.0)?

#214

Post by bjourne »

wnoise wrote: post #163
bjourne wrote: post #149

Earlier quoted context omitted.

More information isn't better if that information isn't useful. Does x*0 evaluate to 0.0? Not with -0 around. Does x+0 evaluate to x? Maybe!

IEEE 754 requires that -0.0 and 0.0 compare equal. > Does x*0 evaluate to 0.0 No, but it will compare equal, unless x is either infinite or a NaN. > Does x+0 evaluate to x? Maybe! Yes, unless x is either infinite or a NaN.

No, if x = -0.0 then x+0 = 0.0 and x*0 = -0.0. This violates fundamental tenets of arithmetic, surprises most, and makes many compiler optimizations impossible.

Re: How does your programming language handle “minus zero” (-0.0)?

#216

Post by phkahler »

dnautics wrote: post #197
phkahler wrote: post #40

Earlier quoted context omitted.

Posits handle this by using the smallest non-zero number where floating point would go to zero. They also use the largest represent able number instead of infinity. These exist for both positive and negative numbers. At least that's the way I read it.

Co-inventor of posits here, this is basically correct, there still is "infinity" in posits, it's strictly reachable by inverting 0 directly.

I thought that was essentially NaN and could also result from square root of negative numbers?

Re: How does your programming language handle “minus zero” (-0.0)?

#217

Post by patrec »

Const-me wrote: post #207
patrec wrote: post #101

Earlier quoted context omitted.

> Your approach makes the range asymmetrical like it happens with integers. Not necessarily since you've got (a lot of different) NaNs anyway. For the sake of argument, you could give up one one of them and make it positive zero (since this representation would be unnatural, it would slow stuff down, just as non-finite values do on many CPUs. Wouldn't matter that much since signed zeros would only arise from underflo…

> you could give up one one of them and make it positive zero What do you expect to happen when you set the sign bit of that number? A possible answer to that is "negative zero", and now you have 2 separate encodings for negative zeroes: one of them with exponent 0, another one 0xFF, and they behave slightly differently.

If you manually screwed around with the most significant bit of the underlying bit pattern (rather than just writing -x like any normal person) I'd expect to get a NaN -- assuming of we keep an explicit sign bit in the representation at all. It would obviously make hardware implementation of negation more complex (and thus slower) but I don't think there is any conceptual problem.

Re: How does your programming language handle “minus zero” (-0.0)?

#218

Post by Const-me »

patrec wrote: post #217
Const-me wrote: post #207

Earlier quoted context omitted.

> you could give up one one of them and make it positive zero What do you expect to happen when you set the sign bit of that number? A possible answer to that is "negative zero", and now you have 2 separate encodings for negative zeroes: one of them with exponent 0, another one 0xFF, and they behave slightly differently.

If you manually screwed around with the most significant bit of the underlying bit pattern (rather than just writing -x like any normal person) I'd expect to get a NaN -- assuming of we keep an explicit sign bit in the representation at all. It would obviously make hardware implementation of negation more complex (and thus slower) but I don't think there is any conceptual problem.

PC hardware doesn’t have hardware implementation of negation.

Possible to do in 2 instruction, xorps to make zero, then subps to subtract. Combined, they gonna take 4-5 cycles of latency (xorps is 1 cycle, subps is 3 cycles on AMD, 4 cycles on Intel).

If you do that a lot, a single xorps with a magic number -0.0f gonna negate these floats 4-5 times faster. People don’t pay me because I’m a normal person, they do that because I write fast code for them :-)

On a serious note, I’d rather have the current +0.0 and -0.0 IEEE values to be equal and be the exact zero, and make another one with 0xFF exponent encoding inexact zeroes, +0.0f or -0.0f depending on the sign bit.

Or another option, redefine FLT_MIN to be 2.8E-45, and reuse the current FLT_MIN, which is 1.4E-45 / 0x00000001 bit pattern, as inexact zeroes.

Re: How does your programming language handle “minus zero” (-0.0)?

#219

Post by OneWingedShark »

dnautics wrote: post #164

the Erlang VM said "screw IEEE": iex(1)> -0.0 === 0.0 true there's also explicitly no infinity or NaN, there is a software throw for all (core) implemented function domain failures. This has, however, recently come up for Nx (numerical elixir) which had to implement and standardize ways to shim these IEEE concepts back into the VM for interop purposes.

> This has, however, recently come up for Nx (numerical elixir) which had to implement and standardize ways to shim these IEEE concepts back into the VM for interop purposes.

This would have been an excellent place to use Ada. The package "Interfaces" has types exactly for IEEE Floats: `Interfaces.IEEE_Float_64`.

You could then get rid of non-numeric representations (raising `Constraint_Error` instead) via the following subtype-definition:

    subtype Float is Interfaces.IEEE_Float_64 range Interfaces.IEEE_Float_64'Range;
(I've thought about writing an Erlang in Ada, hoping to tie together Erlang's actors w/ Ada's Task where possible [ie focus on interop], but haven't found any Erlang language definition that's anywhere near recent.)
Post reply on HN