3 ms·
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 inaccurac
by carnitine 5y 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.
- JackFr 5y agoI 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.”
- brazzy 5y agoThe difference between precision and accuracy in a nutshell.
- brazzy 5y agoExactly. 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).
- Chris2048 5y agoCan 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"
- carnitine 5y agoYou don’t do that though, there’s no use case to account with the output of a model.
- Chris2048 5y agoI'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.
- chewbaxxa 5y agoSure we add up the numbers, but there are thresholds for everything anyway. We might not be concerned about something within a 1MM range let alone a floating point inaccuracy. The uncertainty is accounted for already.