[GNC-dev] gnc_numeric division with how=GNC_HOW_DENOM_LCD
geert.gnucash at kobaltwit.be
Sat May 19 05:28:46 EDT 2018
Christopher Lam is busy writing unit tests for our business reports which is
However he has run into a peculiar issue in that he can't create a test
invoice entries that properly handle tax or percentages.
I have been tracing in the debugger and I ran into a peculiar bug for which I
need some feedback.
The core of the issue is in this line:
This division is to convert a number as entered by the user into a percentage
The user enters "10", which the code should interpret as 10%, or 0.01
This works fine with numbers entered by real users in the user interface,
however it fails when generating these same numbers via scheme code.
And this is because both get a different denominator: all user entered numbers
(in this context) will be stored with a denom of 100000. However when you make
a scheme rational 1000000/100000 (so equivalent to 10), it gets reduced to
10/1 by the time it's used in the line above. Clearly guile automatically
The net effect is that for user entered numbers the line above will divide
1000000/100000 by 100/1 while for scheme generated numbers the division
becomes 10/1 by 100/1.
Combining this with how=GNC_HOW_DENOM_LCD makes that the denominator will be
fixed to 1 causing 0.1/1 to be rounded to 0.
That's the symptom. But I do have some difficulty determining the actual
cause: is gnc_numeric_div doing the wrong thing with GNC_HOW_DENOM_LCD ? That
would make it a bug in gnc_numeric_div. In a division I would expect the
nominator of the divisor to be taken into account to calculate the LCD but
perhaps my (accounting related) math is wrong.
Or perhaps GNC_HOW_DENOM_LCD just doesn't make sense for a division and
another rounding method should be used here? That would make it a bug in the
Or both are right and I should just ensure to have a proper common denominator
somehow. I could maybe set percent in the calculation above to 10000000/100000
instead of to 100/1.
Or I could avoid gnc_numeric_div altogether by multiplying with 1/100 instead.
However I wanted some feedback before applying one of the workarounds to be
sure I'm not masking a a more important bug that way.
More information about the gnucash-devel