Live data from Hacker News

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

lemire.me

101–110 of 219 posts

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

#101
post #30

Earlier quoted context omitted.

When does this need arise? Well, otherwise inverting a value can change it's sign and in particular inverting -∞ twice will give you +∞, and being off by "2∞" is a pretty large error for a lot of computations ;) You can end up with zeros and infinities pretty easily because you overflow or underflow the range of floating point precision, and generally you want something sensible to happen in typical cases, even if so…

> If anyone knows why this design was not chosen and what fundamental downsides it has, I'd love to hear it. No fundamental ones, but a few practical. 32-bit numbers have 2^32 unique values, the number is even. Your approach makes the range asymmetrical like it happens with integers. The range for 8-bit signed integers is [ -128 .. +127 ]. On ARM NEON there’re two versions of integer negate and absolute instructions,…

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

> Another useful property of IEEE representation is that for two intervals [ 0 .. FLT_MAX ] and [-FLT_MAX .. -0.0f ] sort order of floats corresponds to [inverted] sort order of 32-bit integers.

I'm aware, but as you correctly note this only works in the right direction for unsigned values. And it's just not that important a benefit, I'd much rather have my calculations come out right than being able to sort positive floating point numbers with an integer sort routine.

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

#102
post #99
post #83

Earlier quoted context omitted.

I never use the square root in games, I always compare squared distances (since the properties are the same). If you try to do with Fixed Point Arithmetic what was intended to be done with Floating Point, you're the problem. A 32 bits integer can hold values up to 4 billions, if I have that kind of value in a simple game, then yes i will switch to Floating Point Arithmetic, but when does that use case happen if you'r…

It appears you have a very niche definition of "game", one which excludes basically all 3D games.

Yes, that's exactly why I wrote:

> some game engines

and

> simple games

A 3D game is not a simple game.

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

#103
post #91
post #85

Earlier quoted context omitted.

Lots of the math in games and ML assumes you’re operating in the reals. For example, the optimization in neural networks. Integers and fixed point won’t work.

Doesn't ML work fine with fixed point numbers? I don't think there is a particular use case for very large or very small numbers.

Referring to ML is so vague that it’s not particularly meaningful. The answer in general is no. There’s been some work showing neural networks can function with low precision floating point, but that’s still pretty different than fixed point.

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

#104

Earlier quoted context omitted.

You shouldn't really use equality on floating point numbers, except on very special circumstances (and I imagine the == behavior for 0 breaks things more often than it helps). But the wikipedia page on -0 has your case covered: > According to the IEEE 754 standard, negative zero and positive zero should compare as equal with the usual (numerical) comparison operators, like the == operators of C and Java. In those lan…

> You shouldn't really use equality on floating point numbers, except on very special circumstances. This is very common advice, so common that it gets cargo-culted into situations where it is really quite poor. Information storage, retrieval, and transmission systems should faithfully deliver floating-point values that are good to the last bit. Round-trips through databases, transmission over network protocols, etc…

> Round-trips through databases, transmission over network protocols, etc should all give values back that are exactly identical to what was put into them.

Yes that's true... but what's that got to do with using an equality operator?

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

#106
post #102
post #99

Earlier quoted context omitted.

It appears you have a very niche definition of "game", one which excludes basically all 3D games.

Yes, that's exactly why I wrote: > some game engines and > simple games A 3D game is not a simple game.

Ugh, do you really have to be this nitpicky? Fine, you wrote:

> the approximation is generally good enough for a game

No, it's not generally good enough for a game – only for some games, and not good enough for any game with 3D graphics.

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

#107

PHP just refuses to divide by zero: php > $minus_zero = -0.0; php > $plus_zero = +0.0; php > var_dump(1.0 / $minus_zero); PHP Warning: Uncaught DivisionByZeroError: Division by zero in php shell code:1

Actually as shown by your output it doesn't completely refuse to divide by zero, a warning means that execution continued.

The result of that division is a float with a value of -INF, INF being a constant that PHP treats as infinite.

But as of PHP 8 dividing by zero causes a fatal error and execution is halted.

This site is really good for comparing results in different PHP versions: https://3v4l.org/9Tl1I

I actually wasn't aware that PHP had an INF contant but seeing the warning in your output prompted me to dig a little bit deeper :)

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

#108
post #61

Ruby seems to handle this correctly: >> 1 / -0.0 => -Infinity Although you have to put the 0.0, otherwise it treats it as an integer and makes it 0.

Dividing by zero is "undefined" not "Infinity" because there is not a "well defined limit."

https://en.wikipedia.org/wiki/Division_by_zero

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

#109

I recall there being an issue with double.GetHashCode() in the early versions of .Net, where it would return different hash values for 0.0 and -0.0. That got fixed, but it seems a variation with signed NaN recently got fixed[1] in .Net Core (taking care to handle all the possible NaN values). Floats are deceptively easy to use. Which is nice but kinda sucks too, given all the footguns they bring to the party. [1]: ht…

> I recall there being an issue with double.GetHashCode() in the early versions of .Net, where it would return different hash values for 0.0 and -0.0.

I never thought about that (I avoid FP as much as I can) but, oh boy, the can of worms!

.Net (or Java) OOP where an object's hashcode needs to give the same (or not?) value for 0.0 or -0.0: this is the kind of stuff nightmares are made off.

I'm sure this can be turned into some very funny "Java puzzler".

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

#110
post #91
post #85

Earlier quoted context omitted.

Lots of the math in games and ML assumes you’re operating in the reals. For example, the optimization in neural networks. Integers and fixed point won’t work.

Doesn't ML work fine with fixed point numbers? I don't think there is a particular use case for very large or very small numbers.

ML optimization algorithms generally do require proper handling of very,very small numbers for e.g. calculation of gradients.

There's a bunch of work on discretization of models after you've done optimizing them - that works, you can get high-performance inference with low-bit fixed point numbers; but that's after the learning has been done using proper floating point (however, you don't necessarily need high accuracy floating point, e.g. single precision may work betted than double precision simply because it's twice less bytes to copy over).

Post reply on HN