For JSON serialization, which doesn't support fixed-point precision it does.
replyFloating-point precision has too many gotchas for being suitable to store Decimal types, especially for the Currency use case.
Surely it does:
reply {
"price": {
"amount": 1000,
"decimal_places": 2,
"currency": "USD"
}
}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)?
replyIt is explicit about the fact that that number of decimal places is part of the data.
replyThe 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!’
> The semantics for your string “10.00” are complex - is it considered equal to “10”?
replyYes, 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.
It makes a lot of sense if you value correctness over performance.
replyWhy not store them in unary then?
replyUnary is exactly as expressive as decimal or binary for integers, but somewhat less efficient, so why would you?
replyidk, why would you store integers as ASCII strings? It's somewhat less efficient.
replyBecause it's much more explicit. Computers are fast, engineering is expensive. You usually never want to optimize prematurely when dealing with monetary amounts.
reply