Let's discuss the precision

[Roman Cheplyaka]

Suppose we sum some amounts which have different precision.
What should be the precision of the result?

From scientific point of view, where precision (number of digits after
the point) indicates the accuracy of measurements, it's natural to take
the minimum of the precisions.

But in our context, what is the difference between 3.5 and 3.50? It's
just that I was lazy to type an extra zero. There is no reason to cut
the precision.

I see that hledger's behaviour has changed at some point -- once it used
the minimal precision of the addends, now it uses the precision of the
seconds addend (at least the comments say so).

Here's an example which shows why it matters.

------

Enter one or more transactions, which will be added to your ledger file.
To complete a transaction, enter . as account name. To quit, press control-c.
date [2010/02/13]:
description: sample transaction
account 1: acc1
amount 1 [0]: 13.75
account 2: acc2
amount 2 [-13.75]: 2.5
account 3: acc3
amount 3 [-16.3]: <Enter>
account 4: .

could not balance this transaction, amounts do not add up to zero. Re-enter:

------

Any reasons to support another behaviour?

--
Roman I. Cheplyaka :: http://ro-che.info/
"Don't let school get in the way of your education." - Mark Twain

[Simon Michael (sm)]

> I see that hledger's behaviour has changed at some point -- once it used
> the minimal precision of the addends, now it uses the precision of the
> seconds addend (at least the comments say so).

I don't quite remember that, the commit message might help. But it
seems to me the immediate bug is in add, it should be prompting
[-16.25] surely.

[Roman Cheplyaka]

* Simon Michael (sm) <si...@joyful.com> [2010-02-13 07:42:25-0800]

> But it seems to me the immediate bug is in add, it should be prompting
> [-16.25] surely.

Sure it should! And the reason it prompts [-16.3] is the wrong (in some
sense) definition of amountop (used in the instance Num Amount).

This is the point of my original letter.

[Simon Michael]

I see.. it's just the "display precision" we are talking about here. I
think the current Amount code works well for most of our needs, but we
go wrong here in Add:

defaultamount = maybe balancingamount (Just . show . pamount)
bestmatch
where balancingamount = Just $ show $ negate $ sum $ map
pamount enteredrealps

where we take the "show" value, rather than the actual value ?

A test would be good.

[Simon Michael]

Also, you may know this already but I think we want it to work this
way: add's default amounts use the greatest display precision for that
commodity so far encountered within the current transaction.