[GNC-dev] gnc_numeric division with how=GNC_HOW_DENOM_LCD

[Geert Janssens]

Christopher Lam is busy writing unit tests for our business reports which is 
great.

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:
https://github.com/Gnucash/gnucash/blob/maint/libgnucash/engine/
gncEntry.c#L1139

This division is to convert a number as entered by the user into a percentage 
value.
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 
reduces rationals.

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 
gncEntryComputeValueInt function.
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.

Geert