-
Notifications
You must be signed in to change notification settings - Fork 106
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
Add product of spaces #859
Comments
How about >>> space = odl.uniform_discr(0, 1, 100)
>>> space ** 3
uniform_discr([0.0, 0.0, 0.0], [1.0, 1.0, 1.0], (100, 100, 100)) ? |
Well your suggestion is strictly different from mine and frankly doesn't really make sense in how you usually write notation. You are taking the power as a power of a domain, while I take it as a power of the range. Your suggestion is hence not compatible with this suggestion, since it has no obvious equivalent in the case of non- Example, my proposal: >>> space = odl.uniform_discr(0, 1, 100)
>>> (space ** 3)[0]
uniform_discr(0, 1, 100) your proposal would, if it is to be consistent with slicing, give >>> space = odl.uniform_discr(0, 1, 100)
>>> (space ** 3)[0]
uniform_discr([0, 0], [1, 1], [100, 100]) Mathematically it doesn't make much sense either. If I write F({1, 2, 3}, R) to mean the set of functions from {1, 2, 3} to R, then F({1, 2, 3}, R)^2 should be the set of ordered 2-tuples of such functions. I.e.
this can be identified with
but doesn't have an isomorphism to what you propose, i.e.
|
Oh never mind, what I wrote was obviously BS. That kind of stuff would only work for tensor spaces, where you would add a 3 to the shape on the left, obviously not adding 2 axes as I wrote above. |
Well what you wrote could be given the syntax >>> space = odl.uniform_discr(0, 1, 100)
>>> 3 ** space
uniform_discr([0.0, 0.0, 0.0], [1.0, 1.0, 1.0], (100, 100, 100)) which I think would make sense? |
Haha, not quite sure about that.. I just know |
A rather obvious syntax that we have not started using is the product of spaces, i.e. one could easily envision
sub-classes could then overload this syntax to provide more advanced storage and functionality, i.e. in #857.
The text was updated successfully, but these errors were encountered: