3 ms·
What do you recommend instead? Standard floating-point ("float"/"double"), fixed-point arithmetic with thousandths (or smaller) of the minor unit, arbitrary-pre
by gucci-on-fleek 4mo ago
What do you recommend instead? Standard floating-point ("float"/"double"), fixed-point arithmetic with thousandths (or smaller) of the minor unit, arbitrary-precision decimal numbers, or something else entirely?
- lxgr 4mo agoI think what matters most is your database and API representation, as well as having consistent and well-defined rounding rules. I largely agree with TFA: Round explicitly and consistently whenever you cross a boundary, i.e. database persistence and internal API calls. Use whatever works for your required business case internally (i.e. inside of procedures calculating some function of one or more input amounts). This can be regular old floats/doubles if you absolutely know what you're doing, or BigDecimal if you aren't and would rather suffer slightly slower performance than having to talk to an auditor about IEEE 754 rounding modes, or even minor-amount integers (yes, even though I just said to not use them – but you'll want to ABSOLUTELY NEVER leak them outside of your system, including your data/analytics pipeline, which might have different ideas about financial amounts than your business logic implementing a nice custom monetary type).
- ivanmontillam 4mo agoA string type. As parent says: it completely bypasses the problem. Save the numbers between double quotes and be done with it.
- portly 4mo agoStoring numbers as arrays of u8? That doesn't make sense
- ivanmontillam 4mo agoFor 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 4mo agoSurely it does: { "price": { "amount": 1000, "decimal_places": 2, "currency": "USD" } }
- lxgr 4mo agoHow 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 4mo agoIt 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 4mo 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 4mo agoString 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 4mo agoIt makes a lot of sense if you value correctness over performance.
- lxgr 4mo agoExcept 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…
- KellyCriterion 4mo agoDo not throw away any precision in finance/money computation, regardless what/ how you are doing it. In C# e.g., there is type decimal for those computations.
- lxgr 4mo agoYou'll definitely have to throw it away at some point. The art is in making those points well-defined and rare enough to not cause large discrepancies, but frequent enough to avoid ballooning arbitrary-precision numbers across databases and services that might not be able to handle them.
- necrotic_comp 4mo agoFloating point value stored multiplied by 10^8. That gives you a huge integer, but it's extremely accurate, especially for US denominated currencies. Easily transformed into floating point numbers for reporting/etc.
- deleted 4mo ago[deleted]