And then there was one

[John Wiegley]

So, after a few months of working with Claude, C++Ledger is now down to 1
issue remaining: the desire to offer a PyPI package for Python users.

Now that the dust has settled, please if anyone encounters issues are broken
behaviors resulting from all of this hectic churn, report them now so that I
can be sure this version is in good shape before tagging the next release
candidate.

Thanks and apologies for the turmoil!
John

[Alexandre Rademaker]

Congratulations John! Excellent work. Thank you so much for your effort to develop and maintain Ledger.

Best,

--
Alexandre Rademaker
http://arademaker.github.io

[o1bigtenor]

On Tue, Apr 28, 2026 at 12:43 PM Alexandre Rademaker
<arade...@gmail.com> wrote:
>
>
> Congratulations John! Excellent work. Thank you so much for your effort to develop and maintain Ledger.
>
>

Thanks from me too.

[Tavis Ormandy]

Thanks for being patient with my reports, I just checked and I filed 15!

I think a major change is the rounding changes... IIUC ledger used to
always maintain maximum possible precision and then just round at the
end when an amount needed to be displayed. The next release rounds after
every single transaction.

I'm not really sure of the benefit, but the obvious problem is that
people with lots and lots of commodity trades might notice balances
drift after they upgrade. Today, even with the most complex ledger if
you do something like `ledger --cost -X USD bal` the total should be no
more than +/- 1 cent (from the final rounding for display...right?).

I think with the next release, there's no real limit to how far away
from zero it will be. I guess it doesn't break anything, but it feels
like a big change because it's no longer true that "the journal must
always balance to zero"... which used to be the fundamental rule of
ledger...

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger tav...@sdf.org
_\_V _( ) _( ) @taviso

[John Wiegley]

>>>>> "TO" == Tavis Ormandy <tav...@gmail.com> writes:

> I'm not really sure of the benefit, but the obvious problem is that people
> with lots and lots of commodity trades might notice balances drift after
> they upgrade. Today, even with the most complex ledger if you do something
> like `ledger --cost -X USD bal` the total should be no more than +/- 1 cent
> (from the final rounding for display...right?).

I definitely do not want commodity drift, so I’m going to dig into this change
in behavior more deeply.

John

[Tavis Ormandy]

Oh, okay, thanks, I guess I didn't think it was a bug just a major
change :)

I guess a minimum testcase would be some transaction that needs
rounding, e.g.

2025/01/01 * Opening Balances
Assets:Brokerage $123.45
Equity:Opening Balances
2025/02/01 * Investment
Assets:Brokerage 0.005 FOO @ $124.95
Assets:Brokerage 0.001 BAR @ $124.95
Assets:Brokerage

with main you get:

$ ledger --cost -X USD bal
$123.44 Assets:Brokerage
$-123.45 Equity:Opening Balances
--------------------
$-0.01

But every rounded transaction can add a penny, so if I duplicate it
three times...

2025/01/01 * Opening Balances
Assets:Brokerage $123.45
Equity:Opening Balances
2025/02/01 * Investment
Assets:Brokerage 0.005 FOO @ $124.95
Assets:Brokerage 0.001 BAR @ $124.95
Assets:Brokerage
2025/02/01 * Investment
Assets:Brokerage 0.005 FOO @ $124.95
Assets:Brokerage 0.001 BAR @ $124.95
Assets:Brokerage
2025/02/01 * Investment
Assets:Brokerage 0.005 FOO @ $124.95
Assets:Brokerage 0.001 BAR @ $124.95
Assets:Brokerage

$ ledger --cost -X USD bal
$123.42 Assets:Brokerage
$-123.45 Equity:Opening Balances
--------------------
$-0.03

In the current release, I think it would be zero, because rounding only
happens once.

[John Wiegley]

At least at first glance, I would expect this although. All math is intended
to be done in a domain of infinite precision, with rounding only happening on
display, or when the “displayed value” has significance (like checking a
balance assertion statement).

John