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 On Mon, Apr 8, 2024 at 12:33 PM Davide Pittet <[email protected]> wrote: > > 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 > > Il giorno lunedì 8 aprile 2024 alle 10:06:46 UTC+2 [email protected] ha > scritto: >> >> 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 >> >> On Sun, Apr 7, 2024 at 2:02 PM Davide Pittet <[email protected]> wrote: >> > >> > 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 >> > >> > >> > -- >> > 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 view this discussion on the web visit >> > https://groups.google.com/d/msgid/sympy/f480cb78-3741-484a-bc32-1535cbab177bn%40googlegroups.com. > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/5ea6ca99-0cc9-4190-8817-c8ba5da1a9a8n%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L5fEWMYe%2BG_rRNpUFRsxjZ3UVsxpdCC%3Dze_BWUCsiRoA%40mail.gmail.com.
