Codecov Report

✅ All modified and coverable lines are covered by tests.

... and 23 files with indirect coverage changes

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

So, it turns out that I made a mistake in simply replacing the entire call with add_braid!, since that is not actually equivalent to transpose + artin_braid, which is what the BraidingTensor is supposed to do.
This caused me a lot of painful debugging, but I think I now figured it out :).

I know that we could still consider merging this by writing a new fusiontree manipulation that does this, but unless this is really showing up in the profiler I would argue that it is fine to leave this as is for now.

Failures are unrelated (still the MatrixAlgebraKit issues), so will merge this as-is.

So, it turns out that I made a mistake in simply replacing the entire call with add_braid!, since that is not actually equivalent to transpose + artin_braid, which is what the BraidingTensor is supposed to do. This caused me a lot of painful debugging, but I think I now figured it out :).

I should have known this. I had some hunch while reviewing that something might be off, and was looking for the effect of the final pAB permutation, but then I stopped worrying about it and assumed that it would be fine, with the permutation really only doing the swap and therefore add_braid! being the right primitive. But indeed, it is not.

Yeah, it is very confusing since the @planar macro actually only generates calls where the pAB turns out to be trivial, which is why I somehow assumed it would be fine.
I at least put in some comments to prevent me (and anyone else in the future) from making the same mistake again :)