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

321–330 of 372 posts

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

#321

Post by LAC-Tech »

tech_ken wrote: post #317
LAC-Tech wrote: post #312

Earlier quoted context omitted.

This is also the way to do it if you want a number that multiple nodes can edit independently. When you sync back up, do a big tally at the end, and that's your final number. (This constitutes a CRDT, and is known as the Positive/Negative Counter).

The idea is similar/equivalent to a stack of git deltas yeah? Each line is a change of one of two types and then you combine them to get a net change?

I'm actually not too familiar with git deltas, but that does sound very similar to an Observed/Removed Set, another CRDT.

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

#322

Post by blibble »

RamblingCTO wrote: post #118
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,…

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…

they'd probably care if you're compounding interest daily on that rounded up euro

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

#323

Post by blibble »

hot_gril wrote: post #274

> For the same reason, digital currencies are another use case for 128-bit balances, where again, the smallest quantity of money can be represented on the order of micro-cents (10-6)… or even smaller. To give a concrete example, Ethereum has a lot of precision (1 ether = 10^18 wei), and there are like 120M ether, so that's more than 64 bits just to represent the supply. Idk though, is this a real concern with traditi…

> Idk though, is this a real concern with traditional finance

CME have contracts with 1/128ths of a dollar

they also have a tenancy to add another power of 1/2th every 10 years or so

this causes problem for fixed point, but amusingly this works perfectly well with floating point

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

#324

Post by chasd00 »

Dylan16807 wrote: post #310
hiatus wrote: post #293

Earlier quoted context omitted.

> That depends on whether the hundred-billion-dollar corporation cares about being off by a dollar. How many hundred billion dollar corporations are private? Public companies would care a great deal about accounting accuracy.

Is it worse for a hundred billion corp to be off by a dollar than for a hundred million corp to be off by a third of a penny?

it's not so much how much it is off but that it's off at all. If the numbers don't add up then they don't add up. If there's any kind of difference then it has to be found and accounted for and it becomes a needle in a haystack search to account for the difference. Think about trying to find $0.05 spread across hundreds of thousands of transactions due to rounding issues.

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

#325

Post by munificent »

lxgr wrote: post #219
ilyt wrote: post #207

Earlier quoted context omitted.

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

Floating point calculations without some final rounding step before presentation/export/storage are almost always wrong, since you're implying much more precision than is justified by your source data.

Ths problem isn't rounding the final result. The problem is that the source data itself can't be accurately represented.

There is no floating point value equal to 0.3.

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

#326

Post by hot_gril »

zarzavat wrote: post #267
ilyt wrote: post #262

Earlier quoted context omitted.

2^63 / 100 Trillion = 9.2E6 so even in this case you have few decimal positions left.

You may be overlooking the potential for someone to own more than one of those $100T bills. Apparently it was worth about 30 USD at the time.

If $100T = 30 USD, then probably nobody will mind if we round to the nearest $1B. Just like how I have no way to compensate someone for less than 0.01 USD.

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

#327

Post by manicennui »

lxgr wrote: post #314
manicennui wrote: post #259

Earlier quoted context omitted.

I agree with the parent. Almost everyone thinks floats are fine. I work in lending, and many of my coworkers, who claim to have CS degrees, do not understand floats at all.

GP isn't just saying "don't use floats", though. (And even that is only a heuristic: It's possible to get correct results using floats, but you need to be very diligent about when and how you round, so in practice it's easiest to just avoid it.) They're saying that only arbitrary precision arithmetics are acceptable, and additionally claiming that everybody else in the world gets money arithmetics wrong. I doubt both…

Arbitrary precision decimals are the best solution in most cases. I have worked at multiple companies where people represent currency with floats and then wonder why they get strange results in some cases.

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

#328

Post by munificent »

jorangreef wrote: post #209
Jabrov wrote: post #191

Earlier quoted context omitted.

How are they superior though? What do they gain by doing this (other than added complexity)?

Hey! Joran from TigerBeetle here. (I know this only because I somehow happened to major in Accounting back in university), but when you represent a general ledger of accounts, there are always two positive columns for amounts in any given account, one for debits, the other for credits. The golden rule is that you always add to either column. You always preserve information. To see why two columns (or two integer bala…

> You always preserve information.

Using two positive numbers preserves some information, but still destroys plenty. Just less than a single signed number would. Consider two accounts:

    1. An account A with a debit balance of $1m and a credit balance of $0, and
    2. An account B with a debit balance of $1m and a credit balance of $0.
One of those was opened by a lottery winner last week who did a single transaction dropping in their winnings. The other was opened by a retiree 60 years ago who has been dripping small deposits in for their entire working history. Which is which?

That distinction is still lost by summing debits and summit credits.

To really preserve information, you'd need the full list of all transactions. But, obviously, that comes at a significant performance cost. So the way to look at storing sums for debits and credits is that it's a trade-off which gives you a little more information than just a single balance but is still a relatively small fixed-size amount of data.

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

#329

Post by vidarh »

Merad wrote: post #248
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 who work with software that handles money are just winging it. I worked on a project once that handled payment processing functionality for other products at the company (it was a B2B SaaS where clients could take payments through our software). We also handled payments related billing, since the clients would owe fees to us and to our payments gateway for their transactions. The payments…

I think that's a case for just dropping that cent. As long as it's your own money and not tax you're underreporting it's not a problem as long as it's consistent.

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

#330

Post by hot_gril »

hot_gril wrote: post #281
JeremyNT wrote: post #276

Earlier quoted context omitted.

> Idk though, is this a real concern with traditional finance? Zimbabwe had their huge bills, but I assume the small ones were unused. Just like you round US cents, you could probably round their currency at some cutoff. If you were processing Ether outside the blockchain, you'd probably round somewhere too. Yeah... I started reading this article and was waiting for the crypto angle, because in normal finance I don't…

Even in cryptocurrency, I feel like the level of precision is mainly aspirational + cuz they can. Who cares about 1 wei in the context of a transaction that costs around 100 trillion wei on its own? The smallest unit of ether I've ever seen in any kind of UI is 1 gwei (1 billion wei).

Forgot to also add, cause various parts of a cryptocurrency ecosystem are much harder to change than traditional finance. So I can see why they throw in a ton of 0s and use 256-bit ints just in case.
Post reply on HN