Earlier quoted context omitted.
There is the difficulty that you don't actually have zero, you have postive and negative infinitesimal.
That is the meaning of "+0.0" and "-0.0". Actual zero is neither.
[deleted]
How does your programming language handle “minus zero” (-0.0)?
201–210 of 219 posts
Re: How does your programming language handle “minus zero” (-0.0)?
#202Earlier quoted context omitted.
Probably not even rounding, but just printf. The following works on my zsh: $ printf '%.0f°\n' 0.3 0° $ printf '%.0f°\n' -0.3 -0°
That actually is rounding around zero (to zero decimal places, but it is rounding).
You're right. What I meant to say was that it's possible the programmers working on the weather app didn't add explicit rounding, they just passed the value through a formatter that did the rounding implicitly.
Re: How does your programming language handle “minus zero” (-0.0)?
#203Earlier quoted context omitted.
> When they do it's often a mistake, like for currency. The most beautiful FP bug I remember was a denial of service in some webservers where by setting the header "Accepted Language: en-gb;q=0.3 en;q=0.8 ..." to a specific value you could send the official Java floating-point parser in an infinite loop (and this affected several Java webservers). So at each webpage request, you were sending one CPU core of the webse…
There is nothing wrong with the protocol. The protocol has nothing to do with what representation is used by software that speaks the protocol. Software could just as well parse those values as integers. Just drop the decimal point and pad with zeroes. Or use a decimal type (but there is really no need to).
It’s on implementors to be correct. No one said the Java implementation needed to use float or double. Java isn’t the only web server implementation language.
Re: How does your programming language handle “minus zero” (-0.0)?
#204I 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…
You inspired me to check java world. // 0.0d / 0 equals 0x7ff8000000000000 (NaN) // Math.sqrt(-1) equals 0xfff8000000000000 (NaN) // 0x0p+0d is a funky way to specify 0x0000000000000000 (0) // -0x0p+0d is a funky way to specify 0x8000000000000000 (-0) // without 0xHEXp+NUMd my compiller optimizes "-0" literal to 0 // 0 == -0 0x0p+0d == -0x0p+0d // hashCodes for 0 and -0 are different Double.hashCode(0x0p+0d) != Doubl…
So yeah, same issue that .Net had.
I can't find the original complaints about this (was back in early 2000s after all), but as I recall it someone was very surprised that something that compares as equality ended up two times in the hashmap, and that messed up their code bad.
Re: How does your programming language handle “minus zero” (-0.0)?
#205I 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…
In javascript, every number is technically floating point. :)
Re: How does your programming language handle “minus zero” (-0.0)?
#206Earlier quoted context omitted.
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.
Technically, 32-bit fixed-point numbers have 8-bit more precision compared to 32-bit floating-point numbers, but the real problem is it's quite cumbersome to fully utilize the precision offered by fixed-point numbers as you'd have to keep in mind their numerical range all the time.
Re: How does your programming language handle “minus zero” (-0.0)?
#207Earlier quoted context omitted.
> 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 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.
Re: How does your programming language handle “minus zero” (-0.0)?
#208Python Produces the following:
minus_zero = -0.0
plus_zero = +0.0
parsed = float("-0.0")
print(1/minus_zero)
print(1/plus_zero)
print(1/parsed)
ZeroDivisionError Traceback (most recent call last)
in ()
2 plus_zero = +0.0
3 parsed = float("-0.0")
----> 4 print(1/minus_zero)
5 print(1/plus_zero)
6 print(1/parsed)
ZeroDivisionError: float division by zero
Re: How does your programming language handle “minus zero” (-0.0)?
#209Earlier quoted context omitted.
I dont think this is true. Integer math is used in some game engines because they need to be deterministic, between networked computers (and different CPUs rounds floating point numbers differently). I have written an engine like that, and i know that Starcraft 2 is all integer for the same reason. No one does it because its faster or easier. Its a pain.
I never said it was easier and I never said ALL game engines. And computing integers IS faster than computing floats, at least on a CPU.
Modern CPUs, like Zen2, have vastly more f64 multiplier throughput than 64 bit integer multiplier throughput.
This goes so far, that Intel added an AVX512 instruction to expose this 52/53 bit multiplier for integer operations, to accelerate bigint cryptography calculations like RSA and ECC.
Re: How does your programming language handle “minus zero” (-0.0)?
#210Earlier quoted context omitted.
In some game engines, Fixed Point Arithmetic is used instead of Floating Point, because it's faster, and the approximation is generally good enough for a game.
I dont think this is true. Integer math is used in some game engines because they need to be deterministic, between networked computers (and different CPUs rounds floating point numbers differently). I have written an engine like that, and i know that Starcraft 2 is all integer for the same reason. No one does it because its faster or easier. Its a pain.
Actually, the rounding for basic add/multiply are strictly defined and configurable (some algorithms need other rounding rules than the default "round to nearest even").
If you only use those (maybe including division, I'm not sure), and don't rely on hardware support for sqrt, sin/cos/tan, approximate-inverse, etc., you can totally use them deterministically between different architectures.