We could also tax everything above 32 bits, good for people, good for machine
64-bit bank balances ‘ought to be enough for anybody’?
71–80 of 372 posts
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#72Earlier quoted context omitted.
What do you do if heavy deflation causes the government to release a $0.001 coin? A cent isn't a fundamental unit. Edit: as another hypothetical, what if the $0.001 coin is released to support micropayment use cases?
Worth noting that hyperdeflation has never happened, which is kind of interesting because it theoretically could.
It's not really symmetric. It's not hard to imagine a situation where everyone stops believing something (a currency) is not worth anything anymore. But why would somebody believe that nothing except currency is not worth anything?
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#73Specialising 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,…
For very simple billing, arbitary precision sounds like overkill, as do rounding, and order of operations.
Oh, sure, because when you are a small company you don't care that people get correct invoices.
I can certainly sympathise with this stance. There is about a billion things you can do better but you have limited time to do anything so you have to prioritise. And if one invoice in ten thousand is incorrect by one cent, and only one client in ten thousand who received the wrong invoice will actually find it out, then it is hard to argue you should be spending time on fixing this one problem.
Just don't say you can do accounting correctly on floats and we will remain friends.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#74Earlier quoted context omitted.
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 cor…
I had such case too, the solution is simple: round in favor of the bank / financial institution you are working for
I've worked in banking.
I assure you, I would have had a million bugs filed on that before it even hit production.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#75Earlier quoted context omitted.
I had such case too, the solution is simple: round in favor of the bank / financial institution you are working for
No, it does not work this way. Any good accountant will see a different in values, even smallest one, as a sign of an incorrect calculation. Does not matter which way it goes, they will feel compelled to figure out who is wrong. At least a good accountant will.
There is no accounting error; let's say customer has purchased / used a service for 1.433 USD.
You issue an invoice for 1.44 USD (aka, amount due), then the 1.44 USD is used as a basis for accounting and is all consistent.
Then, if you are a nice company and the situation applies in your case, you may issue a credit in favor of the customer for 1.44 USD - 1.433 USD that will be used as a discount on a future invoice
The best part is that the moment where you decide to issue the credit invoice or not, is the perfect moment to track the rounding errors and even keep a very detailed journal of the entries (e.g. for auditors).
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#76Specialising 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,…
What are the specific challenges to writing financial software? What are common mistakes you see? What are common data structures for representing money (both the common incorrect implementations but also the correct implementations)? Also, provided you have a data structure that can represent money, you should presumably be able to serialize that data structure and store or send it just like any other data, right? W…
String (json), decimal/numeric (db) is enough to passively store amounts. Calculations and rounding going to be funny though. E.g. split $10 bill in 3 exactly the same parts, store, sum up to $10 again
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#77The 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 th…
I think it's the worst example. I very much doubt we will ever see the price of, say, a car approach a billion billion dollars (or cents). It's too many zeros for people to work with on a daily basis. I think what will happen is that, at regular intervals, the old hyper-inflated currency will be replaced with a new currency that's, say, 2^32 times less than the original one.
Besides, if you think a billion billions might be reached (64 bits) then why wouldn't a billion billion billion billions also be reached (128 bits)? 128 bits seems just as arbitrary as 64 bits in this context.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#78I 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
Every financial system I've seen uses either decimal floating point or integers. Using normal float is just asking for trouble.
Float can be justified where performance is more important than accuracy. Which does happen sometimes in the financial world.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#79It sounds like they use a rational number with a fixed power of 10 denominator. Much like if they used Go's *big.Rat type with a fixed denominator of say 100 or 100000 depending on the currency, then the numerator they are moving from a 64 integer to a 128 bit integer.
I personally don't see the advantage this has over a decimal 128 numeric value. In either situation, if you have 10 / 3, you will get 3.33 and need to round. Ultimately, the math concepts in finance are different then in abstract math. If for some reason you need to divide $10 by 3, it should result in three numbers: 3.33, 3.33, and 3.34.
But fundamentally, I don't see how their fixed integer math fixes something as fundamental as that, over a standard decimal 128 representation.
Re: 64-bit bank balances ‘ought to be enough for anybody’?
#80Earlier quoted context omitted.
Wouldn't we just re-base the currency at that point?
That “just” is doing some very heavy lifting. That could potentially involve having to update almost every financial system worldwide given the US dollar’s position as a global reserve currency.
Yes, but I think a "new dollar" is more likely than the US putting up with million-dollar bills. I guess it's a tough call which one is more embarrassing.