How do we handle --

[Jason Rennie]

So, here something from left field...

All of this discussion concerning roundoff error, internal number 
representation, etc. seems to be assuming that there *is* a right answer.  
i.e. if we discuss and think hard enough, we'll be able to come up with a 
solution that will always do the right think with respect to roundoff 
error.

Another approach would be to assume that we can't win, go with the 
floating point representation that we have and allow the user to fix 
roundoff "errors" by explicitly stating what a*b equals when a 
price*amount calculation doesn't match what it needs to be.

For example.  Say I buy 17 share of stock "foo" at 13 1/16.  GNUCash might
calculate this as 222.06 (doing rounding after multiplying 17 by 13 1/16).
 However, whatever system does the actual transaction calculation rounds
the price to cents and then does the multiplication, hence deciding that I
actually owe 222.02 (17*13.06).  So, why not just let the user change 
222.06 to 222.02?  i.e. if the user modifies the transaction amount, 
ignore what GNUCash calculates and simply use what the user entered, 
trusting that 17 * 13 1/3 does, in fact, equal 222.02 via some 
calculation scheme.

Putting this idea into GNUCash will create some GUI issues, e.g. what 
happens if the user changes the quantity after entering a transaction 
amount?  Do we recalculate the transaction amount or trust the old value 
entered by the user?  However, the positive aspect is that GNUCash ends 
up doing all of the rounding correctly because it lets the user correct 
its "errors."

Anyway, just another thought to throw into the foray...

Jason D Rennie          www.ai.mit.edu/~jrennie/
MIT:  (617) 253-5339          jrennie@ai.mit.edu
MITRE: (781) 271-7249          jrennie@mitre.org