Live data from Hacker News

64-bit bank balances ‘ought to be enough for anybody’?

tigerbeetle.com

161–170 of 372 posts

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#161
post #104

Earlier quoted context omitted.

> floats cannot correctly represent any non-contrived calculation Like adjusting all your financial calculations to use microcents and partitoning instead of division to keep the result representable by integers? Neither can represent 1/3 even shifted. When you want to do exact calculations with floats, and you can, you just have to set yourself up so that the result is exactly representable, it's not as intractable…

> they represent subsets of the reals Sure. My point is that this subset is useless. Because trying to add, subtract, multiply, or divide members of this set will result in a number outside the set. > When you want to do exact calculations with floats, and you can, you just have to set yourself up so that the result is exactly representable, it's not as intractable as you make it seem. In the general case, you absolu…

I think you're getting the impression that my stance is "floats are usable for all problem domains" when it's really "floating point arithmetic is not the same as approximate calculations."

Nearly all mathematical calculations cause the result to be outside the range of integers. You can't do much else other than subtract without accounting for edge cases. No matter what tool you use you must work with your chosen representation and around its limitations and make sure your domain can be modeled exactly. For example Python's base random function chooses a floating point uniformly in the range [0, 1) but it achieves this by requiring that the result be a multiple of 2^-52 which is exactly representable so rounding doesn't introduce bias.

> If you don't have control of your inputs

Well you clearly do to some degree because you're sure you can model anything you might might receive with fixed sized fixed precision integers. I'm not saying this means you can just switch to floats but that you're doing the same thing, mapping the real life problem domain exactly to a subset of the reals that is closed under the operations you want to perform.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#162
post #43

Specialising 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 cor…

Whenever I input my tax data on forms, it always rounded to the nearest dollar. It was strange that accuracy didn't seem to be a big priority.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#163
"All right, so when the subroutine compounds the interest, it uses all these extra decimal places that just get rounded off. So we simplified the whole thing and we just... we round them all down and just drop the remainder... into an account that we opened."

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#164
post #127
post #77

Earlier quoted context omitted.

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 m…

Before 2009 would you have predicted that a 100 Trillion Dollar bill would never be issued by a central bank?

Germany had notes and stamps in the trillions Marks in 1924 - nothing new there

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#165
post #43

Specialising 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 cor…

Exactly. I think many people start overthinking things in banking. Most accounting/finance departments are ok with rounding pennies every month.

I run a Commercial Real Estate Servicing platform, where we are accruing interest on large balances daily. Our method is to not do the rounding daily, but add up all the numbers for a given period, say a month, and then round to the penny and create a single adjustment rounding transaction along with it. Accounting departments love us for it.

If we rounded daily before storing the amount, the adjustment for accounting is usually a few pennies at least every month they have to make. Our method, it's roughly $0.01 per year with monthly periods, adjusted usually at the very end. Which on a $20MM loan, is very well within the bounds of acceptable.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#166

We could also tax everything above 32 bits, good for people, good for machine

Imagine if the most money you could have is $43 million (rounding!), and it rolled over to 0 if you exceeded that. You'd be paying accountants to keep you as close to the limit as you dare, instead of just cheating on taxes. But not paying them too much, as you're only a multimillionaire.

The real trickle down

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#167
post #77

The 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 m…

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

I lived through hyperinflation (in Brazil). What happened was that, at regular intervals, the old hyper-inflated currency was replaced with a new currency that's 10^3 times less than the original one. Cutting decimal zeros is better for humans, and three is convenient because it matches the usual three-digit grouping (that is, 123.450,00 becomes 123,45). This had to be done because, otherwise, calculators would become useless (most common pocket calculators had only eight digits).

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#168

Earlier quoted context omitted.

BCD makes stored value -> human-readable trivial, at the cost of complicating math on those values. So it's useful for applications where you're mostly doing human input/output stored value. But as soon as you do any non-trivial math on those values, using (fixed point?) integers wins. At the cost of a simple stored value human readable conversion. I'd think most financial applications fall into the category "do math…

I honestly don't understand the argument here or the parent comment makes. Why is a BCD decimal 128 worse at math then a fixed point integer? You are saying it is more CPU efficient? Are you saying some operations with fixed point integer math operations are more accurate then dec128? I've seen this asserted several times, both in the post and in comments, but I've never seen a single concrete example of it being bet…

Most CPUs don't have BCD math instructions, so you need multiple instructions, with probably around a 10-100x slowdown in math.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#169

"All right, so when the subroutine compounds the interest, it uses all these extra decimal places that just get rounded off. So we simplified the whole thing and we just... we round them all down and just drop the remainder... into an account that we opened."

Glad you enjoyed the reference!

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#170
post #155

Specialising 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 did join somewhere that could do it correctly, because they had some very long-running POS software. It could even do things like "split bill three ways" correctly allocating both the spare penny from the division and the tax calculation, such that you could add the bills back together again and get the same numbers as the split bill. Using a "money" class that stores things as integer pennies gets you a long way t…

Integer cents is fantastic for POS software and similar things that deal with at most a few thousand dollars at a time. The place where it starts to fail is when the absolute numbers get really large, not really small. Think "United States Federal Reserve" or "UBS". Then remember that some of these institutions need to deal with accounts denominated in Zimbabwean dollars.
Post reply on HN