Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the default interface be transform! and itransform!? #52

Closed
MikaelSlevinsky opened this issue Sep 5, 2018 · 3 comments
Closed
Labels

Comments

@MikaelSlevinsky
Copy link
Member

This would mirror the current ApproxFun transforms interface, and could help avoiding issues with converting At_mul_B!(Y,A,X) overrides to mul!(Y,A',X). (I could be wrong, but it's not clear to me that the authors were aware of how this change in Base could affect packages that use recursive linear algebra data structures.) @dlfivefifty, thoughts?

@dlfivefifty
Copy link
Member

dlfivefifty commented Sep 6, 2018

Are we happy with ApproxFun's interface? I think embracing types even more would be better: I like Transform.

I don't see how there are any issues with A' and recursive data structures, as its a lazy adjoint so doesn't do anything besides wrap A in another type.

Note: I think it's agreed that P*x being in-place is not ideal and should be lmul! (JuliaMath/FFTW.jl#77).

I think this package could definitely use some structure. One option would be to make ApproxFun's spaces "lightweight" and then the interface for in-place would be:

lmul!(Transform(Jacobi(a,b), Jacobi(c,d)), x) 

the out-of-place would be:

Transform(Jacobi(a,b), Jacobi(c,d)) * x

and the inverses would be

ldiv!(Transform(Jacobi(a,b), Jacobi(c,d)), x)
Transform(Jacobi(a,b), Jacobi(c,d)) \  x

Or possibly lazy inv(::Transform).

@MikaelSlevinsky
Copy link
Member Author

Is it not true that in the new paradigm, if A is conceptually equal to [A11 A12; A21 A22], then mul!(y, A', x) would want to create four more light types each representing the adjoint of the subblock?

I think P*x being in- or out-of-place is a question of convention. Do any transforms in this package function like this? (The FastTransforms C library does, because I think it's more efficient for the C plans to have their own personal aligned workspace to copy into and out of. But then it's a C-to-Julia wrapping issue.)

@dlfivefifty
Copy link
Member

No that's not true:A' isa Adjoint{eltype(A), typeof(A)}.

I don't like P*x being in-place because it abuses the notion of multiplication. Note it's easy to make both in-place and out-of-place work:

*(T::MyInplaceTransform, x) = lmul!(T, copy(x))
lmul!(T::MyOutofplaceTransform, x) = (x .= T*x)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants