Hacker News Reader

Comment by oddthink | Hacker News Reader

> 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 Carlo options pricing over interest rate paths, and you're interested in the risk metrics, like durations, convexity, vega, and so on, no one cares what your rounding convention is. doubles are just fine, thank you. How are you going to force `exp(-rt)cashflow` to be an integer? Or the normal CDF?

Yes, there are domains where ints make sense. But it's certainly not universal, you just need to make the right engineering choice.

View on HN

It can be really frustrating viewing threads like this sometimes. I've not once seen an interest rate swap priced in anything other than float/double, and that's relatively simple even compared to some of the crazy instruments out there.

Like, sure, probably don't use floats for everything, but what are the odds that your greeks are gonna be nicely expressable as simple rationals?

Quick browse over Stripe API (i.e. not a simplistic payment provider) will show exactly otherwise.

Metrics/durations/convexity/vega aren't monetary value, these are calculation values and I'm fine with them being whatever. If you're calculating averages to make decisions based on this I don't care if you're counting dolars or tomatoes.

Monetary value is $4.50 and it's representation of actual money passed through system. In practice this value is almost never undergoing any operations except for addition and subtraction. Any multiplication/divison etc. is left to specialized systems that return results wrapped in 800 pages of standarization documents, regulations and so on; systems where term "bit flip" is not a joke, but a risk.

As I wrote fintech != fintech, and I know many organizations aren't at that level of scrutiny, but a huge domain of people dealing with others' people money know that charging someone 1 cent too much is a tens of thousands of problems coming their way.

What's your preferred solution to dealing with FX conversions?

My issue with using integers everywhere is that FX conversions (or other rates) always come into play, and at that point I'm forced to use something else anyway (e.g. arbitrary precision decimals).

I never had to deal with that. At one place it was so complicated that specialized system took reconciliation over (it got baggage full of context data including exchange agreement details, with boundaries and time-regions plan).

In not-a-fintech we just went with doubles and rounded up (worst case - we get a cent more of a customer).

Though if I had to design today for that, I'd look for non-string serializable decimal, so not "10.123 == (10, 123)" but more like (10123, 3) and serialize in JSON as a value and precision separately.

Yet that's only cause I saw Decimal(10,123) sent in JSON as "10.123" which JSON reader red as 10.122 float and inserted to "1012" to database.

I worked on a trading system dealing with transaction limits expressed in USD but trading in many currencies.

FX rates and prices were expressed in fixed point because it was more efficient to handle in FPGA. A lot of thought went in to making the system accurate enough based on real FX rates while falling on the right side of the limit

Basically whenever you are acting as a custodian e.g., a bank. Then you have to be super careful.

No one cares if you’re mortgage calculator is off by a penny

I love how this sensible take is followed by a tornado of comments that boils down to "NEVER use floats JUST BECAUSE".

Never use floats for financial calculations. Because hard won experience.

"Floats" are simulations of Real Numbers, and Reals are uncountable. Not what you want for finance, where everything is counted.

I suggest reading the comment I was replying to since it contextualises the answer quite well. Hard to find absolutes in real life outside of thermodynamics.

> you're interested in the risk metrics, like durations, convexity, vega, and so on, no one cares what your rounding convention is. doubles are just fine, thank you.

Doubles are not just fine, but required there. If you compute risk, as you allude to, by finite differences, then you need the precision of floats rather than rounding to integer cents prematurely.

Rule of thumb here is that investments will work fine using doubles, but transfers need to run on int or fixed point.

It doesn't matter for quant finance to use floats because approximate is perfectly fine. Tracking the exact amount to accounting standards is the job of the brokerage team not the quant devs. Floats are fine for modeling as long as the numerical drift is accounted for.

Reply on news.ycombinator.com