Is there any language that treats the zeros as unequal? That would seem like the real "screw IEEE".
in the specific case of erlang, and the erlang beam vms, 0 !== 0.0 Of course 0 == 0.0 I imagine if they had chosen to follow IEEE, it would have been that 0.0 !== -0.0 and 0.0 == 0.0.
I don't know erlang, but it looks to me like that's a difference between types. (integer vs float)
Is there a language that treats different float values of zero as unequal? That would be surprising to me. And possibly silly.
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…
So no then? As you say, epsilon should be used in this case.
I meant as in infinitesimal, not as in machine epsilon (which lacks the required properties) -- poor wording on my part. If you have numbers of impossibly large magnitude you probably also want corresponding numbers of impossibly small magnitude. You can do this in a nice, algebraically satisfying way with infinitely many such numbers (hyperreals), but I think if it weren't for the signless zero and positive zero conflation, IEEE754's way would be quite a reasonable finite precision approximation to this.
in the specific case of erlang, and the erlang beam vms, 0 !== 0.0 Of course 0 == 0.0 I imagine if they had chosen to follow IEEE, it would have been that 0.0 !== -0.0 and 0.0 == 0.0.
I don't know erlang, but it looks to me like that's a difference between types. (integer vs float) Is there a language that treats different float values of zero as unequal? That would be surprising to me. And possibly silly.
Meh, it's not like there can't be a bug in whatever other parsing code a webserver uses. Maybe using a float is overkill in this case, since you're never going to hit more than a hundred languages. But it's at least not setting any limitations.
The issue is that the representation of floating point numbers imposes additional cognitive burden that the code must handle. How does the web server header parsing code handle positive/negative infinity? How about NaN? NaNs/infs are particularly vicious, as they propagate through computations.
This. Floating point numbers, as they are lossy attempts to discretize continuous data, are more complex and usually non-deterministic. They should never be chosen when a non-lossy representation is available for the problem domain.
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 ints. No multiplication necessary. Everything is done in cents. You add/remove the decimal point when doing string conversions.
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…
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.
Computers (obviously) have to approximate the majority of actual mathematical numbers, as they do not have infinite storage. If you've got two numbers, +0.0000001 and -0.0000001, but you can't represent that precision, can you see how it's less bad to round to +0.0000 and -0.0000 rather than to just 0.0000? It's encoding strictly more information.
Reading your comment gave me a realization that transformed my understanding of floats. What just clicked for me was that in any system where we use finite precision to store exponents, we can't actually have zero as a normal value... we'll always underflow the exponent before we get to actual mathematical zero. So +0/-0 is actually a convenient misnomer. They really are +/- epsilon. The only way to have zero is if i…
> The only way to have zero is if it's some specially handled value like NaN. Which IEEE doesn't do and that's entirely understandable.
Wait what? Am I missing something? 0 is absolutely part of the IEEE 754 spec thanks to the existence of denormalized floating point numbers. So I would certainly call it a "specially handled value", in a sense. The existence of +/- 0 has more to do with the implementation of the leading sign bit.
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…
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.
a cons of that is that there is no longer a distinction between positive and negative infinity
Meh, it's not like there can't be a bug in whatever other parsing code a webserver uses. Maybe using a float is overkill in this case, since you're never going to hit more than a hundred languages. But it's at least not setting any limitations.
The issue is that the representation of floating point numbers imposes additional cognitive burden that the code must handle. How does the web server header parsing code handle positive/negative infinity? How about NaN? NaNs/infs are particularly vicious, as they propagate through computations.
laughs in Ada
-- IEEE754/64-bits: Interfaces.IEEE_Float_64
-- And here we strip out non-numeric values.
Use Interfaces;
Subtype Numeric_Real is IEEE_Float_64 range IEEE_Float_64'Range;