on non-standard infix operators

[ExpandingMan]

Hi, thanks for all your work on this very impressive package.

I was wondering if you would ever be willing to re-consider the use of infix operators in this package. In particular, the use of * and $\cdot$ are incompatible with the conventions of all other AbstractArray. You cannot, for example, replace an SMatrix with a Mat and have matrix multiplication still work. While I understand that the Tensor objects in this package are more general than StaticArrays and one is certainly not a drop-in replacement for the other, I nevertheless think it would go a long way to making this package more useful in the wider Julia ecosystem. Similarly, I have only ever seen $\cdot$ used as an inner product (i.e. having codomain $\mathbb{R}$), so I would expect $A \cdot B = \textrm{tr}(A^\dagger B)$ before simple matrix multplication.

I know this is a huge suggestion that might imply a lot of work, but I thought it worth mentioning as I very much doubt I am the only one who would hesitate to use this particularly because of differences in convention not only with StaticArrays but with AbstractArray types more generally.

[KeitaNakamura]

Hi, thanks for your suggesting and giving a star.

This package is mainly developed for the field of continuum mechanics. A similar package is Tensors.jl, while Tensorial.jl can handle the arbitrary size of tensor. Maybe I should change the description of this package so that people can know the package focuses on continuum mechanics. So, $A \cdot B$ means the single contraction and is exactly the same operation as simple multiplication if both $A$ and $B$ are matrices.

I'm not sure that this package is as useful for general usage as StaticArrays.jl because the key features of this package, such as symmetric tensors, contractions, tensor product, etc., seems to be beneficial in continuum mechanics. For example, the multiplication between two symmetric matrices $A_{ik} B_{kj}$ becomes a non-symmetric matrix, and thus there is no benefit to considering symmetries. On the other hand, if we use the fourth-order symmetric tensor $C_{ijkl}$ where $(i,j)$ and $(k,l)$ have symmetry, which is often used in continuum mechanics, $C_{ijkl} A_{kl}$ becomes a symmetric tensor. In this case, considering and eliminating calculations for symmetric indices speeds up the calculation.

So, in answer to your question, if there are significant advantages to using this package over StaticArrays.jl in general usage, yes, I will reconsider the definitions of the infix operators. May I ask which aspect of this package you find particularly useful in your case?

[ExpandingMan]

I was interested in perhaps using it for differential geometry. One of the most obvious advantages of this package is what looks like extensive support for symmetry properties, something (almost) totally absent from the array libraries (though it doesn't seem there is anti-symmetry, is that right?). This package also seems to define many more convenient operations for tensors than are available directly with StaticArrays which would require shenanigans with tullio in that case (even if some of the notation looks very strange for someone from GR, diff-geo world).

I'm not sure that this package is as useful for general usage as StaticArrays.jl because the key features of this package, such as symmetric tensors, contractions, tensor product, etc., seems to be beneficial in computational mechanics.

So yes, in my case much of this stuff is still very useful. I have not done extensive performance comparisons but on initial observation this looks like quite a solid package.

Anyway, I understand your not being interested in making extensive changes because some random guy on github claims your conventions are weird. I would merely encourage you to keep in mind that it may have more general applicability and I suspect there are a good number of people around the julia community who would be more interested in it were it more well known. Again, looks quite nice, compliments.

I may at some point use this package as inspiration to write something similar more specifically focused on differential geometry. One of the things I considered was making it a requirement that all indices have the same dimension which would be a massive simplification for the type system relative to both this and StaticArrays (although it could rule out some use cases of mixed representations like spinors).

[KeitaNakamura]

Sorry, maybe I gave the wrong impression. I'm actually fine with changing codes if it is useful in different fields. I just didn't know that, and my world was too small.

In my work, I often use single and double contractions, so I want to keep that usage. It can be resolved by defining the contraction operator with a different symbol. But to maintain compatibility with StaticArrays.jl, we need to restore the definition of the multiplication *. In this case, the use of * and the contraction operator both exist, leading to some confusion.

As for anti-symmetry, yes, I had implemented it before but decided not to include it and to keep the code simple because I could not come up with a situation where handling a skew-symmetric matrix would be effective for performance.