4 ms·

"Integer number of cents" is a fine way to deal with money unless you want sub-cent units. Otherwise, you can divide it up smaller: a few stock exchanges use [

"Integer number of cents" is a fine way to deal with money unless you want sub-cent units. Otherwise, you can divide it up smaller: a few stock exchanges use [price in dollars] * 10^8 as their price unit, and store a 64 bit int.

t_tsonev 4y ago
Exactly, and BigInt fits this role perfectly.
twelve40 4y ago
> "Integer number of cents" is a fine way to deal with money unless you want sub-cent units I use this approach to minimize the amount of time I have to waste on trivial money operations such as storage and api's, but this approach (number of cents) falls apart quickly the moment you need to do something as simple as calculate tax or a commission. So, still likely no getting around proper float math even if you may not really be all that interested in sub-cent units.
Waterluvian 4y ago
You really want to use a decimal library for any serious financial math. And if you’re doing the math on tiny units of processing you’re going to want the precision and accuracy. You don’t need to work in decimal cents. Many work in thousandths of a cent or smaller. But you want an infinite upper and lower bound. Even 64 bit integers only has so much upper range depending on how far you subdivide a penny. You also want the precision guarantees when you take those numbers and do more than just add or subtract them.
- pclmulqdq 4y ago
  Why do you need an infinite upper bound for money? I agree that you need to do saturating arithmetic, but 2^64/10^8 dollars is about 10^10 dollars, which is the around the GDP of the US. A number that big is not going to show up in your billing system if you do everything correctly. With all numerical calculations, you need to be careful about losing precision on mathematical operations, so it's a good idea to think about things like this even if you use a decimal number system with a very wide dynamic range - it won't be very precise all the time.

t_tsonev 4y ago

Exactly, and BigInt fits this role perfectly.

twelve40 4y ago

> "Integer number of cents" is a fine way to deal with money unless you want sub-cent units I use this approach to minimize the amount of time I have to waste on trivial money operations such as storage and api's, but this approach (number of cents) falls apart quickly the moment you need to do something as simple as calculate tax or a commission. So, still likely no getting around proper float math even if you may not really be all that interested in sub-cent units.

Waterluvian 4y ago

You really want to use a decimal library for any serious financial math. And if you’re doing the math on tiny units of processing you’re going to want the precision and accuracy. You don’t need to work in decimal cents. Many work in thousandths of a cent or smaller. But you want an infinite upper and lower bound. Even 64 bit integers only has so much upper range depending on how far you subdivide a penny. You also want the precision guarantees when you take those numbers and do more than just add or subtract them.

pclmulqdq 4y ago
Why do you need an infinite upper bound for money? I agree that you need to do saturating arithmetic, but 2^64/10^8 dollars is about 10^10 dollars, which is the around the GDP of the US. A number that big is not going to show up in your billing system if you do everything correctly. With all numerical calculations, you need to be careful about losing precision on mathematical operations, so it's a good idea to think about things like this even if you use a decimal number system with a very wide dynamic range - it won't be very precise all the time.