-
Notifications
You must be signed in to change notification settings - Fork 7
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
How to handle Linear operators / functionals? #112
Comments
The reason we like having (ε*D^2 + x .* D + I) * T In theory an option is to no longer support this and force users to do ε*diff(diff(T;dims=1); dims=1) + x .* diff(T; dims=1) + T |
I would be very unhappy with version (2), not least because I would have to rewrite a lot of code, but also because I feel it is much uglier. I guess supporting this as an alternative is fine. How would you apply the transpose of an operator this way? |
Right that wasn't really a serious proposition. But we should support at minimum both |
My use case is usually |
At the moment we have the following setup for linear operators / functionals that are not built out of elementary operations, where
f isa AbstractQuasiVector
andT isa AbstractQuasiMatrix
:Derivative(x) * f
andDerivative(x) * T
sum(f)
andsum(T; dims=1)
As we consider other linear operators such as
cumsum
it might be a good idea to see how to make this consistentVersion (2) is in some sense "canonical" as it exists in Base. So the question is what to do with Version (1). We could have something like
How this relates to axes-free alternatives is another question: #22
The text was updated successfully, but these errors were encountered: