reproducible, & possibly configurable rounding

Bradley M. Kuhn bkuhn at ebb.org
Sat May 10 11:59:42 EDT 2014


Josh Berkus wrote at 13:25 (EDT) on Thursday:
> If it has rounding issues, then the answer is to abandon ledger-CLI
> for something else, or reimplement it using code which supports
> fixed-point arithmatic (maybe even that Python project I found).

Let's clarify something here:

I posted a list of student-accessible bugs to our Wiki for our GSoC
project and Tripun picked this one and wrote a great GSoC application,
so I picked him as our one GSoC student.  I'm meanwhile getting started
with Tripun earlier than I thought because his exam schedule conflicts
with the first week of GSoC, so he wanted to get started early.

That's the only reason this rounding issue ended up being the first
issue I discussed on this list during my transition out of the
role of Conservancy's Executive Director.  It's a coincidence, not
a comment on this project's priorities.  If I failed to explain that
adequately in my first post on this thread, please accept my apologies
for failing to be abundantly clear.

Meanwhile, I suspect you're thinking that we've prioritized this
minor bug for some other reason.  Frankly, the appropriate way to
deal with that would have been to simply ask:
"Are you sure this issue should be the top priority for this project?"

...which I could have easily answered with the above, and that would
have settled this without exaggerated accusations.

> a waste of time and money

This is a minor problem that needs addressed.  A GSoC student is doing
it so Google is paying for it, anyway.

Plus, I don't think closing a bug in an important project that we're
relying on is a waste of time.  Tripun is likely going to do other
things this summer as well that will also be quite useful.  Tripun
has already shown clearly that the rounding problems in Ledger-CLI
that concerned me are not as bad as I thought they were (and I
thought they were minor to start anyway).

> Ledger-CLI's functionality is not that complex.

It's the best implementation of double-entry accounting I found by far.
I really don't want to redo the work we've already done in evaluating
projects, but if you really have an implementation of double-entry
accounting that you think is better and supports the kinds of
features Ledger-CLI does, and that easily imports ledger-cli
data (so Conservancy can bootstrap itself and be the first testers
of this new project), then please do present it to us. 

However, we're going to find bugs in any code we rely on.  We're
going to spend time closing them.  However, in this case, I suspect
most on this list will agree that it was highly good planning on
Conservancy's part to use GSoC to get some of those bugs closed
rather than spending my own time on it.  Josh, if you don't agree,
I'd venture that you might be a minority of one.

> This whole project is in serious danger of being consumed by
> yak-shaving.

I've explained above why there's likely a confusion on your
part about the amount of attention this project is giving to this
rounding issue, and that your accusations are inappropriately
exaggerated.  If my explanations above don't address your concerns,
I think we should take this sub-thread off-list.
-- 
   -- bkuhn


More information about the npo-accounting mailing list