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

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

#331

Post by vidarh » Tue, Sep 19, 2023, 9:01 PM UTC

ta1243 wrote: post #303

vidarh wrote: post #212

Earlier quoted context omitted.

UK. The rules may have changed now, it's a long time since I implemented the rounding rules here, but the last time I did it required 5 decimals accuracy. The rules also used to specify how you needed to account for line items vs. sub-totals in your invoices to ensure you didn't find any "workarounds" to shave off some pennies of tax (In fact, the last time was while the tax authority was still called the Inland Reve…

> For aggregate totals of your VAT liability across your total set of invoices, you'd be fine with rounding up to the nearest pound, to the Inland Revenue's benefit On personal tax forms you have to round in the taxpayer favour. If your income is 12345.67 you round it to 12345. If your expense (say giftaid) is 12345.67 you round it to 12346. Surprised it's the other way with VAT, but then I do very little with tax ot…

I'm not sure it's the other way with VAT, as I said it's been many years and the rules may well have changed multiple times.

The key, though, is that with taxes, if at all unsure you've got the rules right, the safest option is to round in the tax offices favour.

It's in general a lot less painful to explain an overpayment than underpayment if something is broken.

Of course, better yet, get it right.

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

#332

Post by vidarh » Tue, Sep 19, 2023, 9:02 PM UTC

ignite wrote: post #296

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…

> A shocking number of people ... are unaware of how many decimal points of accuracy their local tax code requires to calculate A shocking number of people who create tax codes have no idea how many decimal places they are using. It's probably better now, but I recall having to reverse engineer the tax tables to figure out how many decimal points of accuracy were used, and what rounding rules were used, so we could m…

I always hated tables. At least when I last had to implement UK VAT rules the rules were very precisely defined. But I've had to deal with stupid tables implementing rules they couldn't be bothered to spell out before. Yikes.

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

#333

Post by hot_gril » Tue, Sep 19, 2023, 9:50 PM UTC

blibble wrote: post #323

hot_gril wrote: post #274

> For the same reason, digital currencies are another use case for 128-bit balances, where again, the smallest quantity of money can be represented on the order of micro-cents (10-6)… or even smaller. To give a concrete example, Ethereum has a lot of precision (1 ether = 10^18 wei), and there are like 120M ether, so that's more than 64 bits just to represent the supply. Idk though, is this a real concern with traditi…

> Idk though, is this a real concern with traditional finance CME have contracts with 1/128ths of a dollar they also have a tenancy to add another power of 1/2th every 10 years or so this causes problem for fixed point, but amusingly this works perfectly well with floating point

One annoyance with floating point binary is when it happens to not line up so well with floating point decimal, for example

  >>> 0.1 + 0.2
  0.30000000000000004

which is still gonna round to 0.3, but ugh. Also, during aggregations, it's not nice how you get different answers depending on the order of operations when they shouldn't matter.

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

#334

Post by Sohcahtoa82 » Tue, Sep 19, 2023, 9:53 PM UTC

kardianos wrote: post #105

RetroTechie wrote: post #83

Earlier quoted context omitted.

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…

I honestly don't understand the argument here or the parent comment makes. Why is a BCD decimal 128 worse at math then a fixed point integer? You are saying it is more CPU efficient? Are you saying some operations with fixed point integer math operations are more accurate then dec128? I've seen this asserted several times, both in the post and in comments, but I've never seen a single concrete example of it being bet…

Do you know what BCD is? If you did, it becomes pretty obvious why BCD is significantly slower than fixed point integers.

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

#335

Post by Sohcahtoa82 » Tue, Sep 19, 2023, 9:56 PM UTC

kemotep wrote: post #244

kybernetikos wrote: post #63

Earlier quoted context omitted.

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.

Yup, and as a result, nobody wants to actually treat it as the digital currency that it was originally set out to be.

Anybody who truly thinks Bitcoin could hit $100K value certainly doesn't want to spend them.

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

#336

Post by walnutclosefarm » Tue, Sep 19, 2023, 10:29 PM UTC

jorangreef wrote: post #280

walnutclosefarm wrote: post #258

I'd like a report back from TigerBeetle on how many applications they actually support where the high order 64 bits are nonzero. I would note that the entire US GDP is less than 10^15 cents, and that 2^64 accommodates just shy of 10^19 in signed integers. So, even if your database had a justification for thousands of a cent transactions (not intermediate results, but recordable transactions), you'd still need to have…

To be fair, I used to think like this too, but chatting with multiple large exchanges/brokerages made us realize this was a thing. > less than 10^15 cents There are systems that don't work in terms of cents (cf. the examples of issues in many of the comments here), or even in thousandths of a cent, but with significantly more precision. Literally, in other words: Where you run into problems then, with 10 ^ n integer…

I'm not sure I understand what you're saying. Are you saying that these exchanges are trading at prices to a precision of 10 ^ -10 dollars (or other currency)? I saw private exchanges pricing to hundredths of a cent (a long time ago - it's been a decade and half since I worked on Wall Street or in the City) or yen, but never any finer than that. Even then, all transactions were recorded in whole cents.

I'm sure you've done your homework, and I'm long out of the finance business, but even so, I think the applications where this matters are, as financial applications go, very unusual.

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

#337

Post by lxgr » Tue, Sep 19, 2023, 10:35 PM UTC

munificent wrote: post #325

lxgr wrote: post #219

Earlier quoted context omitted.

Floating point calculations without some final rounding step before presentation/export/storage are almost always wrong, since you're implying much more precision than is justified by your source data.

Ths problem isn't rounding the final result. The problem is that the source data itself can't be accurately represented. There is no floating point value equal to 0.3.

That’s not a problem by itself.

You can represent 0.3 as 0.300000…0004, which rounds to 0.3 again in the end.

But you need to reason about the number and nature of intermediate operations, which is tricky, since errors usually accumulate and don’t always cancel out.

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

#338

Post by blibble » Tue, Sep 19, 2023, 10:44 PM UTC

hot_gril wrote: post #333

blibble wrote: post #323

Earlier quoted context omitted.

> Idk though, is this a real concern with traditional finance CME have contracts with 1/128ths of a dollar they also have a tenancy to add another power of 1/2th every 10 years or so this causes problem for fixed point, but amusingly this works perfectly well with floating point

One annoyance with floating point binary is when it happens to not line up so well with floating point decimal, for example >>> 0.1 + 0.2 0.30000000000000004 which is still gonna round to 0.3, but ugh. Also, during aggregations, it's not nice how you get different answers depending on the order of operations when they shouldn't matter.

on CME they're not decimal though, they're binary fractions

so floating point works fine as floating point is binary fractions

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

#339

Post by fancyfredbot » Tue, Sep 19, 2023, 10:48 PM UTC

DamonHD wrote: post #13

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?

Not true for any of the finanical systems I've worked for the credit/derivatives/FI/etc desks of some of the largest investment banks down to the systems for the virtual card e-money issuer in the UK that I founded.

Derivatives are generally subject to some fairly large uncertainty in valuation, for example bid/offer spreads are usually many orders of magnitude larger than floating point error. When the derivative expires it does have some very fixed value but the investment bank will have made enough money off the trade to "generously" round up the float to the nearest cent.

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

#340

Post by cryptonector » Tue, Sep 19, 2023, 11:31 PM UTC

> While some may argue that a 64-bit integer, which can store integers ranging from zero to 264, is enough to count the grains of sand on Earth, we realized we need to go beyond this limit if we want to be able to store all kinds of transactions adequately.

64-bit integers are barely enough anyways. If the world-wide patrimony is somewhere near $100tn or $200tn, that's around a bit more than 10^16 (so let's round the exponent up to 17) cents, and that's just two digits short of the maximum that can be expressed with 64-bit signed integers!

If you want to sum things like inter-bank debt, or if we have a lot of growth or hyperinflation we might need to express between 1¢ and $1e18 or $1e19, but the max range with signed 64-bit integers is [-$9.2 x 10^18, $9.2 x 10^18] if we still need to represent cents. So 64 bits is starting to be a tad too small for financial purposes.

Even unsigned 64-bit integers are not that comfortable, but signed integers are needed if you're dealing with assets and liabilities.

128-bit is definitely too big, but it's a lot easier to deal with than variable-length integers. One might still use variable length encodings to save space on the wire or on disk, but in-memory 128-bit integers is the way to go.