3 ms·

If by "decimal numbers" you mean the reals written in base 10, how do you propose we precisely represent the result of 1 / 3 . Or pi?

shortstuffsushi 12y ago
I guess I wasn't necessary referring to solving the problem of non-terminating numbers, but more things like 0.1 * 0.2 = 0.020000000000000004 in Javascript, or the very first bug listed on the linked page. Perhaps what you intend with that statement is that issues like that of 1/3 are a cause for these sorts of issues, but interestingly (at least in JS), 1/3 is terminating, and results in an "expected" value.
- dietrichepp 12y ago
  The result of the computation 1/3 in JS results in a number which is terminating, but that number is not 1/3. Open up your console and type 1/3+1/3+1/3... 1, as expected. Then type 1-1/3-1/3-1/3... I get about 1e-16, which is not 0. The statement that "1/3 is terminating" is not true in binary, it is not true in decimal, and the only reason that you sometimes get the expected results is that sometimes the rounding errors will cancel out.
  - valleyer 12y ago
    So you're telling me we should use base 3.
    - jakobegger 12y ago
      Well then 0.5 would be non-terminating...
  - shortstuffsushi 12y ago
    I realize that 1/3 is not terminating in decimal, what I meant was that in JS, it seemed to end neatly after x decimal places, which I found interesting. I hadn't tried the operation you mentioned until you posted that, the results are even more bizarre to me. Seems I need to spend some time relearning floating point math to better understand what I'm seeing.
- krzysz00 12y ago
  Well, every base has issues with non-termination. In base 10, we have problems like 1/3 = 0.33333... . Base 2 has its own set of non-terminating decimal expansions, including 1 / 3 = 0.01010101... and 1 / 10 = 0.0001100110011... . Since we only have finite storage space, we have to cut the repeating string of digits off somewhere, no matter what base we're in. This can cause rounding issues. You can't dodge all your rounding problems by changing base. There are binary-coded decimal (BCD) systems that store numbers as strings of decimal digits. You can generally find these in calculators (ever notice that a TI-84 overflows after 9.(9)e99) or some financial software. However, you'll still have problems like the 0.1 * 0.2 issue in binary floating-point. For example (assuming shorter-than-usual numbers): 2/3 = 0.66... ~ 0.66667 2/3 + 2/3 ~ 0.66667 + 0.66667 = 1.33334 However, 4/3 = 1.33333... ~ 1.33333, which isn't the same result. Basically, you can't get away from this problem, you can only push it around to cases you care less about. (You probably can't find an API for binary-coded decimal in $LANGUAGE unless $LANGUAGE is often used for tasks where you really really don't want any float-related gotchas since most everyone else doesn't care too much).
  - edwintorok 12y ago
    You could represent your numbers as fractions of integers and do all operations on them as fractions of integers: https://gmplib.org/manual/Rational-Number-Functions.html#Rational-Number-Functions https://gmplib.org/manual/Rational-Number-Functions.html#Rat... And only converting them to floating point for display purposes: http://www.mpfr.org/mpfr-current/mpfr.html#index-mpfr_005fset_005fq-50 http://www.mpfr.org/mpfr-current/mpfr.html#index-mpfr_005fse...
  - shortstuffsushi 12y ago
    Hmm, so BCD seems closer to what I was roughly imagining (though, I haven't really thought this issue through deeply or anything), but you mention it has shortcomings as well. I guess I'll just have to trust that other people have thought about this, and have determined this to be the best solution, even with its flaws.

shortstuffsushi 12y ago

I guess I wasn't necessary referring to solving the problem of non-terminating numbers, but more things like 0.1 * 0.2 = 0.020000000000000004 in Javascript, or the very first bug listed on the linked page. Perhaps what you intend with that statement is that issues like that of 1/3 are a cause for these sorts of issues, but interestingly (at least in JS), 1/3 is terminating, and results in an "expected" value.

dietrichepp 12y ago
The result of the computation 1/3 in JS results in a number which is terminating, but that number is not 1/3. Open up your console and type 1/3+1/3+1/3... 1, as expected. Then type 1-1/3-1/3-1/3... I get about 1e-16, which is not 0. The statement that "1/3 is terminating" is not true in binary, it is not true in decimal, and the only reason that you sometimes get the expected results is that sometimes the rounding errors will cancel out.
- valleyer 12y ago
  So you're telling me we should use base 3.
  - jakobegger 12y ago
    Well then 0.5 would be non-terminating...
- shortstuffsushi 12y ago
  I realize that 1/3 is not terminating in decimal, what I meant was that in JS, it seemed to end neatly after x decimal places, which I found interesting. I hadn't tried the operation you mentioned until you posted that, the results are even more bizarre to me. Seems I need to spend some time relearning floating point math to better understand what I'm seeing.
krzysz00 12y ago
Well, every base has issues with non-termination. In base 10, we have problems like 1/3 = 0.33333... . Base 2 has its own set of non-terminating decimal expansions, including 1 / 3 = 0.01010101... and 1 / 10 = 0.0001100110011... . Since we only have finite storage space, we have to cut the repeating string of digits off somewhere, no matter what base we're in. This can cause rounding issues. You can't dodge all your rounding problems by changing base. There are binary-coded decimal (BCD) systems that store numbers as strings of decimal digits. You can generally find these in calculators (ever notice that a TI-84 overflows after 9.(9)e99) or some financial software. However, you'll still have problems like the 0.1 * 0.2 issue in binary floating-point. For example (assuming shorter-than-usual numbers): 2/3 = 0.66... ~ 0.66667 2/3 + 2/3 ~ 0.66667 + 0.66667 = 1.33334 However, 4/3 = 1.33333... ~ 1.33333, which isn't the same result. Basically, you can't get away from this problem, you can only push it around to cases you care less about. (You probably can't find an API for binary-coded decimal in $LANGUAGE unless $LANGUAGE is often used for tasks where you really really don't want any float-related gotchas since most everyone else doesn't care too much).
- edwintorok 12y ago
  You could represent your numbers as fractions of integers and do all operations on them as fractions of integers: https://gmplib.org/manual/Rational-Number-Functions.html#Rational-Number-Functions https://gmplib.org/manual/Rational-Number-Functions.html#Rat... And only converting them to floating point for display purposes: http://www.mpfr.org/mpfr-current/mpfr.html#index-mpfr_005fset_005fq-50 http://www.mpfr.org/mpfr-current/mpfr.html#index-mpfr_005fse...
- shortstuffsushi 12y ago
  Hmm, so BCD seems closer to what I was roughly imagining (though, I haven't really thought this issue through deeply or anything), but you mention it has shortcomings as well. I guess I'll just have to trust that other people have thought about this, and have determined this to be the best solution, even with its flaws.