4 ms·
> thank you Rust decimals represented as JSON floats What do you mean? JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not
by lxgr 4mo ago
> thank you Rust decimals represented as JSON floats
What do you mean? JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec.
> If I ever see a monetary value stored in something else than integers I'm going to run away screaming
That’s good, then we’ll likely not be working on the same system :) I consider running from “amounts as integer” systems these days (but usually unfortunately can’t). In an idealized codebase that only seasoned financial programmers are allowed to touch, it can go well, but such a system is usually either overly exclusive or risks becoming brittle.
- lawlorino 4mo ago> I consider running from “amounts as integer” systems these days (but usually unfortunately can’t). In the context of Fintech, how do you otherwise resolve floating point rounding issues if not representing amounts with integers?
- lxgr 4mo agoNative decimal types, if your system has them. Many languages and databases used in financial contexts do.
- Maxatar 4mo agoBut native decimal libraries are almost always floating point. Do people not know what a floating point number is?
- lxgr 4mo agoThat’s alright, the important part here is that they’re decimal, not binary. You don’t want 0.1 + 0.2 to equal 0.300…004.
- Maxatar 4mo agoThere are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4 and it saddens me when this topic comes up and people go to such extreme lengths to recreate a second hand buggy reimplementation of a subset of floating point numbers to do it.
- worik 4mo ago> There are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4 Not across all architectures and operating systems there are not Listen to those who have done this. Use integers for finance.
- Maxatar 4mo agoYes across all architectures and OS's that use IEEE 754 floating points.
- FabHK 4mo agoWhat are those pretty trivial ways? And how are they better than storing 10 cents + 20 cents = 30 cents?
- Maxatar 4mo agoBy not thinking in terms of strict rules and dogmas and instead focusing on the actual problem you want to solve. If you want to guarantee that adding cents together results in an exact value without any loss of precision, and you also want a tiny memory footprint and very high performance, then use a binary floating point to represent cents, just as you would use an int. Also the question of how it's better depends on your use case and my argument is not that one representation is universally better than another, it's that money is used for such a diverse range of use cases that you need to actually understand what you're doing, what the goal is, what the potential issues are etc... in order to pick the right representation for your use case. At my trading firm we have three different Money classes optimized for three different use-cases (with functions to allow interoperability between them). For the use case where the representation needs to use little memory, is fast, and needs to be used to perform complex financial calculations at an enormous scale, then you use binary floating point where a value of 1.0d = 0.000001 dollars. This gives you exact precision when working with cents, and lets you perform all of the usual financial computations that most quantitative applications need to perform with excellent performance. We also have a use case optimized for I/O, where no calculations are expected to be performed but the data will be transmitted over a network or to/from a database etc... If this isn't your domain, maybe you're just writing a GUI application/web app, then by all means use a big decimal or use an integer... I don't know, but it's very sad seeing how many people who are presumably professionals don't take just the bare minimum amount of time to think things through and instead just reason in terms of strict dogmas.
- ktimespi 4mo agoAren't decimal types BCD coded?
- simpsond 4mo agoAn integer for the value (scaled by number of decimals) and an integer value for the number of decimals. Different systems may use different values, even for the same currency or asset.
- Maxatar 4mo agoWhat exactly do you think a floating point number is?
- lxgr 4mo agoUsually that, but in binary, which causes lots of headaches for financial math.
- Maxatar 4mo agoFor those who don't understand what they're doing, yes. But those people end up having headaches and causing trouble no matter what.
- CyberDildonics 4mo agoSo all the people who write financial software and avoid floats don't know what they're doing? That's would end up being just about everyone. You should teach them, you know so much more than they do.
- dgunay 4mo agoAll of the data we control (in the database, in our apis, etc) is integer cents. When we have to interface with a system that represents money using JSON numbers as dollars.cents, we parse or serialize it into an arbitrary precision decimal type. Hasn't been much of a problem.
- morpheuskafka 4mo agoI'm sure there is something I don't know here, but how is working with integers "brittle"? The only issue I see is rounding down by default, not sure if that is even an issue or not. At any rate, it seems a lot less brittle than floats or bigdecimal style number classes.
- lxgr 4mo agoThe brittleness comes from the fact that the number of implied decimal digits per currency isn't always well-defined across all stakeholders and systems. If you're only working in a single currency, there's usually no issue.
- foresterre 4mo agoAs a general rule, you always include the currency code (EUR, SEK, USD etc.) and if possible also the amount of decimals, when using minor units. Currency codes can be found in ISO 4217.
- lxgr 4mo agoYes, definitely always include the number of digits, but at your system boundary you still have to pray that whoever you're working with isn't silently dropping that number and re-deriving it from their own, almost-4217-compliant currency database. Redundancy can be great, but it's not a panacea, since it's not guaranteed to be used in an optimal way.
- zdragnar 4mo ago> JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec. I think that's the problem they were trying to describe. Without a formal spec, systems won't agree on how to handle floats. JS engines treat numbers as 53 bit signed floats, so passing a well defined decimal there through JSON means losing precision at the edges. Money stored in integers gets around the issue by simple virtue of not really needing more than 53 bits to accurately represent the values anyone is going to encounter. There are downsides like all the extra math or functions to handle doing the math everywhere money is manipulated or displayed, but this is the sort of thing where static typing is really helpful, and isn't too hard for juniors to understand that they should always use money functions to work with money data.
- dotancohen 4mo agoWith I need to represent monetary amounts through JSON, I encode it as a base 10 string and wrap it in quotes so that the JavaScript engines treat it as a string. Conversion back to int happens after the string has been parsed and validated. I do this with HTTP GET and POST form requests as well. In HTTP, everything is a string (even if that string is JSON).
- worik 4mo ago> JS engines treat numbers as 53 bit signed floats Please do not use Javascript for finance applications. Just do not do it Save it for user interface elements and dancing whizzimagigs, where it will do less harm.
- zdragnar 4mo agoExcel does the same thing, and has been used to track money for decades. Somehow, we're all still alive.
- lxgr 4mo agoFinancial applications need user interface elements too, and doing these poorly has caused quite some [1] harm in the past... [1] https://financialregulation.linklaters.com/post/102j8af/the-citi-fat-finger-fines-and-ui-design https://financialregulation.linklaters.com/post/102j8af/the-...