4 ms·

Re money systems: I have found that problems arise no matter whether floats are used or something else: The system can be too exact. My current approach is tha

by rho4 3y ago

Re money systems: I have found that problems arise no matter whether floats are used or something else: The system can be too exact. My current approach is that I try to guess (or ask) how a customer understands or checks a statement/invoice. The customer usually takes a calculator and enters the rounded numbers they see. I then try to do all programmatic calculations exactly the same way: Operation - round - operation - round etc, with rounding-steps at exactly the same places where these values will be visible to the customer, and with the same number of decimal places (can vary). Sometimes that is not possible of course, which is usually solved with a final row called 'rounding errors in the customer's favor'). For my (smaller) systems I find floats sufficient and easier to work with compared to the alternatives, which tend to make code very verbose and annoying to read.

fellerts 3y ago
I thought "money systems" always worked in whole units of some fraction of your currency, e.g. "millicents" or similar, and shunned floating point arithmetic like the plague. > The system can be too exact Indeed, high precision, low accuracy! Fixed-point arithmetic can be both precise and accurate if everyone agrees on the same system. Maybe we don't, and that's the problem?
- gpderetta 3y ago
  In Europe, after MIFID II, equities are priced with tick sizes (i.e. the minium whole unit) that depend on the magnitude of the price, i.e are de-jure (decimal) floating points that behave weirdly.
- doubloon 3y ago
  money systems work with whatever tool is convenient to the operations staff which these days is typically Microsoft Excel and Visual Basic, neither of which come with a built in Decimal type. this will typically get transmuted through multiple layers of javascript, xml, back end java, cobol, SQL, python, some domain specific language, and back again.
- nyrikki 3y ago
  IBM partially has a hold on banking because they have supported decimal floating point. By switching binary floating-point from radix 2 to radix 10 (decimal exponents) they get rid of some of the problems. IEEE has had these Decimal types for a while, but IBM is the only company shipping CPUs with them. Fixed decimal is still used where appropriate, but Decimal floating point is a critical feature for some processes. While personal taxes typically drop the cents, tariffs and other taxes are often small percentages as an example. There are software implementations if you don't need performance. But Decimal64 has a lot more represented values and it is easier to trap on some edge cases. As Decimal floating point types were added into C23 we will see if hardware support follows. Note this is also why HP calculators were more accurate for a given bit size, because the engineering ones used radix 10 floats.
  - rerdavies 3y ago
    What does radix 10 floating point bring to the table in terms of precision other than a whole new set of rounding problems? As far as I know, all accounting systems use 'round to nearest cent' integers (or whatever the lowest denomination is in a given currency). Is there a case where calculations using integer cents is in any way inferior to radix-ten fixed point?

by rho4 3y ago

fellerts 3y ago

I thought "money systems" always worked in whole units of some fraction of your currency, e.g. "millicents" or similar, and shunned floating point arithmetic like the plague. > The system can be too exact Indeed, high precision, low accuracy! Fixed-point arithmetic can be both precise and accurate if everyone agrees on the same system. Maybe we don't, and that's the problem?

gpderetta 3y ago
In Europe, after MIFID II, equities are priced with tick sizes (i.e. the minium whole unit) that depend on the magnitude of the price, i.e are de-jure (decimal) floating points that behave weirdly.
doubloon 3y ago
money systems work with whatever tool is convenient to the operations staff which these days is typically Microsoft Excel and Visual Basic, neither of which come with a built in Decimal type. this will typically get transmuted through multiple layers of javascript, xml, back end java, cobol, SQL, python, some domain specific language, and back again.
nyrikki 3y ago
IBM partially has a hold on banking because they have supported decimal floating point. By switching binary floating-point from radix 2 to radix 10 (decimal exponents) they get rid of some of the problems. IEEE has had these Decimal types for a while, but IBM is the only company shipping CPUs with them. Fixed decimal is still used where appropriate, but Decimal floating point is a critical feature for some processes. While personal taxes typically drop the cents, tariffs and other taxes are often small percentages as an example. There are software implementations if you don't need performance. But Decimal64 has a lot more represented values and it is easier to trap on some edge cases. As Decimal floating point types were added into C23 we will see if hardware support follows. Note this is also why HP calculators were more accurate for a given bit size, because the engineering ones used radix 10 floats.
- rerdavies 3y ago
  What does radix 10 floating point bring to the table in terms of precision other than a whole new set of rounding problems? As far as I know, all accounting systems use 'round to nearest cent' integers (or whatever the lowest denomination is in a given currency). Is there a case where calculations using integer cents is in any way inferior to radix-ten fixed point?