Repository navigation
print can show unbalanced entries due to display rounding #931
Description
This frequently annoys me when I need to re-parse print's output, eg when doing a query that requires a pipeline. Time to do something about it.
; limit display precision to 2 places
commodity $0.00
1/1
a -$0.01
b $0.005
c $0.005
print shows an unbalanced transaction:
$ hledger print
2018/01/01
a $-0.01
b 0
c 0
which can not be re-parsed:
$ hledger print | hledger -f- print
hledger: "-" (lines 1-4)
could not balance this transaction (real postings are off by $-0.01)
2018/01/01
a $-0.01
b 0
c 0
Activity
simonmichael commentedon Nov 29, 2018
PS, a use case to justify this: fractions of a cent don't typically arise in day to day transactions, but they do arise eg when splitting shared expenses according to some rule, eg splitting an odd amount 50-50.
You can work around it by putting the extra cent on one amount or the other, but this requires thought and manual intervention and can cause disagreement with external systems - I would rather use the correct mathematical split.
You can also work around it by temporarily commenting out the commodity directive to allow unlimited display precision. But this is manual and annoying (and now all dollar amounts are rendered with three decimal places).
lib: try to pin down what isTransactionBalanced does (#931)
lib: clarify what postingsAsLines does (#931)
lib: add disabled test for proposed #931 solution
simonmichael commentedon Oct 23, 2020
See also @rhyanki's example on #1276. Rounding according to the commodity display styles can cause invalid/unparseable journal entries to be printed.
What is better behaviour here ? I guess print should be allowed to print more decimal places when needed to guarantee a valid entry, overriding the display styles ? I'm not sure what the algorithm would be exactly.
[-]print can show unbalanced transactions with a commodity directive[/-][+]print can show unbalanced entries due to display rounding[/+]rhyanki commentedon Oct 24, 2020
I guess the algorithm would be to iteratively increment the number of decimal places until it balances? Intuitively that seems like it should be guaranteed to find a solution, but I'm not certain.
In the case of auto-transactions, this approach could lead to very ugly print output, for a potentially very high percentage of transactions in the journal (not so much an issue with the commodity directive example in the OP).
Another approach might be to let the user specify a special "rounding" account (or pick one by default). Then for any transaction which is unbalanced in the printed output, we add a posting to the rounding account which balances it out. So for my example, the new output might be:
Then we don't need to print more decimal places, and any transaction which is already balanced in the output can still be left alone.
simonmichael commentedon Feb 4, 2021
Another approach: have the print command ignore the "decimal places" part of commodity styles, ie always show the original number of decimal places for all amounts.
simonmichael commentedon Feb 4, 2021
Which actually is what Ledger's print command does, mostly (it strips trailing zeroes).
print: always show all decimal places (#931)
ui: transaction: show all decimal places (like print, cf #931)
print: always show all decimal places (#931)
ui: transaction: show all decimal places (like print, cf #931)
lib: use a transaction's amount precisions when balancing it
lib: use a transaction's amount precisions when balancing it
use a transaction's amount precisions when balancing it (#1479)
use a transaction's amount precisions when balancing it (#1479)