reproducible, & possibly configurable rounding

Bradley M. Kuhn bkuhn at ebb.org
Sat May 10 11:54:07 EDT 2014


Josh Berkus wrote at 13:21 (EDT) on Thursday:
> Well, if you're doing all python code now, the solution is simple; use
> decimal.decimal.  Fixed-decimal-point numbers are your friend here.
> When I do the PostgreSQL backend eventually, that will use NUMERIC,
> not FLOAT, for the same reason.

Actually, I think Ledger-CLI's internal representation is better as it
never loses any precision until reporting.  However, making sure rules on
this are configurable and documentable is important.  That's
basically what Tripun is ultimately working on.

I assume Python's decimal is going to round when division happens and the
rules are documented in the Python docs, but having configurable options is
somewhat better IMO.

> I've seen other solutions.  For example, one alternative solution is
> that your storage system actually keeps an extra decimal point (for
> USD, 0.000), and doesn't round that off until you have to output
> something.

Sure, Ledger-CLI is roughly this way too, in fact, it has integer
rationals until it prints.  The problem is what gets output: that's what
everyone who consumes the numbers sees anyway.

-- 
   -- bkuhn


More information about the npo-accounting mailing list