Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

To represent prices that are traded fractionally.


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?


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.


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.


Hey! Thanks for your curiosity. This was news to us too. And I think we spent about a year thinking about this before we swapped for a bigger piggy! :)


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.


Known to gophers as a "big rat": https://pkg.go.dev/math/big#Rat


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: