[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.

[jorangreef]

Yes, exactly. And we were surprised by this too. But it can be typical for prices that are fractionally traded. See https://news.ycombinator.com/item?id=37574440

[hot_gril]

Why do exchanges use such high precision for fractions?

[jorangreef]

To represent prices that are traded fractionally.

[hot_gril]

But nothing can do that exactly, for example 1/3 has an infinitely long decimal or binary representation. So why round to 10^-10 as opposed to something like 10^-3?

[jorangreef]

For sure. We didn't pick 10^10 scaling. It's just what some massive brokerages/exchanges actually use. The fact that these were not necessarily crypto made us take note.

At the same time, you can understand that 10^10 scaling is at least significantly more precise. And I can imagine these things are viral too, who you trade with, also determines your minimum resolution. You can always downsample in presentation, but once downsampled in storage, it's impossible to upsample.

It also wasn't the only use case. But it tipped the scales.

[hot_gril]

Yeah, was just curious if the brokerages explained their reasoning in detail. Even if it's just viral, someone big had to have a reason to start the trend.

[filoeleven]

Some languages do have proper support for ratios, so if you define x = 22/14, the value stored is 11/7. Multiply later by 7 and you get 11.

You can maintain exact calculations through an entire data pipeline this way, as long as your base numbers are all integers and ratios, and optionally have one rounding step at the end if you want a decimal value. Most math languages and lisps do this.

There must be libraries for other languages that can do it too, but it’s much nicer to work with when it’s built-in.

[hot_gril]

Yeah, I thought about that. Wonder how efficiently a database can be tweaked to support this, cause that might matter even more than language support.