Re:9999999999999999.0 – 9999999999999998.0
by twtw on Saturday January 05, 2019 @07:10PM
(#18835313)
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.
Re:9999999999999999.0 – 9999999999999998.0
by saagarjha on Saturday January 05, 2019 @06:10PM
(#18834956)
Rationals get unwieldy quickly, even with the simplest of arithmetic. A couple of additions is enough to get a large denominator.
Re:9999999999999999.0 – 9999999999999998.0
by bjourne on Saturday January 05, 2019 @07:12PM
(#18835326)
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.
Re:9999999999999999.0 – 9999999999999998.0
by johndough on Sunday January 06, 2019 @04:30AM
(#18837440)
> 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.
"Most" use cases? You mean the use cases that don't involve heavy math, like graphics, physics, and statistics?
Re:9999999999999999.0 – 9999999999999998.0
by stephencanon on Sunday January 06, 2019 @07:09PM
(#18841635)
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.
Re:9999999999999999.0 – 9999999999999998.0
by trishmapow2 on Saturday January 05, 2019 @06:21PM
(#18835018)
Ariane 5 is ESA not NASA
Re:9999999999999999.0 – 9999999999999998.0
by empath75 on Saturday January 05, 2019 @06:12PM
(#18834968)
You can work directly in reals.
Re:9999999999999999.0 – 9999999999999998.0
by ChrisLomont on Saturday January 05, 2019 @10:57PM
(#18836476)
That package approximates reals. It fails to do equality on infinite precision reals, for example.
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-dam...