I wrote a whole new thing to deal with the rendering of numbers, here: https://bitbucket.org/blais/beancount/src/tip/src/python/beancount/core/display_context.py?at=default
This is an object that is built while parsing the input and it tries to figure out automatically what the most frequently used and maximum precision formats are for each currency. It can then be used to render all the core objects, and supports various alignment options. I've started using it in a few places but not everywhere yet. I have yet to make all the reports use it but when I do the web interface should render the number at its most common precision automatically, that is, if you entered a lot of X.XX digits for USD, those numbers would render as 1234.56. I don't recall where I stopped, I have it on my list to take a second look at this and complete replacing it everywhere. In particular, bean-query output has its own separate mechanism to render numbers that should be replace by this newer and better display_context: https://bitbucket.org/blais/beancount/src/tip/src/python/beancount/query/query_render.py?at=default On Wed, Jun 10, 2015 at 3:21 PM, <[email protected]> wrote: > Thanks Martin, for filing the bug! The workaround is totally fine for now, > if that helps with prioritizing. > > There is a related question I have. Even if I use 331.00 USD for the > Liabilities posting, the sum of the Expenses posting would add up to (and > render as) 330.9999999999999999999999997 USD. Although this is > computationally "correct" given what I asked for (331/12), is there a > better way to perhaps render it (on the web or in bean-query) just so it > appears prettier? This too is a pretty minor issue - just something for the > long term work, perhaps. > > > > On Wednesday, June 10, 2015 at 11:34:34 AM UTC-7, Martin Blais wrote: >> >> Oh <poop> indeed, that looks like a bug. >> What's happening is that division will be processed by the parser and >> produce the full 28 decimal digits of precision, and that it used as input >> for tolerance inference (and it shouldn't be IMO) and then because your >> other amount is an integer (331) it doesn't contribute to the tolerance >> inference. I need to find a solution for this, probably disable inference >> from computed numbers... this is a case where the per-transaction tolerance >> inference fails - congratulations you've found a bug. >> >> In the meantime, changing your first amount from -331 SUD to -331.00 USD >> should do the trick, because it'll expand the tolerance on USD to 0.005 and >> that's enough >> >> Tracking bug: >> >> https://bitbucket.org/blais/beancount/issue/56/figure-out-how-to-disable-tolerance >> >> >> >> >> On Wed, Jun 10, 2015 at 12:03 PM, <[email protected]> wrote: >> >>> I'm not sure I understand how the divide operator interacts with the >>> recent tolerance changes, if it does. For example, if I do this: >>> >>> -------------------------------------------------------- >>> option "title" "Main accounts" >>> option "operating_currency" "USD" >>> >>> 1999-01-01 open Liabilities:Credit-Card >>> 1999-01-01 open Expenses:Utility-Bill >>> >>> 2000-01-01 * "Power company" >>> Liabilities:Credit-Card -331 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> Expenses:Utility-Bill 331/12 USD >>> -------------------------------------------------------- >>> I get: bean-check output: >>> divide.bc:7: Transaction does not balance: (-2.8E-25 USD) >>> >>> Is there a recommended way to handle such situations without having to >>> add an explicit rounding error posting? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Beancount" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beancount/a1b520d1-1039-43d2-8054-58411e5e1e9e%40googlegroups.com >>> <https://groups.google.com/d/msgid/beancount/a1b520d1-1039-43d2-8054-58411e5e1e9e%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/a1a2d631-b0f6-4a66-ae70-6c5562cc540e%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/a1a2d631-b0f6-4a66-ae70-6c5562cc540e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- --- 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.
