64-bit bank balances ‘ought to be enough for anybody’? • Hacker News Board

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

#241

Post by kemotep » Tue, Sep 19, 2023, 4:48 PM UTC

eesmith wrote: post #89

DamonHD wrote: post #31

Earlier quoted context omitted.

Actually that would break so many things (the cent as the smallest unit in law and in custom where that is currently the case) that governments may by preference issue a whole new currency instead of stir that pot.

I thought the smallest unit in the US was the mill. https://en.wikipedia.org/wiki/Mill_(currency) > https://www.law.cornell.edu/uscode/text/31/5101 says "United States money is expressed in dollars, dimes or tenths, cents or hundreths,[1] and mills or thousandths. A dime is a tenth of a dollar, a cent is a hundredth of a dollar, and a mill is a thousandth of a dollar." > [1] So in original. Probably should be “hundre…

This year on our local ballot there is a tax levy to approve an increase to the property tax by 5 mills per 100,000 dollars of assessed property value. Allegedly allowing them to raise a few million over the next 10 years to pay off an addition to the school.

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

#242

Post by r00fus » Tue, Sep 19, 2023, 4:48 PM UTC

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 with ability to specify rounding rules

Do these rounding rules need to vary by jurisdiction?

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

#243

Post by zephyrus76 » Tue, Sep 19, 2023, 4:49 PM UTC

It's interesting that even the current financial system fits so snugly into 2^64! Global GDP = $100T = $10^14. If we imagine global assets being worth 10x GDP, that's $10^15. 2^64 = 1.8 * 10^19. If people care about measuring values to precision at $0.0001, that's about the limit.

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

#244

Post by kemotep » Tue, Sep 19, 2023, 4:51 PM UTC

kybernetikos wrote: post #63

jl6 wrote: post #33

Earlier quoted context omitted.

Worth noting that hyperdeflation has never happened, which is kind of interesting because it theoretically could.

I believe that economists generally think that a small amount of inflation is good for the economy, and that deflation is bad (because it leads to reductions in spending and investment, potentially causing a vicious circle). It's also relatively easy to counteract - just print more. In order for hyperdeflation to occur you'd need a currency where the issuing body didn't believe deflation was bad, or didn't care.

Bitcoin has a hyper deflationary monetary policy hard coded in.

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

#245

Post by PH95VuimJjqBqy » Tue, Sep 19, 2023, 4:52 PM UTC

helpfulmountain wrote: post #189

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…

Why would it be wrong to use floats? That would have been my default assumption

floats are an imperfect representation of real numbers and as such, there are an infinite count of real numbers that cannot be accurately represented with floats (and doubles).

It gets even worse when you start doing calculations on floats/doubles.

These inaccuracies are ok for a lot of things. graphics often uses floats and the errors are small enough they don't matter.

But currency absolutely needs to be accurate, and for that reason, floats/doubles are in appropriate.

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

#246

Post by ska » Tue, Sep 19, 2023, 4:52 PM UTC

r00fus wrote: post #242

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 with ability to specify rounding rules Do these rounding rules need to vary by jurisdiction?

Absolutely. IIRC most tax codes have specific rounding rules. Also e.g. some countries have done away with pennies or penny equivalents and have rules about how you are supposed to handle that, etc.

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

#247

Post by pixl97 » Tue, Sep 19, 2023, 4:53 PM UTC

vidarh wrote: post #222

j16sdiz wrote: post #196

Earlier quoted context omitted.

in my experience, these are often written off as error. if the error is less than their hourly salary rate, it don't even worth mentioning. if it worth a day or two of salary, its nice to fix but never a priority

For it to be written off as error you need to know the discrepancy, which means you need to know what it's supposed to be. When e.g. calculating the VAT or sales tax you owe the government, if the rounding deviates from legal requirements then unless it's in their favour you can be in for a bad time.

I think for most large businesses there are pretty considerable error bars here. If you say you owe 1,000,000 a year in VAT and the government says you owe 1,010,000 it's cheaper to pay the difference then dig into why it's off.

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

#248

Post by Merad » Tue, Sep 19, 2023, 4:55 PM UTC

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…

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 gateway we worked with calculated their fees to a thousandth of a cent, but of course we could only bill whole cents. So basically every billing period there would be a < $0.01 balance due that carried over to the next bill, and every so often the carryover would add up to a full cent that needed to be charged. When we implemented our MVP we (engineering) explained this to the product and business teams, and it blew their minds. Our suggestion was to have a tooltip on the 1 cent charge with a link to a help article explaining how the accounting worked, but they were strongly against it and had us list the 1 cent as something like "other fees" with no explanation. They seemed convinced it was a thing that would happen only rarely, even as we were telling them otherwise. Anyway, that 1 cent charge just infuriated clients for some reason, and every month or two we'd get bug reports about it or requests to explain why it kept showing up. Fun times...

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

#249

Post by jaclaz » Tue, Sep 19, 2023, 4:56 PM UTC

eesmith wrote: post #202

jaclaz wrote: post #112

Earlier quoted context omitted.

The authors of the spec made some provisions, and very likely all of them are useful and correct, the issue is how the programmers will use them, and in some cases there isn't even a "correct" solution that everyone uses. A classic example in invoicing is an item that is advertised for 60.00 (to the final user) VAT 10% included. If you try making an invoice for that sum in a few programs you will find three or four w…

Yes, it isn't possible for the software to know your local accounting laws and practices. My point is it's probably better to use existing, well-tested provisions than to build your own from scaled integers, to get one of those three results. As a bonus, you might get hardware support in the future.

Yes, I understand what you are saying, I was highlighting that those (if adopted) would only fix (maybe) part of the problem, they are just (better) tools.

At the end of the day what I want (and I presume any other customer wants) is a correct invoice with the correct net, tax and total, and this will only happen when (if) the programmer understands the base issues and uses the correct library/algorithm/whatever.

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

#250

Post by singleuse715185 » Tue, Sep 19, 2023, 5:00 PM UTC

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

nobody cares about precision in financial calculations except for nerds. particularly areas like reporting tend to have significant errors, and not just sigma.

this is now a fintech anecdotes thread, but my first ever fintech job was part of a two man special priviledges team directly under a director of X at one of the sifis. we were supposed to cut across multiple departments and through red tape with the main goal if eliminating significant overhead in certain processes (we brought some multi-day multi-step calculations down to 8 minutes in one instance, 2 minutes in another, kept us on a vendor list for a very very very long time). i didn't know how things are done, so i used bigdecimal throughout, with a lot of precision and explicit rounding rules. i did back of napkin numerical analysis for at least inner loop code. we duplicated work done by other departments (!!!), things like instrument pricing, because we couldn't wait for their batch jobs to complete. at the end we were getting from slightly to wildly different results. it took a lot of conversations with business to realize that 1) our calculations were correct 2) for them to realize what the sources of errors were and where they were coming from 3) for everyone to just kind of go eeeehh not a big deal.

i wrote a translator for a subset of j/k to java bytecode using java asm, i was pretty proud of that system, because it allowed to express pricing rules in a what i thought was much more readable way, dynamic reload without restart, but man i am very very sorry for the developers who inherited that system.