5 ms·

For people using C or C++ I can recommend using decimal floating point (which may be added to C++20 in the standard). Contrary to the "default" floating point,

by kirab 10y ago

For people using C or C++ I can recommend using decimal floating point (which may be added to C++20 in the standard). Contrary to the "default" floating point, which are base 2 and do not support precise presentations of certain numbers, you can use a decimal floating point system which uses base 10 and therefore allows exact and precise presentation and solves the problem mentioned on the page. Also important: since 2008 this is standardized in IEEE 754-2008 which added support for decimals. Explanation of decimal floating points: https://en.m.wikipedia.org/wiki/Decimal_floating_point https://en.m.wikipedia.org/wiki/Decimal_floating_point Libraries: https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library https://software.intel.com/en-us/articles/intel-decimal-floa... http://www.bytereef.org/mpdecimal/ http://www.bytereef.org/mpdecimal/ http://speleotrove.com/decimal/ http://speleotrove.com/decimal/ C++ Standard Proposals: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n340... http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3871.html http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3871.ht...

milesrout 10y ago
I absolutely disagree. If you want to represent currency, for example, you should not use decimal floating point. You should integers, specifically you should use an integer number of tenths of cents, which is pretty widely agreed as the standard unit of currency in a computer (or tenths of yen, for example). You need to be extremely careful about overflow, but you need to be anyway, and should almost certainly just use arbitrary-precision integers.
- kirab 10y ago
  I absolutely disagree with your disagreement. Please try writing an ERP system where you have a quantity of a billionth of an item price of a billion euros (or an item price of a billionth Euro and a quantity of billions) and tell me which integer type you deem sufficient for this. Additionally please research decimal floating points before disagreeing.
  - deleted 10y ago
    [deleted]
  - chiph 10y ago
    I'm having trouble visualizing this. The closest I could get is a single unique part for an A380 super-jumbo (typical selling price: $435 million USD)
    - kirab 10y ago
      Imagine a contract which says the contract partner receives e.g. 0.001% of the total revenue for the fiscal year (which could be 10bn Euros) Or you do have a gram price and are selling literally thousands of tons to a big business
      - whatusername 10y ago
        This is clearly why you should price everything in picodollars :) https://www.tarsnap.com/ https://www.tarsnap.com/
      - thaumasiotes 10y ago
        > Imagine a contract which says the contract partner receives e.g. 0.001% of the total revenue for the fiscal year (which could be 10bn Euros) I'm imagining it, and I don't see why storage or computation time would be major obstacles to a calculation you run once a year. Use whatever big integers you want? Suppose we dedicated one $100 hard drive (per year!) to storing all the relevant data. I feel like there would be plenty of space left over, and the budget would cover it.
        kirab 10y ago
        But which advantage would this have over using IEEE 754-2008 decimal floating point numbers?
        thaumasiotes 10y ago
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...

by kirab 10y ago

milesrout 10y ago

I absolutely disagree. If you want to represent currency, for example, you should not use decimal floating point. You should integers, specifically you should use an integer number of tenths of cents, which is pretty widely agreed as the standard unit of currency in a computer (or tenths of yen, for example). You need to be extremely careful about overflow, but you need to be anyway, and should almost certainly just use arbitrary-precision integers.

kirab 10y ago
I absolutely disagree with your disagreement. Please try writing an ERP system where you have a quantity of a billionth of an item price of a billion euros (or an item price of a billionth Euro and a quantity of billions) and tell me which integer type you deem sufficient for this. Additionally please research decimal floating points before disagreeing.
- deleted 10y ago
  [deleted]
- chiph 10y ago
  I'm having trouble visualizing this. The closest I could get is a single unique part for an A380 super-jumbo (typical selling price: $435 million USD)
  - kirab 10y ago
    Imagine a contract which says the contract partner receives e.g. 0.001% of the total revenue for the fiscal year (which could be 10bn Euros) Or you do have a gram price and are selling literally thousands of tons to a big business
    - whatusername 10y ago
      This is clearly why you should price everything in picodollars :) https://www.tarsnap.com/ https://www.tarsnap.com/
    - thaumasiotes 10y ago
      > Imagine a contract which says the contract partner receives e.g. 0.001% of the total revenue for the fiscal year (which could be 10bn Euros) I'm imagining it, and I don't see why storage or computation time would be major obstacles to a calculation you run once a year. Use whatever big integers you want? Suppose we dedicated one $100 hard drive (per year!) to storing all the relevant data. I feel like there would be plenty of space left over, and the budget would cover it.
      - kirab 10y ago
        But which advantage would this have over using IEEE 754-2008 decimal floating point numbers?
        thaumasiotes 10y ago

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...