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

261–270 of 372 posts

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

#261

Post by ben_w »

feoren wrote: post #229
ben_w wrote: post #90

Earlier quoted context omitted.

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.

> 800 years away, which is far enough that we might legitimately not have a moon any more Wait, what? 800 years is absolute peanuts for the fate of orbital bodies. Wikipedia's Timeline of the Far Future estimates the demise of the moon in 7.59 billion years; still in orbit around the Earth (albeit a much higher one), it gets destabilized by the expanding sun and eventually swallowed by it, along with the Earth. If th…

https://en.wikipedia.org/wiki/Self-replicating_spacecraft

Even the unit of replication is a factory under human control with no novel AI, and which can only replicate with significant human oversight of already existing mining, processing, and manufacturing equipment, it doesn't take insane reproduction rates to disassemble the moon in 800 years.

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

#262

Post by ilyt »

jefftk wrote: post #127
runeks wrote: post #77

Earlier quoted context omitted.

I think it's the worst example. I very much doubt we will ever see the price of, say, a car approach a billion billion dollars (or cents). It's too many zeros for people to work with on a daily basis. I think what will happen is that, at regular intervals, the old hyper-inflated currency will be replaced with a new currency that's, say, 2^32 times less than the original one. Besides, if you think a billion billions m…

Before 2009 would you have predicted that a 100 Trillion Dollar bill would never be issued by a central bank?

2^63 / 100 Trillion = 9.2E6 so even in this case you have few decimal positions left.

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

#263

Post by manicennui »

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.

It's viable because customers generally have no recourse and companies don't care as long as the problem is in their favor.

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

#264

Post by throwaway894345 »

onetimeuse92304 wrote: post #70
throwaway894345 wrote: post #52

Earlier quoted context omitted.

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

You said something to the effect of “it’s not enough to have financial libraries, you also need storage (e.g., db) and transfer (e.g., wire formats)” which suggests that you can’t just use a standard library to dump JSON to a file or through an HTTP connection.

But yes, I can see how databases not having a money type with corresponding routines is going to make life harder.

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

#265

Post by manicennui »

iamds wrote: post #9
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

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

Because it is very common to need to deal with fractions of a cent in intermediate calculations.

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

#266

Post by bsder »

The only good thing that Bitcoin ever did was create a real world use case that breaks shitty software handling financial numbers.

Either the programmers have to do the right thing or tell their boss that they can never support Bitcoin.

Both options give me a warm, fuzzy feeling inside when I watch them in real time.

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

#267

Post by zarzavat »

ilyt wrote: post #262
jefftk wrote: post #127

Earlier quoted context omitted.

Before 2009 would you have predicted that a 100 Trillion Dollar bill would never be issued by a central bank?

2^63 / 100 Trillion = 9.2E6 so even in this case you have few decimal positions left.

You may be overlooking the potential for someone to own more than one of those $100T bills. Apparently it was worth about 30 USD at the time.

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

#268

Post by bob1029 »

crazygringo wrote: post #235
weinzierl wrote: post #230

I once argued for using BigDecimal instead of Doubles in an invoicing software but had a hard time to come up with a practically relevant example. Is there an example where it makes a noticeable difference (at least one cent in the final result) that does not involve unrealistic amounts or numbers of items? I'm not arguing for Doubles, just collecting arguments to convince.

I'm curious about this too. If you were engaged in millions of arithmetic operations then I can see how inaccuracies might accumulate in theory, but in practice floating point operations are intentionally designed to minimize that. And for everyday individual transactions it's hard to see a problem. Maybe the problem is more when you're summing up every single financial transaction for the year? But even in that case…

The part of using float for this that concerns me is not epsilon. It is all of the other weird edge cases & states. I don't like that 2 flavors of infinity and something that isn't a number are explicitly representable.

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

#269

Post by tim333 »

amalcon wrote: post #170
pjc50 wrote: post #155

Earlier quoted context omitted.

I did join somewhere that could do it correctly, because they had some very long-running POS software. It could even do things like "split bill three ways" correctly allocating both the spare penny from the division and the tax calculation, such that you could add the bills back together again and get the same numbers as the split bill. Using a "money" class that stores things as integer pennies gets you a long way t…

Integer cents is fantastic for POS software and similar things that deal with at most a few thousand dollars at a time. The place where it starts to fail is when the absolute numbers get really large, not really small. Think "United States Federal Reserve" or "UBS". Then remember that some of these institutions need to deal with accounts denominated in Zimbabwean dollars.

Python can deal with 1000+ digit integers and you can store them as strings in the database. Not sure about other languages.

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

#270

Post by feoren »

ben_w wrote: post #261
feoren wrote: post #229

Earlier quoted context omitted.

> 800 years away, which is far enough that we might legitimately not have a moon any more Wait, what? 800 years is absolute peanuts for the fate of orbital bodies. Wikipedia's Timeline of the Far Future estimates the demise of the moon in 7.59 billion years; still in orbit around the Earth (albeit a much higher one), it gets destabilized by the expanding sun and eventually swallowed by it, along with the Earth. If th…

https://en.wikipedia.org/wiki/Self-replicating_spacecraft Even the unit of replication is a factory under human control with no novel AI, and which can only replicate with significant human oversight of already existing mining, processing, and manufacturing equipment, it doesn't take insane reproduction rates to disassemble the moon in 800 years.

That's like saying "5 years away is far enough that Mount Rushmore might be gone by then!" because we could nuke it if we wanted to. Why would we do that!? We like the moon being there! Do these examples really help illustrate how far away 800 years, or 5 years, are?
Post reply on HN