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

131–140 of 372 posts

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

#131

Post by SoftTalker »

throwaway894345 wrote: post #52
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,…

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…

If your database has a MONEY or CURRENCY data type, use that.

Just as you should use proper DATE or DATETIME data types for time and not roll your own with strings, integers, seconds-from-epoch, or any other schemes at least if you want to keep your sanity.

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

#132

Post by themerone »

onetimeuse92304 wrote: post #73
tgv wrote: post #67

Earlier quoted context omitted.

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

You can make the same arguments against fixed precision decimal types. My systems represent currencies to 4 decimal places. At that level of precision, rounding/order of operations errors could accumulate much faster than with a 64 bit float.

Decimals are still the way to go, you just have to pick a level of precision acceptable for your application.

My management definitely does not want me spending my time chasing errors over fractions of a pennies. The only time those errors are discovered is when I compare the output of new code against old code.

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

#133

Post by jkestner »

lnxg33k1 wrote: post #71

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.

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

#134

Post by mrloba »

tylergetsay wrote: post #86
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…

For simple accounting I've always used integers and done all operations in cents, only converting on the frontend. what's my downside here? I guess it wouldn't support unit prices less than a penny

If you have different currencies you need to keep track of the number of decimals used, e.g. YEN has 0 decimals, bitcoin has 6, etc. It could even change over time like Icelandic ISK did in 2007. If you have different services with different knowledge about this you're in big trouble. Also prices can have an arbitrary number of decimals up until you round it to an actual monetary amount. And if you have enough decimals, the integer solution might not have enough bits anymore, so make sure you use bigints (also when JSON parsing in javascript).

Example in js: Number(9999999.999999999).toString() // => 9999999.999999998

And make sure you're not rounding using Math.round

Math.round(-1.5) // => -1

or toFixed

(2090.5 * 8.61).toFixed(2) // => 17999.20 should have been 17999.21 8.165.toFixed(2) // => 8.16 should be 8.17

The better solution is to use arbitrary precision decimals, and transport them as strings. Store them as arbitrary precision decimals in the database when possible.

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

#135

Post by em-bee »

onetimeuse92304 wrote: post #59
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…

On my first day in a new company, not even senior dev yet, I met with the head accountant. I asked about her top problems, she said her top problem was that the application would produce different invoice on screen, different invoice when printed as PDF and a different invoice in the accounting software. About 1% of all invoices were affected but due to amount of billing they were doing (telecommunications and advert…

if there ever was a reason to apply DRY at all cost, this is one

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

#136

Post by ceejayoz »

keepamovin wrote: post #124

Reserve Bank of Zimbabwe "100 Trillion Dollars" hahahahaha LOL. Is that real? OMG, that's incredible. Image if this trend kept going: what sign of humanity that new SI units need to be minted first because inflation drives currencies to insane new denominations, rather than cat videos, IoT and porn bulge yottabytes out of bounds?

Zimbabwe underwent a period of hyperinflation.

https://en.wikipedia.org/wiki/Hyperinflation_in_Zimbabwe

They eventually stopped printing currency.

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

#138

Post by yyyk »

rvnx wrote: post #53
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…

I had such case too, the solution is simple: round in favor of the bank / financial institution you are working for

Heh. But usually it's the other way around unless they remembered to specify it the right way. Forgiving $0.01*N customers is cheaper than dealing with an irate customer.

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

#139

Post by michaelt »

onetimeuse92304 wrote: post #59
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…

On my first day in a new company, not even senior dev yet, I met with the head accountant. I asked about her top problems, she said her top problem was that the application would produce different invoice on screen, different invoice when printed as PDF and a different invoice in the accounting software. About 1% of all invoices were affected but due to amount of billing they were doing (telecommunications and advert…

> I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF).

That's actually kinda normal, in some industries.

For example, an amazon marketplace seller's warehouse management system might not be tightly integrated with Amazon's basket/checkout display logic.

In some situations the results of recalculating are supposed to be different. For example, if there's a "5% off when you buy 3 widgets" offer and you check out with 2 widgets in your basket, the offer doesn't apply. But if you checked out 3 widgets, thus getting the offer, then the seller found they were low on stock and could only send you 2, you should get the 5% discount on those 2.

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

#140

Post by toomuchtodo »

im3w1l wrote: post #113
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,…

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

The world runs on "good enough."
Post reply on HN