5 ms·

A string type. As parent says: it completely bypasses the problem. Save the numbers between double quotes and be done with it.

• portly 3mo ago
  Storing numbers as arrays of u8? That doesn't make sense
  • ivanmontillam 3mo ago
    For JSON serialization, which doesn't support fixed-point precision it does. Floating-point precision has too many gotchas for being suitable to store Decimal types, especially for the Currency use case.
    • notpushkin 3mo ago
      Surely it does: { "price": { "amount": 1000, "decimal_places": 2, "currency": "USD" } }
      • lxgr 3mo ago
        How is that better than {“amount”: “10.00”} (which also bypasses all potential floating point parsing issues that your or your counterparty’s JSON library might have)?
        • jameshart 3mo ago
          It is explicit about the fact that that number of decimal places is part of the data. The semantics for your string “10.00” are complex - is it considered equal to “10”? To “10.000”? To “10.001”? A user interacting with an API that uses such a string might make all sorts of assumptions about what it supports. A user interacting with an API that has an explicit decimal places concept is being told ‘decimals matter! They can vary! Here be dragons!’
          • lxgr 3mo ago
            > The semantics for your string “10.00” are complex - is it considered equal to “10”? Yes, but "10 USD" would be a non-canonical representation and you probably serialized incorrectly. > To “10.000”? Yes, but same caveat as above applies. > To “10.001”? Obviously not, and any system you'd ever want to use in a financial context will tell you so.
            • notpushkin 3mo ago
              String and two-field exponent/mantissa representations are mostly the same in terms of semantics, yes. Making it two separate fields makes it less likely it would be put into `parseFloat`, but after doing some research I think strings are more popular in JSON [1, 2], so probably I’d stick to that as well. [1]: https://msgspec.dev/supported-types#decimal https://msgspec.dev/supported-types#decimal [2]: e.g. https://getlago.com/docs/api-reference/fees/fee-object#schema-precise-total-amount https://getlago.com/docs/api-reference/fees/fee-object#schem..., although they still use `amount_cents` for all currencies as the base rate
  • lxgr 3mo ago
    It makes a lot of sense if you value correctness over performance.
    • microgpt 3mo ago
      Why not store them in unary then?
      • lxgr 3mo ago
        Unary is exactly as expressive as decimal or binary for integers, but somewhat less efficient, so why would you?
        • microgpt 3mo ago
          idk, why would you store integers as ASCII strings? It's somewhat less efficient.
          • lxgr 3mo ago
            Because it's much more explicit. Computers are fast, engineering is expensive. You usually never want to optimize prematurely when dealing with monetary amounts.
            • microgpt 3mo ago
              Even more explicit would be a PNG of the dollar bills. I suggest that.
• lxgr 3mo ago
  Except that now you have a new problem: Opinionated theorists that haven’t been part of a nasty “oh no, we accidentally considered some amounts as 10x/100x/1000x larger/smaller than expected” incident in their career yet…