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

181–190 of 372 posts

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

#181

Post by TheCoelacanth »

projektfu wrote: post #121
TheCoelacanth wrote: post #94

Earlier quoted context omitted.

Also many types of operations could give you the wrong result from incorrect rounding. E.g. let's say you're calculating 10% of $1.01 ten times and adding the result together. The correct result is $1.01, but with your method you will get $1.00.

The correct answer will depend on the specifics of your environment. In some places, tax is calculated per line item. If you go to a dollar store and buy 10 items with 7.3% sales tax, it adds up without those 0.3¢ bits. In other places, the tax is supposed to be calculated on the total for the tax category in the sale. If you wanted to keep it by line item you'd need the extra digits of precision.

Well, yes, which is why you need to be in control of your rounding and not just let the width of data type you chose for the implementation dictate that.

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

#182

Post by _glass »

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…

I love how small details, like rounding always up for 2.50 would be significantly skewing the numbers to the higher values, so there are functions like ROUND_HALF_EVEN that would round up on even numbers, and down on uneven ones.

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

#184

Post by vidarh »

lxgr wrote: post #145
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,…

The article is about data types for storage, not for intermediary values used as part of calculations, though. Are you proposing that everybody is storing monetary values "wrong", too? And as a meta-point: > I have been fighting over this with countless people, teams and companies. [...] I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correctly [...…

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 round it wrong, to the wrong number of digits. And had we e.g. done something grossly incompetent like used floats for those calculations it most certainly would have been wrong, but so would it if I used fewer than five digits past the decimal point or failed to round in the right direction after that.

It's usually not hard, but it requires being aware that you need to look up the right rules. And know better than using floats.

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

#185

Post by undersuit »

Man, reminds me of my first work project, we rebuilt the time clock in 2006 for our department. I knew about inaccuracies in floating math so I thought I was taking precautions, but in the end my first native PHP float implementation introduced enough drift in just the hours field that we'd lose $40 a year. Rebuilt for the Decimal object and it lasted long enough until the entire organization bought it's own COTS solution.

Now I'm trying to remember if I watched Office Space before or after...

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

#186

Post by meekaaku »

rvnx wrote: post #75
onetimeuse92304 wrote: post #60

Earlier quoted context omitted.

No, it does not work this way. Any good accountant will see a different in values, even smallest one, as a sign of an incorrect calculation. Does not matter which way it goes, they will feel compelled to figure out who is wrong. At least a good accountant will.

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…

One can use more than 2 decimal places for rates, but final invoicing has to be two decimal places (atleast in most countries). Banks/tax authorities dont carry anything beyond 2 decimal.

Eg: fuel is usually priced 3 decimal, so 4 gallons x 25.5444 usd/gallon gives = $102.1776 to 4 dp, but will be billed as $102.18

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

#187

Post by paxys »

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?

The financial systems you've used never needed to add two numbers together?

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

#188

Post by themagician »

Shrezzing wrote: post #50

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…

By the time this is a problem the currency has collapsed and no one is using it anymore.

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

#189

Post by helpfulmountain »

vidarh wrote: post #184
lxgr wrote: post #145

Earlier quoted context omitted.

The article is about data types for storage, not for intermediary values used as part of calculations, though. Are you proposing that everybody is storing monetary values "wrong", too? And as a meta-point: > I have been fighting over this with countless people, teams and companies. [...] I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correctly [...…

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…

Why would it be wrong to use floats?

That would have been my default assumption

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

#190

Post by Nzen »

tgv wrote: post #67
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 very simple billing, arbitary precision sounds like overkill, as do rounding, and order of operations.

I enjoyed Mark Dominus's blog post [0] about the billing system he cowrote, moonpig. It restates much of the other responses, namely that ignoring infinitesimal errors/rounding would have instilled a culture of - at minimum - doubt. Perhaps another way to see this is to look at a visualization [1] of the discontinuous coverage that floating point gives to the numbers we want to represent.

[0] https://blog.plover.com//prog/Moonpig.html#fp-sucks

[1] https://observablehq.com/@rreusser/half-precision-floating-p...

Post reply on HN