[walnutclosefarm]

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 transaction entries larger than the US annual GDP to roll over into the high order 64 bits.

TigerBeetle may have made the right choice for some market, but I predict that there are vanishingly few sales calls where this becomes an important selling point, unless it's potential customers wondering why they are wasting all those bits and checks for a whole lot of freakin' zeros.

[returningfory2]

There's one small part of the article that IMO is sort of key to understanding the why:

> [for every account] we keep two separate strictly positive integer amounts: one for debits and another for credits

It is not sufficient that their integer type is able to handle individual transactions. Their integer type must be able to handle the sum of the absolute value of all transactions that have occurred on an account. And I think it's easy to come up with realistic situations where you hit that.

So say you take the NYSE, which trades about ~$18 billion per day [0]. This is ~$1.8 trillion cents, or about 2^51 microcents. After 2^12 business days (~=16 years) you'll already be hitting the limit. (This is just a toy example ofc.)

[0] https://www.nyse.com/trading-data#:~:text=The%20New%20York%2....

[jorangreef]

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 scaling, is when n is large. When n is large, you aren't left with sufficient room in the remaining bytes to represent the whole-number part. In trading systems, for instance, you can easily hit 10 ^ 10 to represent fractional traded prices.

Concretely, if you need to scale by 10 ^ 10, then your whole-number part is 2 ^ 64 / 10 ^ 10 = 1,844,674,407, which isn't terribly large.

[walnutclosefarm]

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.

[hot_gril]

Why do exchanges use such high precision for fractions?