Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tigerbeetle.com

Post reply on HN
Print view View original

231–240 of 372 posts

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

#231

Post by jorangreef »

runeks wrote: post #151
halosghost wrote: post #137

A reminder that this still isn't the correct way of handling money. The correct way is to put it in the type-system [1]. All the best, -HG [1] https://web.archive.org/web/20211014094900/https://ren.zone/...

This only puts currency codes in the type system; and uses rational numbers for amounts. This is definitely useful because you can have the type system tell you if you've implemented e.g. exchange rate conversion incorrectly. But it's also a hassle because you need to reify currency values discovered at runtime as types, which isn't pretty [1]. [1] https://github.com/runeksvendsen/order-graph/blob/eef0006cba...

Yes, and to your first point, TigerBeetle also supports multiple ledgers, explicitly where each ledger is for a separate unit or currency (with isolation enforced by TigerBeetle across different units/currencies).

Thus, TigerBeetle doesn't preclude the use of money types at a higher layer (you would have seen that we tried to emphasize this also in the post).

Another way to think of this, is that we focus on the storage of accounting information by providing high-performance accounting primitives (e.g. execute 8k double entry transactions all within 5ms in a single network roundtrip DB query).

But the accounting policy (rounding etc.) remains the responsibility of the application/organization, since this may differ according to requirements/jurisdiction.

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

#232

Post by [deleted] »

itsoktocry wrote: post #205
vidarh wrote: post #184

Earlier quoted context omitted.

A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us roun…

> A shocking number of people are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. What is your jurisdiction? In Canada, I can't for the life of me imagine the CRA would remotely care about decimal-point accuracy. In fact, most of their online forms explicitly remove the decimals.

[deleted]

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

#233

Post by jorangreef »

throe37848 wrote: post #62

You need to be also handle "origin" or "flavour" of money. Future governments may place various sanctions and limitation on money. So green dollars will be better, Russian dollars not so great and so on. Some money may be owed to local VIP, and should not be confiscated... All that may be mixed on single bank account.

Yes, we do also have various user_data fields for accounts/transactions to record the:

  who / when / where / why / what / how / how much
https://docs.tigerbeetle.com/reference/transfers

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

#234

Post by [deleted] »

masklinn wrote: post #225
amalcon wrote: post #170

Earlier quoted context omitted.

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.

Really small can be an issue when it gets really small e.g. tarsnap’s accounting is pretty infamously done in attodollars (1e-12). U64 only has room for 19 decimal digits so you’re limited to 7 figures up.

[deleted]

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

#235

Post by crazygringo »

weinzierl wrote: post #230

I once argued for using BigDecimal instead of Doubles in an invoicing software but had a hard time to come up with a practically relevant example. Is there an example where it makes a noticeable difference (at least one cent in the final result) that does not involve unrealistic amounts or numbers of items? I'm not arguing for Doubles, just collecting arguments to convince.

I'm curious about this too. If you were engaged in millions of arithmetic operations then I can see how inaccuracies might accumulate in theory, but in practice floating point operations are intentionally designed to minimize that.

And for everyday individual transactions it's hard to see a problem. Maybe the problem is more when you're summing up every single financial transaction for the year? But even in that case, if the smallest financial resolution is a cent, all the floating point noise seems like it would be occurring many decimal points beyond. Even if you're dealing with billions of dollars.

To be clear, I wouldn't do it myself -- I'm too risk-averse, too afraid of unknown unknowns. But it is hard to see what actual real-life negative consequences there would be for 99.9% of businesses, unless I'm missing something? Like the parent commenter, I'm looking for where I'm wrong here.

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

#236

Post by vidarh »

jjgreen wrote: post #220
ilyt wrote: post #207

Earlier quoted context omitted.

> 0.3-0.2-0.1 -2.7755575615628914e-17 And now you overdrafted

Do it a million trillion times and we're talking cents overdrafted (almost)

If you just add up the errors, sure. What is riskier is that you risk tipping values the wrong direction right before applying a rounding step, or end up with an error right before multiplying a now wrong per-unit value with some large-ish factor.

Often these things are not a big problem on their own, but then later gets compounded because someone does something stupid like passing these imprecise values around to be distorted further all over the place.

And sometimes the reason it doesn't become a legal problem turns out to be because your finance department quietly works their way around it by expending expensive manpower accounting for discrepancies that shouldn't be there in the first place, and so increases the cost to the business by many magnitudes over the loss the developers might have assumed to be the worst case (if they're aware of the discrepancy at all).

This is one of those things you can get away with many times, many places, with no ill effects. But when it finally bites you it can get expensive and/or really bad to deal with, and it's fixed by simply never doing money calculations on datatypes with imprecise arithmetic, and having a five minute conversation with your finance team about what your local rules for rounding tax amounts are.

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

#237

Post by cwmma »

weinzierl wrote: post #223
onetimeuse92304 wrote: post #24

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

"For accounting you should only ever use arbitrary precision math library" I'm a bit surprised by this advice. I thought the common wisdom was to use a decimal type like BigDecimal in Java.

BigDecimal is an arbitrary precision type so using BigDecimal is how you would follow said advice in Java.

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

#238

Post by RamblingCTO »

lxgr wrote: post #150
RamblingCTO wrote: post #118

Earlier quoted context omitted.

Not sure about that. In Germany, especially SMEs, no one cares about cents. Your tax reports are done in rounded Euros anyway. People, companies, and the taxation and financial state dept. are well aware of rounding issues, different ways to round that no one really cares about cents. Besides that, using BigDecimal with two decimal places is sufficient in the java world imho. Depends on your use case. I'm entirely sc…

Only final values are rounded to full Euros (down, if I remember correctly). If a large taxpayer starts rounding down as part of intermediate calculations of their tax liability, I think they'd get some questions. But yes, rounding does happen a lot – what's important is that everybody uses the same, transparent rules for that, or it becomes impossible to double-check somebody's books, tax declaration, invoice etc.

Well, how much money can you save by efficient rounding? Surely not that much that anyone would bother. There's a thing called "Kaufmännisches Runden", which is kind of cheating as well.

> But yes, rounding does happen a lot – what's important is that everybody uses the same, transparent rules for that, or it becomes impossible to double-check somebody's books, tax declaration, invoice etc.

They don't, that's why it doesn't matter that much ;)

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

#239

Post by eternityforest »

hef19898 wrote: post #175
marcosdumay wrote: post #160

Earlier quoted context omitted.

You added 10 of those items as inventory with a total value of 14.33, then you sold each individually as a total value of 14.40. After that transaction, your inventory account has -0.07 on it, but there aren't any items at all there.

From experience, those differences surface during stock taking. Amd most companies are really bad at that. And if they surfacey they are corrected by inventors adjustments (in unit of measure, not value, which is a differwnt can of worms). As long as those adjustments aren't to extreme, nobody really cares. A good accountant so will sooner or later investigate those rounding errors, as they will show up somewhere ult…

So accountants are like number detectives doing what's essentially debugging work just like a coder would?

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

#240

Post by c2h5oh »

weinzierl wrote: post #223
onetimeuse92304 wrote: post #24

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

"For accounting you should only ever use arbitrary precision math library" I'm a bit surprised by this advice. I thought the common wisdom was to use a decimal type like BigDecimal in Java.

BitInteger and BigDecimal are arbitrary precision types in Java
Post reply on HN