Hacker News new | ask | show | jobs
by guggle 2341 days ago
> I would argue that financial math by definition needs to be accurate to the penny.

Yes, indeed. There is no such thing as "financial math that does not need to be accurate to the penny". I wonder if OP has ever worked with a bookkeeper...

2 comments

Bookkeeping needs to be accurate to the penny. Estimating growth for the next quarter or last years GDP doesn't.
Yes, but why switch systems though ?
How are you going to do linear interpolation, let alone exponential growth, without floating-point? On August 1 you made $1000, on August 7 you made $1100, assuming that growth is linear, how much are you going to make on August 20?

If you have some routines for dividing fixed-point numbers, one, why do you believe they have more accuracy than floating point (especially if you're doing divisions by numbers that aren't divisible by 10, as in the example above - don't you have the same problem as with floating point?), and why do you believe they're more correct than floating point? Did you write a test suite? Do you know what needs to be tested? What prevented you from writing the test suite for the floating-point calculations you were originally doing to do?

> How are you going to do linear interpolation, let alone exponential growth, without floating-point?

Fixed point is one answer, but I see you know that already. I don’t know what the banks use for interest, but I can guarantee that it’s not float32.

> If you have some routines for dividing fixed-point numbers, one, why do you believe they have more accuracy than floating point

Fixed point routines do not have more best-case accuracy than float, given the same number of bits ... but float32 definitely has a worst-case accuracy that is very very bad compared to a fixed point number.

> why do you believe they’re more correct than floating point?

Can’t speak for the GP, but I think asking about correctness is a straw man. The issue is really about safety, predictability, and controllability. Floating point can be very accurate, but guaranteeing that accuracy is notoriously difficult, and it depends very much on the unknown ranges of your intermediate calculations. Fixed point, on the other hand, never changes accuracy as you go, so you don’t get surprises.

> I think asking about correctness is a straw man. The issue is really about safety, predictability, and controllability.

Uh, and compliance? (if you didn't mean to imply that under "controllability")

Yeah, definitely. My list certainly isn’t exhaustive; just trying to express that use of floating point isn’t only a matter of correctness, there are lots of other factors. The dev time cost of using floats correctly for financial calculations is higher than the dev time cost of using ints or fixed point numbers.
That's not strictly true. Some of the work I do involves software to do premium calculations for insurance. While pennies do matter for intermediate values during calculation, virtually everyone rounds the final premium to a dollar amount or the closest 10 cent increment. Nobody cares about pennies when each transaction is hundreds or thousands of dollars.
Rounding at the last step is very different from rounding at each step.