3 ms·

Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.

by kr7 10y ago

kirab 10y ago
But in decimal floating point this is also solved: 1/7 + 2/7 = 3/7 Please research decimal floating point first..
- 3JPLW 10y ago
  That particular example happens to work, but 1/7 + 1/7 != 2/7. DecFP is not magic. You still need to know that you're dealing with limited precision numbers under the hood.
  - deleted 10y ago
    [deleted]
  - kirab 10y ago
    You are right, that example doesn't work. I thought the rounding and normalization described in the standard may fix all these cases by itself but there I was wrong. But at least all problems that could happen on a financial application are solved with decimal floating points (where you will only want to use rationals in finite decimal form like 0.01) And even your example can be made working pretty easily: #include <decimal/decimal> int main(int /*argc*/, char **/*argv*/) { using namespace std; using namespace decimal; decimal128 d1 = 1; decimal128 d2 = 2; decimal128 d7 = 7; uint64_t conversionFactor = 10000000000000000000ull; cout << decimal128_to_long_long(d1/d7 * conversionFactor) << endl; cout << decimal128_to_long_long(d2/d7 * conversionFactor) << endl; cout << (decimal128_to_long_long((d1/d7+d1/d7) * conversionFactor) == decimal128_to_long_long((d2/d7) * conversionFactor) ? "yes" : "no") << endl; } 1428571428571428571 2857142857142857142 yes That was done using the gcc included decimal types. And if you look e.g. into the intel dfp library readme, you see lots of functions which will allow you to do the comparison you wanted to do: https://software.intel.com/sites/default/files/article/144639/readme.txt https://software.intel.com/sites/default/files/article/14463...
    - mmarx 10y ago
      > But at least all problems that could happen on a financial application are solved with decimal floating points (where you will only want to use rationals in finite decimal form like 0.01) You still get cancellation if the magnitudes differ by large enough an amount. This is a problem inherent to floating point arithmetic, using a decimal format instead of binary does not save you from that.
dragonwriter 10y ago
This is solved by the Scheme numerical tower, which prefers exact representations (including exact rationals) unless inexact representation is explicitly requested or forced by an operation that doesn't support exact results.
- Johnny_Brahms 10y ago
  The problem is remembering to only input rationals :) So instead of doing (iota 100 0.1 0.1), you do (iota 100 (/ 1 10) (/ 1 10)). That does not work in chicken for some reason. I don't know if precomputation is ever guaranteed for those things, but otherwise it would be neat to be able to input rationals directly into the source. Edit: So, this is scheme standard discovery week: apparently inputing 1/10 works just fine. I can't believe I missed this.

Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.

by kr7 10y ago

Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.

kirab 10y ago

But in decimal floating point this is also solved: 1/7 + 2/7 = 3/7 Please research decimal floating point first..

3JPLW 10y ago
That particular example happens to work, but 1/7 + 1/7 != 2/7. DecFP is not magic. You still need to know that you're dealing with limited precision numbers under the hood.
- deleted 10y ago
  [deleted]
- kirab 10y ago
  You are right, that example doesn't work. I thought the rounding and normalization described in the standard may fix all these cases by itself but there I was wrong. But at least all problems that could happen on a financial application are solved with decimal floating points (where you will only want to use rationals in finite decimal form like 0.01) And even your example can be made working pretty easily: #include <decimal/decimal> int main(int /*argc*/, char **/*argv*/) { using namespace std; using namespace decimal; decimal128 d1 = 1; decimal128 d2 = 2; decimal128 d7 = 7; uint64_t conversionFactor = 10000000000000000000ull; cout << decimal128_to_long_long(d1/d7 * conversionFactor) << endl; cout << decimal128_to_long_long(d2/d7 * conversionFactor) << endl; cout << (decimal128_to_long_long((d1/d7+d1/d7) * conversionFactor) == decimal128_to_long_long((d2/d7) * conversionFactor) ? "yes" : "no") << endl; } 1428571428571428571 2857142857142857142 yes That was done using the gcc included decimal types. And if you look e.g. into the intel dfp library readme, you see lots of functions which will allow you to do the comparison you wanted to do: https://software.intel.com/sites/default/files/article/144639/readme.txt https://software.intel.com/sites/default/files/article/14463...
  - mmarx 10y ago
    > But at least all problems that could happen on a financial application are solved with decimal floating points (where you will only want to use rationals in finite decimal form like 0.01) You still get cancellation if the magnitudes differ by large enough an amount. This is a problem inherent to floating point arithmetic, using a decimal format instead of binary does not save you from that.

dragonwriter 10y ago

This is solved by the Scheme numerical tower, which prefers exact representations (including exact rationals) unless inexact representation is explicitly requested or forced by an operation that doesn't support exact results.

Johnny_Brahms 10y ago
The problem is remembering to only input rationals :) So instead of doing (iota 100 0.1 0.1), you do (iota 100 (/ 1 10) (/ 1 10)). That does not work in chicken for some reason. I don't know if precomputation is ever guaranteed for those things, but otherwise it would be neat to be able to input rationals directly into the source. Edit: So, this is scheme standard discovery week: apparently inputing 1/10 works just fine. I can't believe I missed this.