Looks like my altered check for the indices of exp doesn't work with some preexisting test cases. I'll look into it and fix.

Codecov Report

❌ Patch coverage is 91.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.02%. Comparing base (93300cb) to head (09371e7).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #1661      +/-   ##
==========================================
+ Coverage   81.01%   81.02%   +0.01%     
==========================================
  Files          59       59              
  Lines        4629     4638       +9     
==========================================
+ Hits         3750     3758       +8     
- Misses        879      880       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Updated this PR today with a slight rewrite that takes the ordering of the input indices (to exp) more literally. So a valid input would be:
exp(A, (s1',s2'), (dag(s1),dag(s2)))
but not
exp(A, (s1',s2'), (dag(s2),dag(s1)))
since in the second line of code the indices are not correctly "paired".
(Also technically the calls to dag above aren't needed, and will effectively be figured out by the exp function.)

I have a PR ready along similar lines for the map_eigvals function in ITensorNetworks.ITensorsExtensions but I will wait on that until this one is merged, so I can mimic any changes over the that one.

Updated this PR today with a slight rewrite that takes the ordering of the input indices (to exp) more literally. So a valid input would be: exp(A, (s1',s2'), (dag(s1),dag(s2))) but not exp(A, (s1',s2'), (dag(s2),dag(s1))) since in the second line of code the indices are not correctly "paired". (Also technically the calls to dag above aren't needed, and will effectively be figured out by the exp function.)

Just to clarify, a user can input exp(A, (s1',s2'), (dag(s2),dag(s1))) if they want to, but the inputs will be taken literally, correct? That could be a way to exponentiate an operator where the sites on one side are swapped.

Good question. Yes if s1 and s2 happen to be "swappable" meaning they have identical spaces, just different ids and possibly different tags, then that input is allowed and should do the right thing mathematically. I think it would be equivalent to performing a 'swap gate' on one side of the tensor and then exponentiating the resulting tensor.

In practice, if the inputted tensor is Hermitian in the more natural (s1',s2'), (dag(s1), dag(s2)) pairing (so s1' paired with dag(s1), s2' paired with dag(s2)) then I believe the other input will ruin the Hermitian property so it might be a more sketchy case for exp if we are relying on a Hermitian assumption in any lower-level code.

I mention that Hermitian case because exp should be ok, specifically, but for a case like sqrt which is done with similar but slightly generalized code over in ITensorNetworks.ITensorsExtensions, one might not like the result of swapping those indices because the diagonal elements when using eigendecomp will generally have mixed signs, so then sqrt will output complex numbers etc.

One potentially confusing thing about the current interface is that while a correct ordering of the input indices is (s1', s2'), (dag(s1),dag(s2)) (correct meaning an input that would give the exp of A interpreted as an operator without any swaps) the actual ordering that would be used in that case internally (assuming dir(s1)==dir(s2)==Out) is (s1',s2'),(dag(s2),dag(s1)). This is because that second ordering of the indices is the one where e.g. squaring the tensor as an operator (in the apply sense) does not incur any line crossings / permutations or arrow signs.

I just mention that because users should be careful to understand that the input to exp denotes a kind of pairing of indices, not a kind of model for some "best" or "reference" or "canonical" index ordering of the tensor that will be used during the actual exp operation internally.

Thanks for the clarification, all of that makes sense.

This looks reasonable to me, ready to merge?