Power spaces and tensors

[kohr-h]

Another question pops up with respect to tensors in #738: How to represent power spaces?

One possibility for TensorSpace based power spaces is to just make a new such space with new leading dimension(s) added. That would greatly simplify a number of implementations (like PointwiseSum, becomes a one-liner basically) and allow for powers of arbitrary dimensions.

But for general spaces we may want to keep the "lazy" power space approach that allows any sequence of identical spaces.
The downside of this "legacy" support is the burden on implementers of new functionality on power spaces. It will either be a lot of work to make it work for the "lazy" spaces or support for them will simply be lacking, which is not really good.

I guess the real question is whether or not power spaces of arbitrary spaces that are not TensorSpace based are of big importance and whether or not they should be supported by every vector or tensor field code to be written.

Opinions?

[adler-j]

I am against limiting the functionality of the current ProductSpace, since it provides a very general functionality that can by used with arbitrary spaces with very little requirements on them. It also has the upside of being able to wrap smaller spaces in place, i.e. you can make a ProductSpace of some subspace, use it to call something and then "unwrap it" easily without causing unnecessary copies.

What I would do as of now is start with adding a power space equivalent inside DiscreteLp since that will be needed anyhow and it's how we should do these spaces in the long run. When that is done, we can consider if we want to migrate the PointwiseSum family or keep it as is.

[kohr-h]

I am against limiting the functionality of the current ProductSpace, since it provides a very general functionality that can by used with arbitrary spaces with very little requirements on them. It also has the upside of being able to wrap smaller spaces in place, i.e. you can make a ProductSpace of some subspace, use it to call something and then "unwrap it" easily without causing unnecessary copies.

Well I was specifically talking about power spaces, where you don't combine arbitrary spaces. Any time you have a DiscreteLp and take a power space thereof, you end up with a space that is isomorphic to another DiscreteLp with extended shape. Natural candidates for that would be tangent_bundle or in general powers of spaces. For that it would actually make sense to overload **, using constructs like space ** (2, 3) or similar.

I'm trying to think about a situation where it would be better to use a ProductSpace(space, n) over the (suggested) space ** n construct with contiguous memory. Do we have a use case where the latter would give us extra copies?

What I would do as of now is start with adding a power space equivalent inside DiscreteLp since that will be needed anyhow and it's how we should do these spaces in the long run. When that is done, we can consider if we want to migrate the PointwiseSum family or keep it as is.

The infrastructure in DiscreteLp is already there, just lacking the power space thing.

[adler-j]

Well I was specifically talking about power spaces, where you don't combine arbitrary spaces. Any time you have a DiscreteLp and take a power space thereof, you end up with a space that is isomorphic to another DiscreteLp with extended shape.

Mathematically yes, programming wise no. Storage is notably different.

Natural candidates for that would be tangent_bundle or in general powers of spaces. For that it would actually make sense to overload **, using constructs like space ** (2, 3) or similar.

Power syntax looks cool, I like it.

I'm trying to think about a situation where it would be better to use a ProductSpace(space, n) over the (suggested) space ** n construct with contiguous memory. Do we have a use case where the latter would give us extra copies?

Anytime you want to wrap something. Can't think of an acute case right now but I'm sure there are cases. Also ofc in cases where you do not have access to the full machinery (i.e. if someone implemented a mpi_rn space and didn't want to do everything).

The infrastructure in DiscreteLp is already there, just lacking the power space thing.

Well that is no minor task, we need to explicitly handle the "semi-discretized" case. I.e how to represent it, etc.

My suggestion

• Leave the productspace with related notions as is, don't change anything.
• Implement discretized vector lp spaces.
• Add space ** (2, 3) syntax as you suggested, which returns a new discretized vector space.
• Ensure that Pointwise... work with both ProductSpace and discretized vector spaces, for now. We can drop support later if it is not used.
• Modify the code to use discretized vector spaces where appropriate.

[kohr-h]

Decent suggestion, I agree we shouldn't drop support for the "old way" easily.

[kohr-h]

This has no immediate TODO, and the discussion is settled. Closing.