Earlier quoted context omitted.
An 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.
What exactly do you think a floating point number is?
Fintech Engineering Handbook
151–160 of 234 posts
Re: Fintech Engineering Handbook
#152As a programmer, what I feel when I see fintech programmers each speaking from their own different experiences and perspectives is that it makes me wonder what it really means to be good at programming. What user xlii said about not storing monetary amounts as floats is a common IEEE 754 issue. And while it's true that financial tracking should be done through immutable logs or event-based records, I don't think ever…
Re: Fintech Engineering Handbook
#153I have just left a fintech company after 5 years and I can say after reading this, it looks legit to me (not AI slop as someone asked). These are the same sort of lessons I learned during my time in the industry. I would recommend anyone starting in fintech to take some time to understand accounting principles and the ledger in a bit more depth than just debits vs credits - this is likely what is most unfamiliar to p…
Probably good advice (for everyone in fintech, not just programmers) considering the absolute disaster that happened at Synapse. Kind of wild nobody has gone to jail for that.
Re: Fintech Engineering Handbook
#154Earlier quoted context omitted.
> E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY good reason to do otherwise (though exported view can be in anything, even in weird bitcoded formats). That really overstates the issue. Whole domains of finance run just fine on doubles. If you're doing Monte Car…
I love how this sensible take is followed by a tornado of comments that boils down to "NEVER use floats JUST BECAUSE".
"Floats" are simulations of Real Numbers, and Reals are uncountable. Not what you want for finance, where everything is counted.
Re: Fintech Engineering Handbook
#155Earlier quoted context omitted.
> 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 u…
> 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…
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.
Re: Fintech Engineering Handbook
#156Earlier quoted context omitted.
Native decimal types, if your system has them. Many languages and databases used in financial contexts do.
But native decimal libraries are almost always floating point. Do people not know what a floating point number is?
Re: Fintech Engineering Handbook
#157Earlier quoted context omitted.
That’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.
There 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.
Not across all architectures and operating systems there are not
Listen to those who have done this. Use integers for finance.
Re: Fintech Engineering Handbook
#158Earlier quoted context omitted.
> You store the sums on either end, the currencies, the exchange rate and the final sum? There is a remarkable amount of disagreement as to whether one should do one’s back office work based on the price or based on the quantity of the counter currency. > No one has .0000145 cents in their account. Rounding occurs in the real world. Indeed. But you either need to convince all parties to agree to round the same way or…
My experience in consumer banking says that every instrument specifies the precision of the calculation, how and when rounding happens, and slew of little details. So, yes, everyone has to understand how all their partners are doing rounding and summing.
I would, however, by quite surprised if my personal bank account did this.
Re: Fintech Engineering Handbook
#159I glanced, and I found this handbook shallow and - in some areas - even bad advice. E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY good reason to do otherwise (though exported view can be in anything, even in weird bitcoded formats). FX exchange. Resolution of F…
> E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY good reason to do otherwise (though exported view can be in anything, even in weird bitcoded formats). That really overstates the issue. Whole domains of finance run just fine on doubles. If you're doing Monte Car…
Re: Fintech Engineering Handbook
#160Earlier quoted context omitted.
> 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…
> 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.