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

171–180 of 372 posts

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

#171

Post by 38 »

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

> arbitrary precision math library with ability to specify rounding rules

I got you:

https://godocs.io/math/big#example-RoundingMode

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

#172

Post by tech_ken »

>Surprisingly, we also don’t use negative numbers (you may have encountered software ledgers that store only a single positive/negative balance). Instead, we keep two separate strictly positive integer amounts: one for debits and another for credits.

It's funny I've always thought of two-column bookkeeping as a kludge that was invented because the author was unaware of negative numbers. But here there's actually a justifiable technical reason why they're superior (in this specific context)! History is a silly thing

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

#173

Post by koliber »

SoftTalker wrote: post #128
im3w1l wrote: post #113

Earlier quoted context omitted.

> I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correct This observation should tell you that's it actually quite viable to be off as long as the errors are small enough.

Yeah even in university in my intro-level accounting classes they said in the real world nobody cares about discrepancies less than a dollar (and that amount scales with the size of the business). I don't know if that's actually true and I wasn't an accounting major so I don't know what they said in the more advanced classes. But if I imagine myself as a business owner I would be annoyed with my accounting firm if th…

Years of practice have led me to this practical wisdom:

As long as things are consistent, no one cares if you are correct. If you lose a penny in the backend calculation, and the frontend shows the amount without the penny, and the email contains the amount without the penny, and the PDF download contains the amount without the penny, no one will care that there should be a penny there.

It becomes problematic if some places are wrong and some are right, and they are not consistent. You won't get credit for being right in only some places.

As long as the error is small enough to be inconsequential, being consistent is more important than being correct.

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

#174

Post by hef19898 »

Cshelton wrote: post #165
forinti wrote: post #43

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

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

The real reason is because Cathrine Zeta Jones and James Bond actually did implement a program in Malaysia that collects all those rounding errors on a seperate bank account. And since it wenr global, affecting everypne, everyone thinks it ia simply normal.

Or it is because rounding errors happen and accounting is a bitch. The first option makes for a better movie plot so.

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

#175

Post by hef19898 »

marcosdumay wrote: post #160
rvnx wrote: post #75

Earlier quoted context omitted.

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…

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 ultimately. And a general policy of rounding in one direction is the last thing you want an auditor to find.

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

#176

Post by schmichael »

I find the “no negatives” very confusing even in a double entry ledger for reasons the last sentence of that paragraph hints at:

> When you need to take the net balance, the two balances can be subtracted accordingly and the net displayed as a single positive or negative number.

This means you have to reconcile credits and debits using a different type than each of the columns is in. Not a huge deal by itself, but now that secondary type has to be a weird 129 bit integer (or larger) to ensure it can represent every intermediate sum of credits and debits.

If they just would have sacrificed 1 bit they could have used a single signed 128 bit data type for all storage and computation.

I suspect they have to enforce the “all debits and credits are positive” invariant in a number of places anyway (or risk coercing a negative signed 128 input into an unsigned 128 but ledger entry), so why not sacrifice a bit that will probably never be used otherwise anyway and have a uniform structure for numeric types?

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

#177

Post by marcosdumay »

alexvitkov wrote: post #16
Etheryte wrote: post #3

Perhaps I'm the odd one out here, but most financial systems I've had the chance to work with don't actually use numeric types to store values, they use strings or other comparable types. Numeric values are passed to all outside interfaces, but the internal states are written in a way where no bit level issues peddle with the values. I'm wondering what the experience of the wider audience here is?

If by "bit-level issues" you mean bit flips (which you should be worried about), a string doesn't help much - "4" is 0x34 ASCII/UTF-8, flip lowest bit and you get "5" (0x35). I'd imagine if I have to protect against bit-level fuckery something like this would be a better representation: struct Dough { u64 amount; u64 amount_again; u64 amount_just_to_be_really_sure; } that and hardware-level protection of course

That's the kind of thing for what error correction codes were invented.

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

#178

Post by _glass »

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

As much as SAP has problems, this is a solved problem there. In my experiences sometimes this is implemented incorrectly, but discovered very soon, as it's about money. I encountered this when people made some simple calculations on the frontend-side then submitting to the ERP system, where it was discovered because of the emerging inconsistencies.

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

#179

Post by onetimeuse92304 »

kawhah wrote: post #123
onetimeuse92304 wrote: post #73

Earlier quoted context omitted.

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

Let me guess, the last 10 times you had to move jobs it was because of a difference in opinion with your boss about the importance of correcting one-cent-errors in one invoice out of every ten thousand?

Haha... no. But I may be focusing way more towards the reliability than 99.99% or so developers.

The way I solve this problem isn't by constantly hopping projects. I try to find projects that actually require extreme reliability so that I can be doing what I want in an environment where there is a business case for it.

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

#180

Post by koliber »

TN1ck wrote: post #149
out_of_protocol wrote: post #76

Earlier quoted context omitted.

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

Are there actually some systematic approaches to handle these cases? Or are there some libraries making this easier? We have so many places where we keep track of the offset and spread it over the items afterwards to mitigate this. It’s annoying as it’s most often a two step process and e.g. becomes even more complex when you have constrains on the numbers like applying discounts.

In this particular case, it's easier to think of the problem as "allocating $10 among 3 parties" rather than "dividing $10 among 3 parties." The latter insinuates equal distribution. Often, having the 3 parts sum back up to $10 is more important than giving an extra penny to one person and not dividing equally.

What I've used before is "Express the value in pennies. Divide by X (number of parties). Take the whole number part and give it to each person evenly. Take the modulus and distribute it one by one to each remaining party, until there is nothing left."

Example: allocate $10.01 among 3 parties:

1. You have 1001 pennies

2. Divide by 3 - give each person 333 pennies

3. Take the modulo 1001 % 3 - you have 2 pennies remaining. Time to distribute them round-robin!

4. Give one penny to person A. You have 1 penny remaining.

5. Give one penny to person B. You have no pennies remaining.

If you do this many times, randomly establish the order of the parties each time you round-robin them. In that case, no one will be systematically under-allocated, just because their name starts with the letter Z.

This is not a universal truth, and each situation is different. It may not apply to other kinds of money dividing situations.

Post reply on HN