Comment by carnitine
5 years ago
Always funny to see the objections of new hires without finance experience to the use of floating point for pricing. It’s more related to the inherent inaccuracy of any pricing model though, rather than clients not caring about pennies.
Exactly. Floating point is inappropriate for anything related to accounting (payments, balances, etc.), but when the numbers you're producing are effectively forecasts or estimates, it's no different than what floats were originally invented for (numerical modelling in physics and engineering).
I remember someone demanding that we needed to run our Monte Carlo pricer on 1024 paths, that 256 just wasn’t precise enough and one of the risk guys said “Well since we know our assumptions are wrong I’m not sure what difference it makes.”
The difference between precision and accuracy in a nutshell.
Can cause issues if you are accounting for things, e.g.
"The sum of these values need to equal the sum of these values"
In that case you'd then needs to avoid
"sum_a == sum_b"
and use instead
"abs(sum_a - sum_b) < SOME_SMALL_VALUE"
You don’t do that though, there’s no use case to account with the output of a model.
I'm not sure what you mean - aside from speculative pricing models there are regulatory constraints too, that are a part of the same codebase.
Not to mention that there is a use case for auditing pricing models (as in external requirement, or internally) or comparing alternative models.
1 reply →