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

81–90 of 372 posts

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

#81

Post by GTP »

8organicbits wrote: post #18
iamds wrote: post #9

Earlier quoted context omitted.

why add the complexity of bcd when you can just put in it units (e.g. cents) where there's no decimal point?

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?

I think you could easily convert every stored value to the new unit of measure by multiplying by an appropriate factor. In your example that would mean multiplying all the old values by 10. But when you're designing such software, you could also be conservative and use a smaller unit than cents (which probably many financial sw already do, as you already have things considering fractions of cents like gasoline prices).

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

#82

Post by bux93 »

onetimeuse92304 wrote: post #60
rvnx wrote: post #53

Earlier quoted context omitted.

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

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.

Any rounding discrepancies simply get posted to a rounding-error account. For example, oracle's ledger will complain if there is rounding and no rounding-error account to post to. https://support.oracle.com/knowledge/Oracle%20Cloud/2411363_...

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

#83

Post by RetroTechie »

dahfizz wrote: post #15
throw0101c wrote: post #5

I was under the impression that BCD was generally recommended for money, often because of (IEEE?) rounding and machine precision/epsilon: * https://en.wikipedia.org/wiki/Binary-coded_decimal * https://en.wikipedia.org/wiki/Machine_epsilon

BCD is better than IEEE 754 floating point, but simple integers with an implied decimal point is much better than either of those.

BCD makes stored value -> human-readable trivial, at the cost of complicating math on those values.

So it's useful for applications where you're mostly doing human input/output stored value.

But as soon as you do any non-trivial math on those values, using (fixed point?) integers wins. At the cost of a simple stored value human readable conversion.

I'd think most financial applications fall into the category "do math, so integers win over BCD".

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

#84

Post by out_of_protocol »

dahfizz wrote: post #25
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?

These systems use something like 10^-8 as the implied decimal in the real world. Some forex exchanges even go to 10^-9

Fiat currency can go to -4 i think, crypto currency going to -18. And that's whole units like cents P.S. crypto things are using uint256 internally, and this type don't exist in most languages. Using int64 can work out, sometimes, and will usually break soon enough

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

#85

Post by [deleted] »

Spivak wrote: post #61
fidotron wrote: post #26

Earlier quoted context omitted.

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

[deleted]

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

#86

Post by tylergetsay »

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…

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

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

#87

Post by formerly_proven »

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). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still.

Your setup made it sound like something crazy and inane, like "the PDF printer used on those machines changed floating point rounding modes" or what have you.

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

#88

Post by dahfizz »

Spivak wrote: post #61
fidotron wrote: post #26

Earlier quoted context omitted.

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

In programming, an `int` perfectly represents the integers between INT_MIN and INT_MAX.

A `float` on the other hand, approximates the real numbers. It can perfectly represent exactly 0% of them.

Having control over the rounding behavior is meaningless - floats cannot correctly represent any non-contrived calculation. Exact representation is important in financial systems.

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

#89

Post by eesmith »

DamonHD wrote: post #31
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?

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 “hundredths,”.

About the only time you see values given in mills is with gas prices, like $4.999/gal, though often denoted as tenths of a cent. It's also indirectly used in property taxes.

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

#90

Post by ben_w »

jon-wood wrote: post #66
mbg721 wrote: post #46

Earlier quoted context omitted.

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.

If inflation averages 5% per year, a factor of 10^17 (what are the biggest USD notes actually in use?) is just over 800 years away, which is far enough that we might legitimately not have a moon any more let alone dollars.

If hyperinflation brings that date closer, the dollar will probably also stop being a global reserve. Or possibly: will be caused by it ceasing to be a global reserve.

Post reply on HN