RFC: Introduce AdjointRotation to avoid subtyping AbsMat#46233
RFC: Introduce AdjointRotation to avoid subtyping AbsMat#46233
AdjointRotation to avoid subtyping AbsMat#46233Conversation
|
@nanosoldier |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
|
@nanosoldier |
|
Shall we consider this? I'll try to run the tests once again, since earlier issues have been resolved meanwhile, I believe. @nanosoldier |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
|
The deprecated ITensorsGaussianMP.jl fails, but its up-to-date version in ITensors.jl seems to pass. Let's look at that specifically. I wonder why ITensors.Circuit actually subtypes @nanosoldier |
|
Your package evaluation job has completed - no new issues were detected. A full report can be found here. |
|
Since, after all, this doesn't seem to break any code, I'll merge in a few days if no objections arise. This part of the code seems to be mainly used as a blackbox, without any extensions/overloads/etc. (with ITensors.jl the only exception, which in turn doesn't use any fallback definitions but instead provides all required functions itself). @emstoudenmire @mtfishman @kshyatt |
This is the analogue to #46196 for
AbstractRotation. It is somewhat weird thatAdjoint{<:Any,<:NOTAbstractMatrix}still subtypes toAbstractMatrix, which introduces many ambiguities. Typically, non-matrices like Q's and rotations should have preference over any AbstractMatrix in multiplication. That is, no matter how structured/sparse the other factor is, the q-multiplication code or the rotation-code should apply, not the other way around. Technically, this is again breaking, but I expect even less friction than in #46196.