171–180 of 219 posts
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. 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…
What is wrong in having different hashes for different numbers? https://float.exposed/0x0000000000000000 https://float.exposed/0x8000000000000000
Of course since NaN != x, whatever x is (including infinity and NaN), one could argue it's fine for different NaNs to return different hash codes. But I think most people think of NaN as one thing, and not the 9007199254740990 or so different NaN encodings[1] there are in a double.
Earlier 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).
I think a protocol that used integers instead of decimal point would have led to more correct implementations. So it would be a better protocol.
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.
Is there any language that treats the zeros as unequal? That would seem like the real "screw IEEE".
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.
Earlier quoted context omitted.
Floats are essential for machine learning, scientific computing, and any other application where the goal is to model mathematical processes involving real numbers. The idea that there is something out there that could do the job better than floats is almost certainly wrong. I'm fascinated by how common it is for programmers to hate floats. Yes, if you write business software for a living you may not have much use fo…
> Floats are essential for Not necessarily true. Theoretically you can replace floats by fixed-point representations given enough bits, and in practice this also works often. It's a pity languages/hardware don't have good built-in support for fixed-point numbers though.
What did you gain from this, exactly?
I'm sure there are some special situations where fixed point is better, but for general purpose scientific and technical computing, floating point is obviously the right choice.
Earlier quoted context omitted.
They all follow IEEE 754. But that defines the representation of the bits in a floating point number, not what happens when you operate on them. Different implementations do rounding differently, and there are arguments about how to do this correctly. There can be multiple ways to represent the same number even (this is a reason not to ever do a == compare on floating point number that have been operated on). Not onl…
IEEE 754 does also specify operations and their behavior. E.g. section 5.1 (from 2008 edition): > All conforming implementations of this standard shall provide the operations listed in this clause for all supported arithmetic formats, except as stated below. Each of the computational operations that return a numeric result specified by this standard shall be performed as if it first produced an intermediate result co…
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…
// 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) != Double.hashCode(-0x0p+0d)
// hashCodes for different NaNs collapse to the same value
Double.hashCode(0.0d / 0) == Double.hashCode(Math.sqrt(-1))Earlier quoted context omitted.
Floats are essential for machine learning, scientific computing, and any other application where the goal is to model mathematical processes involving real numbers. The idea that there is something out there that could do the job better than floats is almost certainly wrong. I'm fascinated by how common it is for programmers to hate floats. Yes, if you write business software for a living you may not have much use fo…
For some reason many programmers love to hate technologies that are old. Hate floats, love big decimals Hate OOP, love functional Hate RDBMS, love nosql Hate html web pages, love SPA In my opinion it's a confluence of influences. 1) the same social media attitudes poisoning society generally. "I've got an opinion, and it's worth just as much as yours". News flash - opinions are like arseholes, everyone has one. 2) In…
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…
> 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…
Earlier quoted context omitted.
> Floats are essential for Not necessarily true. Theoretically you can replace floats by fixed-point representations given enough bits, and in practice this also works often. It's a pity languages/hardware don't have good built-in support for fixed-point numbers though.
Okay, so now, relative to floating point arithmetic, you've sacrificed an enormous amount of dynamic range and have to worry about overflow and underflow much more than before. What did you gain from this, exactly? I'm sure there are some special situations where fixed point is better, but for general purpose scientific and technical computing, floating point is obviously the right choice.