Eric Wieser

> it is simply that `aa` That directly contradicts the screenshot I took above from GA4CS, you need to apply grade reversion too

@chakravala, I assume then that `your_lc == ga4cs_lc`, but `your_rc(a, b) == ga4cs_rc(a.rev(), b.rev()).rev()`? Or do neither of them align? @enkimute, it might be worth putting a comparison of contraction...

At this point I suggest we continue this conversation at the Grassman.jl repository. The intent of this issue was to flag a potentially dangerous use of python operator overload semantics,...

Reopening because I have an answer - they're not safe, we need to change them: ```python >>> from galgebra.ga import Ga >>> from sympy import S >>> g, e1, e2,...

Turns out that bug is not relevant. However, our current design means that we cannot cooperatively dispatch the contraction methods, unlike all the other multiplication methods that can return `NotImplemented`:...

Just commenting to note that the above code still works in 0.5.0. The rest of the puzzle is something like ```python from galgebra import metric ga = ... lookup =...

Are you referring to this latex printing? https://github.com/pygae/galgebra/blob/94a5f65d6dbf8176637eaa9a1479713efa719313/galgebra/lt.py#L489-L497 Or to the documentation?

Calling itself recursively wouldn't work, because the inner objects are not `Mv` objects - there's nothing to recurse over.

Arguably the multiplicative behavior is correct - the gradient of a constant is zero

> The division makes it clear that it's a plain multiplication with a scalar, not to apply the operator to a (constant) function. The question is, what should the following...