sympy.diffgeom and Add class

[davidepittet]

Following the post I wrote in the mailing list, I open this issue to discuss some problems I found in the sympy.diffgeom subclass.

As I explained there, it all started from the previous issue on the "WedgeProduct giving wrong output". I started exploring the code around WedgeProduct and TensorProduct, and I found out there is a series of problems that are all more or less related to how we sum objects (tensor products, but also simple vector fields).

For simplicity, I paste here what I wrote previously on the mailing list to explain what I think are the main points:

"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."

As suggested, I open this issue to discuss a potential line of work to fix these problems.

[asmeurer]

We should be able to use a similar method to the one used for shape checks in the matrix expressions to add type checking for tensors in Add.

[davidepittet]

Ok, I will look into it and try to come up with a solution