4 ms·
Word of advice to anyone considering the "minor-units precision" strategy for representing monetary amounts: Don't (or at least, don't use it as an interchange/
by lxgr 4mo ago
Word of advice to anyone considering the "minor-units precision" strategy for representing monetary amounts: Don't (or at least, don't use it as an interchange/API data format).
It seems like a clever idea (fast integer math, no rounding problems for addition and subtraction), but it'll bite you incredibly hard if you ever stumble upon an edge case such as working with a partner that has a different implied number of digits for a given currency. This is especially relevant for stablecoins, which often have a different number of implied decimal digits than the "fiat" currency they represent.
Also, consider representing amounts as a string type in JSON-based APIs. JSON does not specify decimal precision, so you (and all your users/vendors) will always have to make sure your parser/serializer doesn't internally lose precision by going via floating point. This can get ugly fast, and while a string seems conceptually less neat, it completely bypasses that problem. (Some will call this an anti-pattern [1], but I'd rather not fight this particular battle for ideological purity on the shoulders of my users or shareholders.)
[1] https://blog.json-everything.net/posts/numbers-are-numbers-not-strings/ https://blog.json-everything.net/posts/numbers-are-numbers-n...
- gucci-on-fleek 4mo agoWhat 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!’
- 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]
- denismenace 4mo ago> but it'll bite you incredibly hard if you ever stumble upon an edge case such as working with a partner that has a different implied number of digits for a given currency Why would that be a problem? You just transform the values when interacting with their API.
- lxgr 4mo agoSure, but are all your (and your users' and vendors') engineers and LLM agents going to remember that? When in doubt, always be explicit.
- makeitdouble 4mo agoI'm curious how you handle that. Let's say I operate with a 4 decimal expectation and your API expects 6, is there any way to reconcile that outside of documentation and or metadata ? (which would be the same issue I guess whatever representation is used ?)
- lxgr 4mo agoYeah, you need to document it. Still, even if you do: Chances that your users are just going to assume you're conforming to ISO 4217, some national standard, or your competitor that they're already integrated with are pretty high, so I wouldn't take the chance. Pick something that doesn't have to be documented instead.
- xlii 4mo agoExactly, model is in integers and representation can be 1⃣3⃣ or whatever, that's why model-view separation exist.
- lxgr 4mo agoSure, you can do that if you can absolutely guarantee that everyone will always respect that separation and there will never be ambiguity between your internal and some partner's representation – even during incidents, even during low-level CSV-to-DB ETLs during incidents ("just one time, I promise, we don't have time to build the proper adapter, but look how similar their and our formats are").
- antonymoose 4mo agoHaving done HFT / low-latency in C++ with a browser based (read: JavaScript) management front-end: Go ahead and use integer cents everyone. It’s practically an industry standard and it works just fine. Anything else is a worse compromise.
- DetroitThrow 4mo agoAgree with this, working from HFT to payments to account management in the past. You can have the blockchain team be an expert in converting integer cents, or the forex team be an expert in sub-cent conversions. You don't want to require _every team_ to have expertise in float math, by default.
- lxgr 4mo agoBig decimals are widely available and don’t require any expertise but avoid many of the footguns of implied decimal integers.
- Maxatar 4mo agoImagine advising someone who explicitly said they work in HFT to use big decimals.
- m00x 4mo agoBigDecimal should be used by almost everyone except for HFT since they're really slow.
- DetroitThrow 4mo agoWhen performance isn't a concern, I largely agree! Not every financial system can use big decimal as their base, though, too. And HFT isn't the only place in the financial sector where this performance concern might pop up.
- notpushkin 4mo agoIt is fine as long as you don’t cross any edge cases (crypto, or more recently stuff like AI token pricing) and don’t forget to account for third party quirks (e.g. Stripe’s zero-decimal currencies: https://docs.stripe.com/currencies#zero-decimal https://docs.stripe.com/currencies#zero-decimal).
- noitpmeder 4mo agoThe only real correct solution here is to send mantissa and exponent as two separate integers. It's trivial to convert between exponents for whatever math you want, it can be as correct as you want, and is unambiguous. In the HFT space you save some wire space if you can commit to a consistent exponent for some {slice} up front (think instrument/tick-size/asset-class/exchange/feed/server/whatever/...) such that you only need to send the mantissa and your clients can have a hard coded exponent. However, in similar spaces it's often worth the extra uint32 to send a on-the-wire exponent such that things _can_ change and you aren't hamstrung later by earlier "we only need cents now!" design choices when, e.g., you suddenly need to support bitcoin/... prices to full precision. (your users will thank you when they don't have to coordinate a breaking change when you want to adjust your fixed exponent)
- microgpt 4mo agoIf you do that though aren't you just reinventing floating-point?
- jjmarr 4mo agoNo, because you're doing decimal floating point, which eliminates the rounding errors of binary floating point.
- IshKebab 4mo agoThey're both floating point. https://en.wikipedia.org/wiki/Decimal128_floating-point_format https://en.wikipedia.org/wiki/Decimal128_floating-point_form... What noitpmeder described is just floating point.
- OtherShrezzing 4mo agoNo, standard floating point implementations have higher precision for smaller numbers than larger. So for example, in a 32bit float, there are far more numbers between 0-1 than there are between 1,000,000 and 1,000,001. For 32bit floats, you start lowing whole integers with relatively small numbers. Integers have a consistent precision across the entire number line.
- gib444 4mo agoWhat is with this Twitter esque style of discussion? Post some vague comment with no real stake in the ground, but just reply to follow ups asking for clarifications about the right way. It's exhausting. Why not put all that effort into the initial comment? Vague-posting seems to becoming more popular
- lxgr 4mo agoIf there were a simple one-size-fits-all solution to these problems, there wouldn't be a need for a handbook, nor for a discussion, would there? I can't design everybody's systems here, but I was hoping that sharing some war stories that have cost me days or weeks of work might sensitize somebody to a few non-obvious footguns.
- gib444 4mo agoThat strawman is so large it would even scare away a human
- dahart 4mo agoI think I’m agreeing with you whole-heartedly if I say that article’s conclusion is at best extreme and unrealistic when it says “the parsers need to be fixed. They should support extracting any numeric type we want from JSON numbers and at any precision.” This sounds like an unreasonable position to take. “Any” is an unachievable standard that could require an unlimited engineering budget with no demonstrable value in practice. It is good to identify the lack of a standard, and to talk about what parsers do in practice, and good to discuss the gaps and unmet use-cases. It would be a good idea to suggest that there should be a more reasonable standard, perhaps. It’s just not a good idea to demand that everyone support “any” possibility when no one really needs that, no one knows what it means, and it’s not actually possible to achieve.