So, what I'm thinking is that I take the current Tensor classes, switch them over so that they are TensorSymbol (analagous to MatrixSymbol) and add a more concrete tensor class, and also expression classes for those, including tensor product. This results in things like physics vectors and dyads, GA vectors and multivectors, and diffgeom differentials and tensor products and so on being straight up instances of our tensor expressions, except perhaps with different component types.
However, we would like to have other classes as well, like matrix or geometric vectors, since they would have abilities that general tensors would not, and it would also help with backwards compatibility. So I can add a dispatch system like Franz Bonazzi is suggesting to deal with that. This would also allow better interop between the GA module and the physics module for instance, and can be written generally enough to be used throughout sympy for other such large groups as tensors. On Mon, Mar 10, 2014 at 2:44 AM, F. B. <[email protected]> wrote: > > > On Saturday, March 8, 2014 4:23:50 AM UTC+1, Matthew wrote: >> >> I do like the idea of dispatch. I'm not sure that I understand the rest >> though. Maybe I need a more explicit example. We'll probably have to >> convert back at some point. >> >> > As soon as there is multiple dispatch, an approach similar to this one > could be devised: > http://julia.readthedocs.org/en/latest/manual/conversion-and-promotion/ > > For me an example of shared functionality might be indexing. Many matrix >> expressions can be reduced to indexed expressions. Operations like matrix >> multiply could be written more generally as contractions. These >> contractions might mean something very different on a Matrix, a >> MatrixExpression, or a Tensor* but we might be able to find simplifications >> that are common to all. >> > > Tensors defined in *sympy.tensor.tensor* do not define components by > default, they only store index-types, index-symmetries and commutation > symmetries of tensors. The only common feature with n-dimensional arrays is > the number of indices. I think that the shared common feature would then be > just the number of indices, unless you're willing to create a structure > with many optional features. > > I would not concentrate the efforts on a tensor core, rather a system of > easiness of conversion/promotion of types would be more beneficial. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/b16e45b1-85de-4033-bb67-e0547142559c%40googlegroups.com<https://groups.google.com/d/msgid/sympy/b16e45b1-85de-4033-bb67-e0547142559c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAG9O3hQzgPbGuFJCsx4Y5T%2BQ%2BjHJLsoEh%2BdMYJbKixivMX9-Ag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
