# unclear interaction of balance assertions and display precision #941

Closed
opened this Issue Jan 6, 2019 · 8 comments

Projects
None yet
1 participant
Owner

### simonmichael commented Jan 6, 2019 • edited

 It's currentlly possible, if you have a commodity directive limiting display precision, to have a balance assertion failure where both amounts in the error message look identical, eg: commodity \$1000.00 2019/01/01 (a) \$1.006 = \$1.01 \$ hledger stats ... calculated: \$1.01 asserted: \$1.01 (difference: +0) This is unhelpful. Perhaps there was some discussion of this in 2018, but I don't remember where. How should balance assertions work when there is a limited display precision ? Some options: compare the exact calculated balance with the exact asserted balance; display precision is ignored (current behaviour) problem: the failure message shows the amounts with display precision, sometimes hiding the reason for failure. Solutions: in the failure message, show amounts at full precision ? show the amounts with just enough precision so they look different ? compare the calculated balance rounded to display precision, with the exact asserted balance ? compare both balances rounded to display precision ? problem: I think both of the above allow multiple different asserted balances to succeed, which feels a little loosey goosey compare both exact balances by calculating the difference between them, and checking if that looks like zero when rendered at display precision. (I think this is distinct from the above but I'm not certain.)

Owner

### simonmichael commented Jan 6, 2019 • edited

 Several test cases to consider: a. commodity \$1000.00 2019/01/01 (a) \$1.006 = \$1.01 b. commodity \$1000.00 2019/01/01 (a) \$0.006 2019/01/02 (a) \$1.00 = \$1.01 c. commodity \$1000.00 2019/01/01 (a) \$0.006 2019/01/02 (a) \$1.00 = \$1.006 d. commodity \$1000.00 2019/01/01 (a) \$0.006 2019/01/02 (a) \$1.00 = \$1.0061

Owner

### simonmichael commented Jan 6, 2019

 I have implemented compare both exact balances by calculating the difference between them, and checking if that looks like zero when rendered at precision P, where P is the larger of the standard display precision and the full precision of the asserted amount. This makes the checking a little looser, so cases a & b above now pass, as well as c. See new docs at http://hledger.org/journal.html#assertions-and-precision. This still feels a bit complicated, and the error messages can still be a bit confusing, eg the message for case d above now says this, which doesn't look right: calculated: \$1.01 asserted: \$1.0061 (difference: +\$0.0001)
Owner

### simonmichael commented Jan 7, 2019 • edited

 Here's how 3 might look (compare both amounts rendered at display precision; show both display and full precision in the error message). Perhaps this is the way to go ? "Assertions pass if the calculated amount and the asserted amount look the same when rendered at the standard display precision. In practice this means there is some leeway in how you write assertion amounts: you can write them exactly, or rounded to the typical number of decimal places. Here are some examples of this in action. Asserting the exact balance: commodity \$1000.00 2019/01/01 (a) \$0.006 2019/01/02 (a) \$1.00 = \$1.006 ; Display precision 2 ; Actual balance: 1.006 ; Asserted balence: 1.006 ; Rendered: 1.01, 1.01 ; Result: pass Asserting the balance rounded to fewer decimal places: commodity \$1000.00 2019/01/01 (a) \$0.006 2019/01/02 (a) \$1.00 = \$1.01 ; Display precision 2 ; Actual balance: 1.006 ; Asserted balence: 1.01 ; Rendered: 1.01, 1.01 ; Result: pass Asserting an inexact balance that rounds correctly: commodity \$1000.00 2019/01/01 (a) \$0.006 2019/01/02 (a) \$1.00 = \$1.0069 ; Display precision 2 ; Actual balance: 1.006 ; Asserted balence: 1.0069 ; Rendered: 1.01, 1.01 ; Result: pass Asserting a balance that rounds incorrectly: commodity \$1000.00 2019/01/01 (a) \$0.004 2019/01/02 (a) \$1.00 = \$1.006 ; Display precision 2 ; Actual balance: 1.004 ; Asserted balence: 1.006 ; Rendered: 1.00, 1.01 ; Result: fail ; Error message: ;calculated: \$1.00 (rounded from \$1.004) ;asserted: \$1.01 (rounded from \$1.006) ;difference: +\$0.01 "
Owner

### simonmichael commented Jan 7, 2019

 Or, 1b. keep the current behaviour (asserted amounts must be written exactly) but show both display and full precision in the error message, as above.

### simonmichael added a commit that referenced this issue Jan 8, 2019

journal: make balance assertions exact again (#941)
Going with option 1b from the issue: calculated and asserted amounts
are compared exactly, disregarding display precision.
But now balance assertion failure messages show those exact amounts at
full precision, avoiding confusion.
Owner

### simonmichael commented Jan 8, 2019

 Going with 1b, or something similar. Now, calculated and asserted amounts are compared exactly, and balance assertion failure messages show those exact amounts at full precision. Display precision doesn't affect balance assertions at all.
Owner

### simonmichael commented Jan 8, 2019

 Eg: commodity \$1000.00 2019/01/01 (a) \$1.006 = \$1.01 \$ hledger reg *** Exception: balance assertion: "c0.j" (line 4, column 29) transaction: 2019/01/01 (a) \$1.01 = \$1.01 assertion details: date: 2019/01/01 account: a commodity: \$ calculated: 1.006 asserted: 1.01 difference: 0.004

Owner

### simonmichael commented Jan 8, 2019

 I think this resolves it, let me know of issues.

Owner

### simonmichael commented Jan 16, 2019

 The closing and opening transactions generated by hledger close can break due to this: ; limit display precision to 2 digits commodity \$0.00 2019-01-01 (a) \$1.001 ; hledger close generates the following closing transaction, with ; display precision. The assertion is not exact, and will fail (since #941). 2019-01-15 closing balances a \$-1.00 = \$0.00 equity:closing balances