4 ms·

When NASA can't even get it right, because of "surprises", there's no chance in hell I'm blaming us mere mortal programmers... or even 10x wizards. (0) It's ti

When NASA can't even get it right, because of "surprises", there's no chance in hell I'm blaming us mere mortal programmers... or even 10x wizards. (0) It's time to look at other ways to depict fractional parts of numbers in a computer. I know that one can express any rational number as a integer fraction. And our computers are incapable of expressing a irrational number exactly - it does so to a certain precision... In other words, every number a computer expresses is a rational number. The exception is if the computer could express irrational numbers as symbolics, then we could work with the symbolic instead. And then as a last pass, the symbolic could convert to a imprecise rational depiction, or express as its native type. (0) https://itsfoss.com/a-floating-point-error-that-caused-a-damage-worth-half-a-billion/ https://itsfoss.com/a-floating-point-error-that-caused-a-dam...

saagarjha 8y ago
Rationals get unwieldy quickly, even with the simplest of arithmetic. A couple of additions is enough to get a large denominator.
- bjourne 8y ago
  That has not been my experience using a language with builtin support for rationals. The rational is simplified after each operation so it never grows unwieldy large. It is slower than floats, but imo vastly superior for most use cases.
  - Retra 8y ago
    "Most" use cases? You mean the use cases that don't involve heavy math, like graphics, physics, and statistics?
  - johndough 8y ago
    > The rational is simplified after each operation so it never grows unwieldy large. We recently had an exponential memory growth bug because rationals can not always be simplified, for example if you start with (2/3) and repeatedly square it. Fortunately, this was not in user-facing code, so there was no chance of a denial-of-service attack, but that's definitely something to watch out for with rationals.
  - stephencanon 8y ago
    Even simplifying after every operation, in the typical case exact rationals grow exponentially in the number of terms in the computation. This means that either: (a) you cannot use them for any non-trivial computation. (b) you have to round them, in which case they are strictly worse than floating-point numbers because they have redundant representations and a very non-uniform distribution.
empath75 8y ago
You can work directly in reals. http://hackage.haskell.org/package/exact-real http://hackage.haskell.org/package/exact-real
- ChrisLomont 8y ago
  That package approximates reals. It fails to do equality on infinite precision reals, for example.
trishmapow2 8y ago
Ariane 5 is ESA not NASA
twtw 8y ago
That failure had nothing to do with floating point specifically. The same failure could have occurred when converting any data type with larger range (including rationals or arbitrary precision numbers) to 16 bit integer. I would say the fact that floats can have data larger than INT16_MAX is hardly a surprise. That was just a bug, not some great and surprising drawback of floating point.

saagarjha 8y ago

Rationals get unwieldy quickly, even with the simplest of arithmetic. A couple of additions is enough to get a large denominator.

bjourne 8y ago
That has not been my experience using a language with builtin support for rationals. The rational is simplified after each operation so it never grows unwieldy large. It is slower than floats, but imo vastly superior for most use cases.
- Retra 8y ago
  "Most" use cases? You mean the use cases that don't involve heavy math, like graphics, physics, and statistics?
- johndough 8y ago
  > The rational is simplified after each operation so it never grows unwieldy large. We recently had an exponential memory growth bug because rationals can not always be simplified, for example if you start with (2/3) and repeatedly square it. Fortunately, this was not in user-facing code, so there was no chance of a denial-of-service attack, but that's definitely something to watch out for with rationals.
- stephencanon 8y ago
  Even simplifying after every operation, in the typical case exact rationals grow exponentially in the number of terms in the computation. This means that either: (a) you cannot use them for any non-trivial computation. (b) you have to round them, in which case they are strictly worse than floating-point numbers because they have redundant representations and a very non-uniform distribution.

empath75 8y ago

You can work directly in reals. http://hackage.haskell.org/package/exact-real http://hackage.haskell.org/package/exact-real

ChrisLomont 8y ago
That package approximates reals. It fails to do equality on infinite precision reals, for example.

trishmapow2 8y ago

Ariane 5 is ESA not NASA

twtw 8y ago

That failure had nothing to do with floating point specifically. The same failure could have occurred when converting any data type with larger range (including rationals or arbitrary precision numbers) to 16 bit integer. I would say the fact that floats can have data larger than INT16_MAX is hardly a surprise. That was just a bug, not some great and surprising drawback of floating point.