With valuation now preserving more decimal digits, roi could show
excessively precise decimals if there was no known display precision
for the valuation commodity. Now in that situation it limits the
precision to a maximum of 8 digits.
This and the preceding commits were "work in progress" that got out of control.
There's more to do, but this one brings these precision-related improvements
(at least):
When "infinite decimals" arise, they are now generally shown with
8 decimal digits rather than 255.
print and prices no longer add trailing decimal zeros unnecessarily.
Some code has been refactored or given more debug output.
All tests have been updated to match the recent changes.
- The prices comand now more accurately lists the prices that hledger
uses when calculating value reports (similar to what you'd see with
eg `hledger bal -V --debug=2`).
- The prices command's --infer-reverse-prices flag was confusing since
we always infer and use reverse prices; it has been renamed to --show-reverse.
- --infer-market-prices and --show-reverse combine properly.
- --show-reverse now ignores all zero prices rather than giving an error.
- Reverse prices (which can be infinite decimals) are now displayed
with at most 8 decimal digits (rather than the internal precision of
255 digits).
- Filtering prices by cur: or amt: now works properly.
- Price amounts are styled, but all decimal digits are shown.
Cost/value conversion now applies the standard display style, and
sets the display precision equal to the internal decimal precision
(or 8 if the decimal appears to be infinite).
This means value reports and especially `print -V` now show amounts
with more accurate and standard style and precision.
New tests have been added describing and explaining various
style/precision behaviours in print cost/value reports.
Changes to enable more control of "rounding" behaviour
(ie, choosing display precisions for amounts).
This reverts 1.31's change of asprecision, making it a non-Maybe
again, and adds a new asrounding field providing more control over how
a target display precision is applied to existing amounts (two options
for now, more later). Functionality is in an interim state (reports do
no rounding).
Eg "1,000" (with , as a thousands separator and no decimal digits) is
now displayed with a decimal mark: "1,000.".
"1 000" (where space is a thousands separator) is less ambiguous,
but we do the same thing (eg "1 000.") for consistency, and also to
help disambiguate when forgetting to quote a numeric commodity symbol
(eg "1234 0" where 1234 is a symbol that should have been in double quotes).
This simplifies the code for styling amounts with or without precision.
But it complicates the semantics (Nothing is useful only when setting style).
Not sure if it's the best way.
print now shows zero posting amounts with their original commodity
symbol and the corresponding style (instead of stripping the symbol).
If an inferred amount has multiple zeroes in different commodities,
a posting is displayed for each of these.
Possible breaking changes:
showMixedAmountLinesB, showAmountB, showAmountPrice now preserve
commodityful zeroes when rendering. This is intended to improve print output,
but it seems possible it might also affect balance and register reports,
though our tests show no change in those.
Equity conversion postings and cost amounts were being matched up too
exactly, causing valid entries with redundant conversion postings and
costs to be rejected. Now the amounts are compared with the precision
(number of decimal places) used in the conversion posting's amount.
Eg, here the first posting's 209.60495 GEL cost is recognised as a
match for the third posting's -209.60 GEL, using the latter's two
digit precision:
2023-01-01
Assets -84.01 USD @ 2.495 GEL ; 209.60495 GEL
Equity:Conversion 84.01 USD
Equity:Conversion -209.60 GEL
Assets 209.60 GEL
The suggested sample balance assertion now uses the same commodity
symbol as in the failing posting (the first, if there are more than
one). Also the cleared mark has been removed.
hledger check recentassertions now reports the error at the first
posting that's more than 7 days later than the latest balance
assertion (rather than at the balance assertion). This is the thing
actually triggering the error, and it is more likely to be visible or
at least closer when you are working at the end of a journal file.
Since 1.29, we unconditionally run part of the --infer-cost logic to
identify redundant costs/equity postings. This was too strict, raising
an error whenever it could not find postings matching the equity
postings. Now we do this (and also the explicit --infer-costs
operation) as a best effort, leaving transactions unchanged if we
can't detect matching postings. This is consistent with
--infer-equity, --infer-market-prices, -B and -V.
Transaction balancing is supposed to balance costs, but these were
being stripped when calculating balance assignments, causing us to
wrongly reject this transaction when the last amount is left implicit,
unlike Ledger:
2023-01-01
Assets AAA -1.1 @@ CCC 2
Assets BBB -1.2 @@ CCC 3
Expenses:Fees CCC 0.2
Assets = CCC 4.9
I'm not sure why costs were being stripped. I seem to have added it
in 2019 (to Journal.balanceNoAssignmentTransactionB in 3b47b58ae),
but this bug seems to be present even before that.
Since hledger 1.25, "every Nth day of month" period rules with N > 28
could be off by a couple of days if given certain forecast start dates.
Eg `~ every 31st day of month` with `--forecast='2023-03-30..'`.
Breaking change: previously timeclock descriptions could contain
semicolons. Now a semicolon in the description will end it and
start a comment (which may contain tags).
