fix: exponential method ambiguity resolutions

[sanderdemeyer]

This is another type restriction (see #252) to make sure the exponential in TensorKit will be implemented correctly (see QuantumKitHub/TensorKit.jl#465). If I don't restrict these types, it will be ambiguous with this function in TensorKit (src/factorizations/matrixalgebrakit.jl).

for f! in (
        :qr_null!, :lq_null!,
        :svd_vals!, :eig_vals!, :eigh_vals!,
        :project_hermitian!, :project_antihermitian!, :project_isometric!,
        :exponential!,
    )
    @eval function MAK.$f!(t::AbstractTensorMap, N, alg::AbstractAlgorithm)
        $(f! in (:eig_vals!, :eigh_vals!, :project_hermitian!, :project_antihermitian!) && :(LinearAlgebra.checksquare(t)))
        foreachblock(t, N) do _, (tblock, Nblock)
            Nblock′ = $f!(tblock, Nblock, alg)
            # deal with the case where the output is not the same as the input
            Nblock === Nblock′ || copy!(Nblock, Nblock′)
            return nothing
        end
        return N
    end
end

[lkdvos]

Did a quick search throughout the codebase, and it seems like except for svd_compact, we always combine DiagonalAlgorithm with AbstractMatrix, so this is consistent with most of it.

[codecov]

Codecov Report

❌ Patch coverage is 63.15789% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/implementations/exponential.jl	75.00%	4 Missing ⚠️
src/interface/exponential.jl	0.00%	3 Missing ⚠️

Files with missing lines	Coverage Δ
src/interface/exponential.jl	0.00% <0.00%> (ø)
src/implementations/exponential.jl	94.52% <75.00%> (-5.48%)	⬇️

... and 23 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[Jutho]

There are still ambiguities currently. Also, I do think the current these specializations invalidate some of the discussions we had previously, e.g. regarding map_diagonal vs broadcasting.

[sanderdemeyer]

These ambiguities should now be removed. It is indeed a bit strange that we're specialising these methods, when we indeed wanted to keep them general and not use broadcasting. I think it was probably still the right choice, even if we restrict some of the methods here.

[lkdvos]

I made a slight change to the implementation to remain consistent with the decompositions - we are now never specializing the out arguments, and only using input::AbstractMatrix. I'm not saying this is really the best solution, and I agree that it is unfortunate we can't (yet?) handle this in a more satisfactory way, but barring the option to actually fully solve this right now, which I think will take a substantial refactor, I would vote to just keep this consistent with the decompositions, where this problem is also present.