-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
Are we happy with ApproxFun's interface? I think embracing types even more would be better: I like I don't see how there are any issues with Note: I think it's agreed that 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 |
Is it not true that in the new paradigm, if I think |
No that's not true: I don't like *(T::MyInplaceTransform, x) = lmul!(T, copy(x))
lmul!(T::MyOutofplaceTransform, x) = (x .= T*x) |
This would mirror the current
ApproxFun
transforms interface, and could help avoiding issues with convertingAt_mul_B!(Y,A,X)
overrides tomul!(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?The text was updated successfully, but these errors were encountered: