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

Multidimensional product spaces #157

Closed
kohr-h opened this issue Dec 13, 2015 · 4 comments
Closed

Multidimensional product spaces #157

kohr-h opened this issue Dec 13, 2015 · 4 comments

Comments

@kohr-h
Copy link
Member

kohr-h commented Dec 13, 2015

Not a must-have, but certainly nice: a way to produce product spaces which are more than one-dimensional, i.e. the factors are stored in a multidimensional array rather than a list. With all the connected questions of norms, inner products etc.

We could follow a similar approach as in the case of FnBase vs. DiscreteLp: make the underlying storage linear (e.g. a NumPy array with dtype=object) and reshape to higher dimensions only on demand by some generalized Discretization class.

Of course, this will give a substantial speed penalty for a large number of member spaces compared to the situation where we have a discretization of a single large space, but I think we're going to need something like this in the long run, see e.g. #156.

@adler-j
Copy link
Member

adler-j commented Dec 14, 2015

There is a age old issue on this on the old github.

A trivial way to do this is to implement this recursively, something like

>>> space1 = odl.ProductSpace(odl.Rn(3), [2, 2])
>>> space2 = odl.ProductSpace(odl.ProductSpace(odl.Rn(3), 2), 2)
>>> space1 == space2
True

@kohr-h
Copy link
Member Author

kohr-h commented Dec 14, 2015

As long as we don't need anything else than our good old weighted p-norms, this should be working. More thoughts necessary for more complicated things.

@kohr-h
Copy link
Member Author

kohr-h commented Jan 23, 2017

For power spaces, this will be trivial with #857. For the general case, I guess as long as there's no real need for it we don't do it?

@adler-j
Copy link
Member

adler-j commented Jan 24, 2017

I agree. #857 solves the most common use cases and in other cases it's just a matter of somewhat clunky syntax that we can live with.

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

No branches or pull requests

2 participants