|
|
|
|
@ -15,12 +15,12 @@ both the register entry and the price must have links to each other
|
|
|
|
|
|
|
|
|
|
This is needed because if the user enters an incorrect amt or value
|
|
|
|
|
or date in the transaction register, and then corrects it later,
|
|
|
|
|
piossibly weeks or months later, the corresponding price in the
|
|
|
|
|
possibly weeks or months later, the corresponding price in the
|
|
|
|
|
priceDB must be fixed as well.
|
|
|
|
|
|
|
|
|
|
Similarly, if a user deletes a transaction (possibly because it
|
|
|
|
|
contains an error in date/amt/value), then it is adviasable that
|
|
|
|
|
the correpsonding priceDB entry must be deleted as well (since
|
|
|
|
|
contains an error in date/amt/value), then it is advisable that
|
|
|
|
|
the corresponding priceDB entry must be deleted as well (since
|
|
|
|
|
it is not safe to assume that the price is 'correct').
|
|
|
|
|
|
|
|
|
|
\section Rounding errors
|
|
|
|
|
@ -30,7 +30,7 @@ round-off errors can make 'obvious' math inaccurate. Note that if
|
|
|
|
|
we define price as (value/amt), then we will find that
|
|
|
|
|
value != price * amt due to roundoff handling. One must be careful
|
|
|
|
|
and consistent in handling this in the register, as otherwise
|
|
|
|
|
users will be driven crazy by inconsitent behaviour.
|
|
|
|
|
users will be driven crazy by inconsistent behaviour.
|
|
|
|
|
|
|
|
|
|
(Linas Vepstas April 2003)
|
|
|
|
|
|
|
|
|
|
|