Question: Co(ntra)variance, coordinates and pullbacks

[EricForgy]

Hi,

This seems like a cool package and the benchmarks blow me away. How can it be that much faster? :)

Anyway, I am looking into doing some research (still early stages) and am considering whether to use and contribute to this package, try to roll my own package from scratch or use this package as a basis for a new package. Or maybe there is another package more suitable for what I'm looking for?

From my personal perspective, the point of tensors is that they are coordinate independent and metric independent multilinear objects defined on smooth manifolds with both covariant (lower indices) and contravariant (upper indices) components. For example, a matrix is a once covariant and once contravariant tensor, vectors are once contravariant and covectors are once covariant. So the order of a tensor should not be a single integer, but something more like a tuple of booleans or something, e.g.

# v::Vector v^u
iscovariant(v) = (false,)
iscovariant(v') = (true,)
# m::Matrix m^u_v
iscovariant(m) = (false,true)
iscovariant(m') = (false,true)
 # t::Tensor T_{uv}^w
iscovariant(t) = (true,true,false)

I wish there was some way to express a tensor as a multilinear object on a smooth manifold without resorting to coordinates, but it is not obvious to me how to do that. So this package apparently starts by assuming a coordinate system and then encodes the tensor into an array of numbers. That makes sense and is fine, but I think that choice should probably be made more explicit. If you assume all tensors are Cartesian tensors with Euclidean metric then raising and lowering indices are trivial and the paragraph above is moot. If this package is intended to support only Cartesian tensors, that would be perfectly fine, of course, but maybe then it should be called CartesianTensors.jl or at least the README should make that clear?

Is there any desire to support mixed tensors with this package?

Also, since tensors are represented as numbers in an array implying a chosen coordinate system, I think the chosen coordinate system should be part of the tensor definition. For example, you cannot add a tensor expressed in Cartesian coordinates to a tensor expressed in spherical coordinates without first transforming them to the same coordinate system.

It would be nice if a tensor package (this one or maybe one built on top of this one) had a concept of coordinate system, e.g. Coordinates then we could incorporate that into the definition of the tensor, probably as a parameter, Tensor{order,dim,T,coord}.

Finally, one of the most important concepts involving tensors is pullback / pushforward, which generalize coordinate transforms to maps between different spaces.

Given smooth manifolds M and N, a smooth map F: M -> N, a covector a on N and a vector v on M, it would be great if we could express something like

<F^*(a),v> = <a,F_*(v)>

or in pseudocode

pullback(a)(v) == a(pushforward(v))

Anyway, these are the kinds of things I think about and would hope to have in a tensor package. Do you have any thoughts? Is there anything above that should / could be incorporated into this package? Would it be better to leave this package as it is and build another package on top that has things like mixed tensors, coordinate maps, pullback / pushforward? Or do something completely different?

Having said all that, I'd like to end by saying that if you are dealing with Cartesian tensors, this package seems fantastic and it is clear that a lot of thought has gone into performance 🙌

[dkarrasch]

That's a fantastic proposal. I don't think, however, that there is some "Euclidean tensor" assumption behind the scenes. It's just assumed that you have some (consistent) coordinate representation of the objects involved, and then you compute tensor contractions. Tensor contraction (without changes of coordinates) is independent from co(ntra)variant transformation behavior, so covariance only hits you when you want/need to transform your tensors and (co)vectors. But tensor transformation is again nothing but iterated tensor contraction, so that is not leaving the framework provided here. So I think that "all" that is required is additional structure on top of what exists here, be it in this or an independent package. What I mean by this is some structure wrapping tensors as provided here, and adding more metainformation. I don't think there is need to hardwire this with the Tensors here.

I was working on related stuff, but got stuck on how to formalize coordinate systems and changes of coordinates (and induced changes in the bases of (co)tangent/tensor spaces). There may be something out in the ecosystem, actually.