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

Stashing user variable(s) in a LinearMap struct? #53

Closed
JeffFessler opened this issue Jul 30, 2019 · 3 comments
Closed

Stashing user variable(s) in a LinearMap struct? #53

JeffFessler opened this issue Jul 30, 2019 · 3 comments

Comments

@JeffFessler
Copy link
Member

#52 involves stashing some quantities in the BlockMap struct, which reminds me of a feature request that I have been thinking about for a while.
In many applications, a LinearMap corresponds to some physical system that has attributes that went into the definition of the map. It would be convenient to allow the user to provide a single variable (e.g., a NamedTuple or a struct) that would be stashed in the LinearMap struct so that the user can access it later. Something like this
L = LinearMap(f, fa, M, N, user=(density=0.5, temperature=100))
then later the user could retrieve those values via something like L.density
or L.user.density
It would be pretty easy to do with Base.getproperty I think.
If there is willingness to consider such an enhancement I might give it a try.

@dkarrasch
Copy link
Member

That sounds good to me, in principle, but the devil is in the details, as always. Since there is no inheritance of properties/fields, one would have to introduce that for all concrete types of the abstract type LinearMap; what you have above covers only the FunctionMap type. You can find some inspiration with the issymmetric and ishermitian fields in wrappedmap.jl. Also, I think this should certainly be non-breaking.

Have you tried to build your own struct in your own package(s)? Something like

struct NamedLinearMap{T, A<:LinearMap, At<:Union{Nothing,NamedTuple}}
    lmap::A
    attribute::At
end

and then, for a L::NamedLinearMap redirect typical linalg functions to L.lmap? Then you would get all core functionality for free. Actually, I wonder what you would do when you add two NamedLinearMaps with different attributes, or when you multiply them? I imagine finding a generic default here will be difficult, so you may actually wish to experiment with that outside of LinearMaps.jl, but in your concrete context first. I mean without the ambition to find generic solutions, but something that suits your specific needs.

@JeffFessler
Copy link
Member Author

Thanks for the great feedback. Once again the type issues will be the challenge for me...
I'll let you know if I follow through on this.
I like the wrapper you suggest. That might let me do some other things I like such as getindex :)

@JeffFessler
Copy link
Member Author

In case anyone else wants to store user variables in a LinearMap I have done that in this simple overlay package:
https://github.com/JeffFessler/LinearMapsAA.jl
Daniel's suggestion above was super helpful for getting me started on this.
I did it with more generic typing both for simplicity and to allow support for setindex! but my (limited) timing tests did not show any drawback, probably because all the multiplies are done under the hood by LinearMaps and you guys did the heavy lifting there to make those efficient.
The properties are not propagated when combining objects with add or hvcat etc.

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

No branches or pull requests

2 participants