3 ms·

The important question to ask is: do you really need bit-accurate results? If so, then floating point arithmetic isn't probably what you want. However, running

by exDM69 11y ago

The important question to ask is: do you really need bit-accurate results? If so, then floating point arithmetic isn't probably what you want. However, running the same binary on different (compatible, ie. not ARM vs. x86) CPU architectures should produce identical results almost always (can anyone give a counterexample?). But in reality, it is often acceptable to have one or two least significant bits differing. Especially when computing with doubles, a relative error in the order of 2^-53 = ~10^-16 isn't really significant. Even 32 bit floats give a precision of 2^-24 = 5*10^-8. This is usually good enough for e.g. games, although multiplayer games need some kind of authoritative server model to avoid cheating. Finally, the x87 floating point unit shouldn't be used any more because SSE2 is ubiquitous at this point so issues with 80 bit internal precision should be a thing of the past. I'll conclude with a link to an article about a (very) competitive sim racing game where a least significant bit in a float ended up making a practical difference: http://www.iracing.com/q-circles-the-crop-circles-of-iracing/ http://www.iracing.com/q-circles-the-crop-circles-of-iracing...

mortoray 11y ago
I'm not sure 80-bit floats are a thing of the past. Many calculations still benefit from the extended precision compared to 64-bit. The issue also crops up agian on some platforms that can do 128-bit float, but are then truncated down to 64-bits for storage. I agree there are ways to avoid that problem, but the general issue of truncation across storage/calculation I think remains an important concept.
- exDM69 11y ago
  > Many calculations still benefit from the extended precision compared to 64-bit. Out of curiosity, can you name some examples? 64 bit doubles are really precise, to give a practical figure: a 64 bit float is good enough to calculate the orbit of Neptune to a precision of half a millimiter (0.497 mm). That's a distance of about 30 AU = 4.5 * 10^12 m = four and a half billion kilometers. > The issue also crops up agian on some platforms that can do 128-bit float, but are then truncated down to 64-bits for storage. Which CPU architectures use 128 bit floats internally? Is it common to use such platforms? What comes to x87, I'd imagine that the difference in speed in comparison to SSE is already a good enough reason to not use 80 bit floats in most practical applications. Perhaps some nuclear simulations or particle accelerator physics deal with numbers that vary in magnitude so greatly that increased precision may be useful but these cases are really rare (albeit important).
  - rurban 11y ago
    Technical calculations do care, e.g FMAC in matlab. http://www.cs.berkeley.edu/~wkahan/MxMulEps.pdf http://www.cs.berkeley.edu/~wkahan/MxMulEps.pdf In short Java went ahead and declared imprecise and architecture-independent float results better than more precise and architecture dependent results. Matlab followed suite with v6.0 and found big errors in mxmuleps compared to Matlab v5.0. Such a little rounding problem in the 6th digit e.g. caused a big problem in one architectural problem of mine, where it did cost several millions. Check for the costs of rounding problem in the real world, comp.risks e.g. https://www.ima.umn.edu/~arnold/disasters/ https://www.ima.umn.edu/~arnold/disasters/
- fdej 11y ago
  Basically everything that can be done with 80-bit floats can be done with techniques such as compensated summation and double-double arithmetic. This requires several 64-bit operations per operation, but those operations can take advantage of SIMD capabilities when processing several inputs in parallel.
deleted 11y ago
[deleted]

by exDM69 11y ago

mortoray 11y ago

I'm not sure 80-bit floats are a thing of the past. Many calculations still benefit from the extended precision compared to 64-bit. The issue also crops up agian on some platforms that can do 128-bit float, but are then truncated down to 64-bits for storage. I agree there are ways to avoid that problem, but the general issue of truncation across storage/calculation I think remains an important concept.

exDM69 11y ago
> Many calculations still benefit from the extended precision compared to 64-bit. Out of curiosity, can you name some examples? 64 bit doubles are really precise, to give a practical figure: a 64 bit float is good enough to calculate the orbit of Neptune to a precision of half a millimiter (0.497 mm). That's a distance of about 30 AU = 4.5 * 10^12 m = four and a half billion kilometers. > The issue also crops up agian on some platforms that can do 128-bit float, but are then truncated down to 64-bits for storage. Which CPU architectures use 128 bit floats internally? Is it common to use such platforms? What comes to x87, I'd imagine that the difference in speed in comparison to SSE is already a good enough reason to not use 80 bit floats in most practical applications. Perhaps some nuclear simulations or particle accelerator physics deal with numbers that vary in magnitude so greatly that increased precision may be useful but these cases are really rare (albeit important).
- rurban 11y ago
  Technical calculations do care, e.g FMAC in matlab. http://www.cs.berkeley.edu/~wkahan/MxMulEps.pdf http://www.cs.berkeley.edu/~wkahan/MxMulEps.pdf In short Java went ahead and declared imprecise and architecture-independent float results better than more precise and architecture dependent results. Matlab followed suite with v6.0 and found big errors in mxmuleps compared to Matlab v5.0. Such a little rounding problem in the 6th digit e.g. caused a big problem in one architectural problem of mine, where it did cost several millions. Check for the costs of rounding problem in the real world, comp.risks e.g. https://www.ima.umn.edu/~arnold/disasters/ https://www.ima.umn.edu/~arnold/disasters/
fdej 11y ago
Basically everything that can be done with 80-bit floats can be done with techniques such as compensated summation and double-double arithmetic. This requires several 64-bit operations per operation, but those operations can take advantage of SIMD capabilities when processing several inputs in parallel.

deleted 11y ago

[deleted]