3 ms·

micro-dollars are a better way of representing it (multiply by 10e6); store as bigint. See: https://stackoverflow.com/a/51238749 https://stackoverflow.com/a/51

by shishy 5y ago

micro-dollars are a better way of representing it (multiply by 10e6); store as bigint. See: https://stackoverflow.com/a/51238749 https://stackoverflow.com/a/51238749

IncRnd 5y ago
No, they aren't. Micro-dollars do not exist, so this method is guaranteed to cause errors.
- mdellavo 5y ago
  this is a common approach when you are dealing in rates less than .01 -- you just need to be sure you are rounding correctly
  - IncRnd 5y ago
    When you are approximating fixed-point using floating-point there is a lot more you need to do correctly other than roun ding. Your representation must have enough precision and range for the beginning inputs, intermediate results, and final results. You must be able to represent all expected numbers. And on. There is a lot more involved than what you mentioned. Of course, if you are willing to get incorrect results, such as in play money, this may be okay.
    - 10000truths 5y ago
      When did mdellavo anything about floating point? You can, and should, use plain old fixed-point arithmetic for currency. That’s what he means by “microdollar”.
    - cjaybo 5y ago
      > store as bigint
      - IncRnd 5y ago
        Thank you. I made a mistake due to the starting comment in the thread.
kyrra 5y ago
Googler, opinions are my own. Over in payments, we use micros regularly, as documented here: https://developers.google.com/standard-payments/reference/glossary#micros https://developers.google.com/standard-payments/reference/gl... GCP on there other hand has standardized on unit + nano. They use this for money and time. So unit would 1 second or 1 dollar, then the nano field allows more precision. You can see an example here with the unitPrice field: https://cloud.google.com/billing/v1/how-tos/catalog-api#getting_the_list_of_skus_for_a_service https://cloud.google.com/billing/v1/how-tos/catalog-api#gett...

3 ms·

micro-dollars are a better way of representing it (multiply by 10e6); store as bigint. See: https://stackoverflow.com/a/51238749 https://stackoverflow.com/a/51

by shishy 5y ago

micro-dollars are a better way of representing it (multiply by 10e6); store as bigint. See: https://stackoverflow.com/a/51238749 https://stackoverflow.com/a/51238749

IncRnd 5y ago
No, they aren't. Micro-dollars do not exist, so this method is guaranteed to cause errors.
- mdellavo 5y ago
  this is a common approach when you are dealing in rates less than .01 -- you just need to be sure you are rounding correctly
  - IncRnd 5y ago
    When you are approximating fixed-point using floating-point there is a lot more you need to do correctly other than roun ding. Your representation must have enough precision and range for the beginning inputs, intermediate results, and final results. You must be able to represent all expected numbers. And on. There is a lot more involved than what you mentioned. Of course, if you are willing to get incorrect results, such as in play money, this may be okay.
    - 10000truths 5y ago
      When did mdellavo anything about floating point? You can, and should, use plain old fixed-point arithmetic for currency. That’s what he means by “microdollar”.
    - cjaybo 5y ago
      > store as bigint
      - IncRnd 5y ago
        Thank you. I made a mistake due to the starting comment in the thread.
kyrra 5y ago
Googler, opinions are my own. Over in payments, we use micros regularly, as documented here: https://developers.google.com/standard-payments/reference/glossary#micros https://developers.google.com/standard-payments/reference/gl... GCP on there other hand has standardized on unit + nano. They use this for money and time. So unit would 1 second or 1 dollar, then the nano field allows more precision. You can see an example here with the unitPrice field: https://cloud.google.com/billing/v1/how-tos/catalog-api#getting_the_list_of_skus_for_a_service https://cloud.google.com/billing/v1/how-tos/catalog-api#gett...