# How do we handle --

Jason Rennie jrennie@ai.mit.edu
Fri, 28 Jul 2000 17:49:08 -0400

```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

```