On 01/06/2014 21:07, Christian Stimming wrote:
From my point of view the problem is still not yet understood completely here.
IMHO the problem is not too much rounding -- the problem instead is too little
rounding. What are the exact requirements on the handling of rounding and
overflow from our application domain? My argument is that our application
domain of *managing finances* will give us the requirement to do the rounding
according to normal currency numbers! Instead, our implementation using
rational numbers tries to be "more precise" than rounding to currency numbers.
I agree with this. There is no point in precision beyond natural or
market trade. If the global market rounds at a number of decimals then
we should too, I think.
If people are using gnc for enormous fund movements where fractional
amounts of major currency are important I think they should send this
project a few units of currency :)
In effect, this is not more precise but rather more wrong. We must not pretend
to be more clever than the calculations that happen in reality. Speaking of
finance calculations, we must not do the calculations with lesser rounding
than what IFRS or similar authorities will clearly specify. Hence, your
statement that our "internal representation is always exact" is correct from
our programmer's point of view, but IMHO it is not true from the application
requirement point of view (due to missing financial rounding). Your $0.01
discrepancy is a symptom of exactly that. This doesn't mean our calculation is
"more correct", it unfortunately just means our calculation is wrong.
The sum is correct, the allocation of the penny must be made. I think
Christian and I are saying the same thing, here. I also think John
(right or wrong) doesn't want to allocate the penny.
Here's an example where the missing rounding will lead to wrong results: Let's
do some currency exchange, say between USD and EUR. Let's assume an exchange
rate of 1.50 USD = 1.00 EUR (given with normal currency SCU [1] i.e. 2 digits
after the decimal point here) or almost equivalently an exchange rate of
0.6667 EUR/USD (given with more digits after the point). Let's say the user
wants to enter some transactions where she sold 1 USD with the given rate
0.6667. She enters those numbers in the txn dialog: 1.00 USD, rate 0.6667, and
gnucash will calculate the resulting third number: 0.6667 EUR, but the display
will show 0.67 EUR due to the currency's SCU. The user presses Ok because the
resulting 0.67 EUR will match the number on the receipt, i.e. the 0.67 EUR
were the amount that resulted in reality. However, if the gnucash account
contains "the exact value" 0.6667 [2] and we don't do the correct rounding of
this exchange transaction to the currency's SCU, the gnucash account shows
0.67 EUR but internally contains a little bit less. Now the user enters a
second identical transaction: 1.00 USD, rate 0.6667, the displayed EUR value
is 0.67 which is the amount from reality. The user presses Ok again and she
has 2 * 0.67 EUR in reality = 1.34 EUR. However, in gnucash, the account
contains 2 * 0.6667 EUR = 1.3334 EUR, rounded for display to 1.33 EUR. Huh,
where did that 0.01 EUR go missing?
It doesn't need to be that complicated. Any recurring sum will produce
something similar.
The fact is RL transactions don't have indefinite decimals.
My conclusion: We need to introduce more intentional rounding. Every time when
the result of a calculation represents a monetary amount that has some known
SCU (either from the currency or from the account), this amount needs to be
rounded to exactly those digits. No more, no less. And not only for display,
but for the real amounts.
quite
The overflow of the int64 rational numbers is not a problem but inevitable and
probably completely fine. Any numerical data type must have some restriction
on its precision sooner or later, as long as our computers have to live with
finite amounts of memory. Every division and multiplication will increase the
significant digits of the resulting number. This just says that in computer
arithmetics there will always be the question of when to do the rounding. We
can't get around this. So we should better do the rounding according to the
application domain's requirements, which in our case means the rounding
happens rather soon. No need to get more significant digits from somewhere.
The number data type could have been chosen more suitable to our application
domain (which is what I pointed out by the decimal64 floating point format),
but the resulting 19 significant digits of gnc_numeric are just fine.
Did I get something completely wrong here? If we are missing the intentional
rounding of monetary values, this will be a problem, but the finite precision
of gnc_numeric will probably not be a problem.
I think, Christian is heading in the right direction.
--
Wm
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
