[deleted]
64-bit bank balances ‘ought to be enough for anybody’?
41–50 of 372 posts
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#42Earlier quoted context omitted.
Not true for any of the finanical systems I've worked for the credit/derivatives/FI/etc desks of some of the largest investment banks down to the systems for the virtual card e-money issuer in the UK that I founded.
They use integers to store cents or fraction of cents, and that's it (or the equivalent of MySQL "DECIMAL" format if not using integers)
When you say "they" I could tell you exactly what format we stored card balances in, including the implied point position for different currencies (not the same for GBP and (say) JPY) and none of it involved DECIMAL!
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#43Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules. If your programming environment/language does not have one, it is unsuitable to be used for accounting, billing, invoicing, payments, etc. Having the underlying library is,…
I have a personal anecdote on this subject. A long time ago I worked at a bank and I had to calculate a large number of accounts regarding agricultural loans. These were state sponsored loans. When I finished my task (this was a Java job), I found that sometimes the results were off by $0.01. So I asked my boss how I should do the rounding, to which he replied that an error of up to $1 was acceptable. If I recall correctly, the amounts where in the hundreds and thousands.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#44Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules. If your programming environment/language does not have one, it is unsuitable to be used for accounting, billing, invoicing, payments, etc. Having the underlying library is,…
Would IEEE decimal128 be sufficient (instead of arbitrary precision)?
"Formally introduced in IEEE 754-2008, it is intended for applications where it is necessary to emulate decimal rounding exactly, such as financial and tax computations."
https://en.wikipedia.org/wiki/Decimal128_floating-point_form...
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#45I was under the impression that BCD was generally recommended for money, often because of (IEEE?) rounding and machine precision/epsilon: * https://en.wikipedia.org/wiki/Binary-coded_decimal * https://en.wikipedia.org/wiki/Machine_epsilon
I've never seen anyone use floating point for money in their bespoke applications
Nubank used floating point - not in their real backend systems, but somewhere in their app. It was a bit amusing when people on Twitter found out certain very specific, arbitrary-looking amounts were not able to be transferred, then the computer scientists noticed what they had in common.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#46At some point denominations will be 2^20 USD per note. As inflation grows, in the USA and others, a 64bit won’t be enough. Money is imaginary store of value we all agree on. The actual number changes.
Wouldn't we just re-base the currency at that point?
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#47Earlier quoted context omitted.
They use integers to store cents or fraction of cents, and that's it (or the equivalent of MySQL "DECIMAL" format if not using integers)
When you say "they" I could tell you exactly what format we stored card balances in, including the implied point position for different currencies (not the same for GBP and (say) JPY) and none of it involved DECIMAL!
> They use integers to store cents or fraction of cents or DECIMAL as alternative if not using integers
Seemed rather clear, what's difference with what you say ?
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#48Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules. If your programming environment/language does not have one, it is unsuitable to be used for accounting, billing, invoicing, payments, etc. Having the underlying library is,…
Would IEEE decimal128 be sufficient (instead of arbitrary precision)? "Formally introduced in IEEE 754-2008, it is intended for applications where it is necessary to emulate decimal rounding exactly, such as financial and tax computations." https://en.wikipedia.org/wiki/Decimal128_floating-point_form...
Hypothetical solutions that do not exist are none of my concern.
Did you know different countries and different currencies have different rounding rules, for example for tax-related calculations? Does "IEEE decimal128" support this? Unless you can get all countries on our planet to agree on a single standard, any solution that does not allow specifying rounding rules is pretty much useless (unless you want to implement rounding yourself which tends to be very tricky -- I know because I attempted this couple of times).
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#49Still not enough for storing Ethereum/ERC20 balances (256-bit)... :(
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#50The hyperinflation example is quite interesting because:
1) If it happens, it happens rapidly, and you don't want to implement this in a hurry
2) If it happens, the global economy could well be melting down, and your financial institution will have other priorities to attend to
3) Retaining existing staff, and hiring new engineers, will be challenging at best
You really don't want to be implementing this change in those circumstances.