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

61–70 of 372 posts

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

#61

Post by Spivak »

fidotron wrote: post #26
Waterluvian wrote: post #12

Earlier quoted context omitted.

Floating point feels like an incredibly grokkable concept that was just not taught well for a long time. Maybe too mathematically (of course). Or maybe that was just my experience. I feel like any dev team should pick up a copy of this for on-boarding: https://jvns.ca/blog/2023/06/23/new-zine--how-integers-and-f...

Floating point being grokkable doesn’t make it any more suitable for this application. Floating point is inherently an approximation - your bank balance should not be an approximation.

> Floating point is inherently an approximation - your bank balance should not be an approximation.

I think this is a perfect example of bad floating point teaching. Floating point is not an approximation in any sense. If the numerical result of your calculation is representable in floating point you will get an exact answer always. And for results that aren't representable you decide exactly what should be done about that. It's like saying integers are an approximation because 5/2 == 2.

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

#62

Post by throe37848 »

You need to be also handle "origin" or "flavour" of money. Future governments may place various sanctions and limitation on money. So green dollars will be better, Russian dollars not so great and so on. Some money may be owed to local VIP, and should not be confiscated... All that may be mixed on single bank account.

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

#63

Post by kybernetikos »

jl6 wrote: post #33
8organicbits wrote: post #18

Earlier quoted context omitted.

What do you do if heavy deflation causes the government to release a $0.001 coin? A cent isn't a fundamental unit. Edit: as another hypothetical, what if the $0.001 coin is released to support micropayment use cases?

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.

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

#64

Post by rvnx »

atemerev wrote: post #28
bowsamic wrote: post #10

Earlier quoted context omitted.

I've never seen anyone use floating point for money in their bespoke applications

You _can_ use floating point if you are very careful and know what you are doing and know about decimal normalization (see e.g. OpenHFT implementation for high-frequency trading: https://github.com/OpenHFT/Chronicle-Core/blob/ea/src/main/j... ) But if you are not an expert, you better stick to BigDecimal and absorb the performance costs.

Nice share! Interesting sorcery in their code:

> final double residual = df - ldf + Math.ulp(d) * (factor * 0.983);

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

#65

Post by twodave »

forinti wrote: post #43
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 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…

https://wiki.c2.com/?BankersRounding

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

#66

Post by jon-wood »

mbg721 wrote: post #46
matt3210 wrote: post #29

At some point denominations will be 2^20 USD per note. As inflation grows, in the USA and others, a 64bit won’t be enough. Money is imaginary store of value we all agree on. The actual number changes.

Wouldn't we just re-base the currency at that point?

That “just” is doing some very heavy lifting. That could potentially involve having to update almost every financial system worldwide given the US dollar’s position as a global reserve currency.

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

#67

Post by tgv »

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.

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

#68

Post by Waterluvian »

dahfizz wrote: post #19
Waterluvian wrote: post #2

I’m a bit surprised that these two concepts are seen together. I’d of thought that financial math and data management would always be done with some level of abstraction so it doesn’t matter at all what your computer’s implementation is. Then again, 128 bits is plenty for microcents or whatever the minimim unit is. I’m guessing back in the day when things were 32 bit or less, there were entire financial database impl…

> be done with some level of abstraction so it doesn’t matter at all what your computer’s implementation is. This still doesn't do that, its just integer math. It doesn't matter how your CPU implements it, as long as `x = a + b` gives the correct value for x. You don't have to immediately reach for an abstraction layer when you hear the word "bits" ;)

But without a sufficient stratigraphy of abstractions, I can't ever dig down if I run into issues! ;)

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

#69

Post by Waterluvian »

fidotron wrote: post #26
Waterluvian wrote: post #12

Earlier quoted context omitted.

Floating point feels like an incredibly grokkable concept that was just not taught well for a long time. Maybe too mathematically (of course). Or maybe that was just my experience. I feel like any dev team should pick up a copy of this for on-boarding: https://jvns.ca/blog/2023/06/23/new-zine--how-integers-and-f...

Floating point being grokkable doesn’t make it any more suitable for this application. Floating point is inherently an approximation - your bank balance should not be an approximation.

Indeed. I'm just making a tangential comment. Definitely want to work in unsigned fractional cents.

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

#70

Post by onetimeuse92304 »

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…

I never said you need special database or wire format. Maybe if you are using JSON, transfer monetary values as strings rather than decimal or float data types. Some databases can actually handle money, some don't. Those that do not, usually require you to store money as strings to not lose information. When you get warned by your DBA that the database can't do arithmetic on strings, tell them that "thank you, it could not do correct arithmetic anyway".
Post reply on HN