On Tue, Jul 1, 2014 at 3:22 PM, Martin Michlmayr <[email protected]> wrote:

> * Stefano Zacchiroli <[email protected]> [2014-06-24 12:07]:
> > I agree with both Martin-s that this is not enough, at the very least
> > precision should also be customizable at the account level.  However, if
> > we have precision associated to both commodities and accounts, how would
> > they interact? Account might contain multiple commodities; would
> > specifying a precision for an account mean that all commodities
> > contained therein must have the same precision?
> >
> > Sounds like we might need the ability to specify:
> >
> > - a default commodity precision
> > - a default account precision
> >   (with rules deciding who wins among these two)
> > - a specific precision for commodity/account pairs
>
> Maybe something like:
>
> commodity EUR
>     precision 2
>
> account Foo
>     commodity EUR
>         precision 2
>     commodity GBP
>         precision 3
>
> I think this would meet all requirements.
>
> > > While precision is probably the same for one currency regardless of
> > > the account
> >
> > I don't think that's necessarily the case. Either way, this seems to be
>
> Yes, Martin already gave an example where it's not true.
>
>
> > This is somewhat tangential to your question, but we do need a way to
> > specify the *display* precision, more flexible than what we have
> > now. Your initial example using D works in restricting the output
> > precision for lot prices, but AFAICT D doesn't work in restricting the
> > display precision for simple postings, e.g.:
> >
> >   zack@timira:~$ cat test-rounding.ledger
> >   D 10.00 EUR
> >
> >   2014-01-01 Foo
> >       Assets:Cash                              10.1234 EUR
> >       Income
> >   zack@timira:~$ ledger -f test-rounding.ledger bal
> >            10.1234 EUR  Assets:Cash
> >           -10.1234 EUR  Income
> >   --------------------
> >                      0
>
> I think the problem you're trying to raise is that the display
> precision can only extend the display precision, not reduce it.


Someone ought to summarize this thread into a well-organized design doc
that arranges all the issues nicely, something like Python's PEP documents.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to