You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, A'x where A::Toeplitz falls back onto a generic and slow method. By defining
function LinearAlgebra.Adjoint(A::Toeplitz{T}) where T
At =Toeplitz(A.vr, A.vc)
end
the problem is mitigated and the optimized method for mul! is used. Still, if A'x occurs in a loop, the initialization of the Toeplitz object occurs each iteration, which is suboptimal since it performs some allocations and plans an FFT etc. Ideas on how to solve the problem in general is appreciated.
In the meantime, would you be up for a PR that adds the definition above?
The text was updated successfully, but these errors were encountered:
Sounds great! Though you should never overload a type constructor (Adjoint) to return a different type, unless you really have good reasons: it is confusing for users. Instead, overload the function adjoint.
Note if a user is worried about A' being expansive, they can move that out of the loop.
Down the line, this package may move to a trait-based setup using ArrayLayouts.jl, (as BandedMatrices.jl and BlockArrays.jl have). This would allow Adjoint(Toeplitz(A.vr, A.vc)) to conform to a ToeplitzLayout interface. Though that's a ways off from materialising.
Currently,
A'x
whereA::Toeplitz
falls back onto a generic and slow method. By definingthe problem is mitigated and the optimized method for
mul!
is used. Still, ifA'x
occurs in a loop, the initialization of theToeplitz
object occurs each iteration, which is suboptimal since it performs some allocations and plans an FFT etc. Ideas on how to solve the problem in general is appreciated.In the meantime, would you be up for a PR that adds the definition above?
The text was updated successfully, but these errors were encountered: