Diffgeom needs some major rethinking

[Davide Pittet]

Hello everyone,

following up the discussion on GitHub related to the WedgeProduct bug, I started exploring the code around the implementation of wedge and tensor products. I think there are deep problems with the way tensor products (but not only) are implemented in the diffgeom submodule. 

I would like to address these issues, but it would be my first contribution and I do not think it will be a simple task. I have a good knowledge of the theoretical field as my MSc thesis applied differential geometry to particle physics and I would like to help, but I would surely appreciate some guidance with the code, primarely on the direction we want to follow.

Davide Pittet

[Aaron Meurer]

Your contributions are definitely welcome, although it would be a good
idea to first lay out exactly what changes you want to make, either
here or on an issue. If any of the changes are controversial, or would
break the current API, we should iron them out before you potentially
waste a lot of time coding them.

If there's any changes you want to make that aren't potentially
controversial, like bugfixes, you don't need to open issues for them
first.

Aaron Meurer

> --
> 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 sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/f480cb78-3741-484a-bc32-1535cbab177bn%40googlegroups.com.

[Davide Pittet]

I think that the main problem is that we "delegate" the sum of tensors to the Add class, allowing to sum apples with pears; e.g. we can create an object that is the sum of a vector and a covector like e_x + dx, when they really belong to different spaces, without getting an error. This reflects in cascade to the whole submodule: the sum of two tensor products is a tensor and should be treated as such, not as a generic Add instance, because there are constraints that are not taken into account; extending the previous example, we cannot sum TensorProduct(e_x, dx) with TensorProduct(dx, e_:x). 

Then, we have to implement the associativity of the tensor product and the distributivity of the tensor product wrt the sum.

Once this is fixed we have to put a constraint on the number and the type of the arguments of the __call__ method and this should solve the problems pointed out on GitHub.

Davide Pittet

[Aaron Meurer]

I would open an issue to discuss this, if you haven't already. These
sorts of issues relating to what Add class is used to represent sums
generally end up being pretty tricky and involve a lot of subtleties.

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5ea6ca99-0cc9-4190-8817-c8ba5da1a9a8n%40googlegroups.com.

[Davide Pittet]

That's what I was thinking. I opened an issue as you suggested to discuss this.

Davide Pittet

You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/sIxP_dfq6dE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sympy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L5fEWMYe%2BG_rRNpUFRsxjZ3UVsxpdCC%3Dze_BWUCsiRoA%40mail.gmail.com.