My application requires a fractional quantity multiplied by a monetary value.
$65.50 × 0.55 hours = $36.025 (rounded to
I know that floats should not be used to represent money, so I'm storing all of my monetary values as cents.
$65.50 in the above equation is stored as
For the fractional coefficient, my issue is that
0.55 does not have a 32-bit float representation. In the use case above,
0.55 hours == 33 minutes, so
0.55 is an example of a specific value that my application will need to account for exactly. The floating point representation of
0.550000012 is insufficient, because the user will not understand where the additional
0.000000012 came from. I cannot simply call a rounding function on
0.550000012 because it will round to the whole number.
To solve this, my first idea was to store all quantities as integers and multiply × 1000. So
0.55 entered by the user would become
550 (integer) when stored. All calculations would happen without floats, and then simply divide by 1000 (integer division, not float) when presenting the result to the user.
I realize that this would permanently limit me to 3 decimal places of precision. If I decide that 3 is adequate for the lifetime of my application, does this approach make sense?
Are there potential rounding issues if I were to use integer division?
Is there a name for this process? EDIT: As indicated by @SergGr, this is fixed-point arithmetic.
Is there a better approach?
I should have clarified, this is not time-specific. It is for generic quantities like
1.256 pounds of flour,
1 sofa, or
0.25 hours (think invoices).
What I'm trying to replicate here is a more exact version of Postgres's
extra_float_digits = 0 functionality, where if the user enters
0.55 (float32), the database stores
0.550000012 but when queried for the result returns
0.55 which appears to be exactly what the user typed.
I am willing to limit this application's precision to 3 decimal places (it's business, not scientific), so that's what made me consider the
× 1000 approach.
I'm using the Go programming language, but I'm interested in generic cross-language solutions.