That's what I was thinking. I opened an issue as you suggested
to discuss this.
Davide Pittet
On Mon, Apr 8, 2024 at 8:46 PM Aaron Meurer wrote:
> 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
>
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 wrote:
>
> I think that the
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
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
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
