Method `.matrix()` in module lt.py returns incorrect matrices; suggested correction; method `.det()` returns incorrect determinant

[Greg1950]

Let $f$ be an outermorphism on a geometric algebra Ga.  The matrix of $f$ with respect to a basis $b_1, ..., b_n$ is defined by $f(b_j) = \sum\limits_{i=1}^n f_{ij} b_i$.  The definition can be found in virtually any introductory linear algebra book, so call $[ f_{ij} ]$ the standard matrix of $f$ with respect to the indicated basis. The coefficients $f_{ij}$ in the expansion of $f(b_j)$ do not depend on the metric, although they can be computed using the inner product and the reciprocal basis vectors $b^1, ..., b^n$.

(Note in particular that the left index on $f_{ij}$ is the one summed over. GAlgebra's documentation, if it can be trusted, writes the defining equation as $L(b_i) = \sum\limits_{j=1}^n L_{ij} b_j$, with the summed-over index on the right. This would have the effect of defining a matrix $[ L_{ij} ]$ which is the transpose of $L$'s standard matrix.)

Problem #1: I have discovered that the method .matrix(), the code for which appears in the module lt.py, returns a matrix which iis metric dependent and so cannot be the standard matrix. The command f.matrix() returns the standard matrix only when

• the inner product is Euclidean, and
• the basis used is orthonormal. 
  I've also discovered that post-multiplication of f.matrix() by Ga.g_inv produces the standard matrix for f with respect to the basis used to generate Ga.  

As evidence I am attaching a file Linear Transformations.zip.  It contains six Jupyter notebooks, which parallel each other in format, that examine the situation using different signature inner products and different bases.  It also contains gprinter.py, a new module from Alan Bromborsky, that aids the construction of formatted output and which was used by the notebooks mentioned.  Lastly, the zip file contains a notebook g2.ipynb which is easier to examine than the other six notebooks.

Suggested Solution for Problem #1: The next-to-last line of the code for the .matrix() method reads

    self.mat = Dictionary_to_Matrix(self.lt_dict, self.Ga) * self.Ga.g

While I have only rudimentary programming skills, it seems to me that simply replacing that line by

    self.mat = Dictionary_to_Matrix(self.lt_dict, self.Ga)

will correct the problem with the transformation method .matrix(). The idea is that the multiplication of the incorrect matrix by Ga.g_inv effectively cancels out the multiplication by self.Ga.g.

Problem #2: If one applies the method .det() to an outermorphismf, strange things can happen. Look at the notebooks, other than g2.ipynb, in the attached zip file. Towards the end of each notebook one will see f.det() returning incorrect answers. Sometimes the correct answer is returned, sometimes a pseudoscalar is returned instead of the scalar which should be returned, and in one instance (hyperbolic plane, polar coordinates.ipynb) an answer is returned which multiplies the pseudoscalar by SymPy's unit imaginary i (geometric algebra doesn't use imaginary numbers, per se).

Solution for Problem #2: I have none. But I suspect the appearance of the unit imaginary arises with an incorrect computation of the unit pseudoscalar Ga.I(). That in turn may be linked to incorrect computation of a blade's norm. (I plan to post separately with regards to a multivector's norm-squared and norm.)

Greg Grunberg

Addendum: The Suggested Solution for Problem #1, described above, sort of worked. I made the change indicated in the suggestion. Afterwards f.matrix() would returned an answer in the form of a matrix with a transposition T as a superscript. Upon carrying out the indicated transposition, the desired standard matrix was obtained. I then restored the code for the method .matrix(), and then wrote a new method as follows:

def std_matrix(self) -> Matrix:
    r"""
    Returns the standard matrix representation :math:`\left[ {{f}^i}_{j} \right]` of 
    the linear transformation :math:`f`, with entries defined by the equations
    :math:`{{f}\lp {{{\eb}}_{j}} \rp} = {{\eb}}_{i} {{f}^i}_{j}`.
    """
    standard_matrix = self.matrix() * self.Ga.g_inv 
    return standard_matrix

Testing f.std_matrix() for all outermorphisms examined in then notebooks contained in the zip file, in each case the metric-independent standard matrix was returned.

Linear Transformations.zip

[Greg1950]

The zip file I attached to my original post contained within it a file Euclidean 3-space, spherical coordinates.ipynb with some errors. The attached file corrects those errors.

Euclidean 3-space, spherical coordinates.zip

[eric-wieser]

Thanks for the report. Here I think is a simpler reproduction (which is built on top of #454):

>>> from galgebra.ga import Ga
>>> g2 = Ga('e_x e_y', g=[1,1])
>>> g2a = Ga('e_x e_y', g=[[1, 0], [0, 2]])
>>> g2b = Ga('e_x e_y', g=[[0, 1], [1, 0]])

>>> g2.lt([[0, 2], [1, 1]]).matrix()  # note: this crashes until #454 is in
Matrix([
[0, 1],
[2, 1]])

>>> g2a.lt([[0, 2], [1, 1]]).matrix()
Matrix([
[0, 2],
[2, 2]])

>>> g2b.lt([[0, 2], [1, 1]]).matrix()
Matrix([
[1, 0],
[1, 2]])

to me, it looks like lt(list) is uniformly broken. You get what looks to me like correct behavior if you use lt(Matrix) instead:

>>> from sympy import Matrix
>>> g2.lt(Matrix([[0, 2], [1, 1]])).matrix()
Matrix([
[0, 2],
[1, 1]])
>>> g2a.lt(Matrix([[0, 2], [1, 1]])).matrix()
Matrix([
[0, 2],
[1, 1]])
>>> g2b.lt(Matrix([[0, 2], [1, 1]])).matrix()
Matrix([
[0, 2],
[1, 1]])

I think this only scratches the surface though. #158 is related.

[eric-wieser]

#456 is also related.

[eric-wieser]

You say in your notebooks:

disregard the L on the left side of the equations; each pair of equations corresponds to a different transformation):

Do you have a better suggestion for how to display the transformation without the confusing L?

[Greg1950]

Hi Eric, Suppose one has a function $s$ such that $s(x) = x^2$. One doesn't actually have to give the function a name $s$ to be able to refer to the function. Instead just refer to the function $x \mapsto x^2$ , read "$x$ maps to $x^2$". No name $s$ is needed. This practice is well established in mathematical literature. Here's an example relevant to the GAlgebra module *lt.py*. Let $T$ be a linear transformation on a space with basis , represented in GAlgebra by the identifier `T`. Currently, when one executes a simple `T` in a Jupyter notebook In[ ] cell, the corresponding Out[ ] cell will contain output looking something like this: $$ \left \{ \begin{array}{ll} L \left ( \mathbf{e}_x\right ) =& 2 \mathbf{e}_y \\ L \left ( \mathbf{e}_y\right ) =& \mathbf{e}_x + \mathbf{e}_y \end{array} \right \} $$ This looks like one is applying a transformation named $L$, but the actual name was $T$. Instead one could simply output a description of $T$'s action that looks like this : $$ \left \{ \begin{array}{ll} \mathbf{e}_x \mapsto & 2 \mathbf{e}_y \\ \mathbf{e}_y \mapsto & \mathbf{e}_x + \mathbf{e}_y \end{array} \right \} $$ I've seen "mapsto" notation used in SymPy (or maybe it was in SageMath), but I don't remember the details. Greg Grunberg

…

On Mon, Sep 14, 2020 at 11:41 AM Eric Wieser ***@***.***> wrote: You say in your notebooks: disregard the L on the left side of the equations; each pair of equations corresponds to a different transformation): Do you have a better suggestion for how to display the transformation without the confusing L? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG2OCIF6EYSELBHGA3BJOPTSFZBUDANCNFSM4RIVJDKA> .

[Greg1950]

Let a_list_of_lists = [ [a,b], [c,d] ] and consider the SymPy matrix created by the command Matrix(a_list_of_lists) . It will be a matrix whose first row is *a b* and whose second row is *c d* . In general, the *i*th entry (itself a list) in a_list_of_lists specifies the *i*th *row* of the matrix. If one is already familiar with SymPy's Matrix() constructor, one may be inclined to misinterpret how a_list_of_lists is interpreted in the GAlgebra command T = GA.lt(a_list_of_lists) . (I made that mistake.) The [image: j]th entry [image: [ {T^1}_j, \ldots, {T^n}_j ]] in a_list_of_lists is interpreted as the coefficients in the expansion [image: T(b_j) = b_1 {T^1}_j + \cdots + b_n {T^n}_j] of the image of the [image: j]th basis vector. Those coefficients form the [image: j]th column of the *standard matrix* of [image: T] with respect to basis [image: b_1, \ldots, b_n] . So the [image: j]th entry in a_list_of_lists gives the [image: j]th *column* of [image: T]'s standard matrix, not its [image: j]th *row*. The standard matrix will be the transpose of Matrix(a_list_of_lists) . It is important to understand that unless the basis is orthonormal and the metric is Euclidean, the command T.matrix() does not return the standard matrix of [image: T] with respect to basis [image: b_1, \ldots, b_n] . I have not so far figured an interpretation of T.matrix(), but, as previously posted, the matrix product T.matrix() * T.Ga.g_inv appears to yield the standard matrix of [image: T]. T.matrix() is dependent on the metric, the standard matrix of [image: T] is not. I was not aware that the constructor GA.lt( ) accepted a SymPy matrix as an argument. Preliminary investigation indicates that S = GA.lt(Matrix(a_list_of_lists)) instantiates a transformation which has a different action from T = GA.lt(a_list_of_lists). That preliminary investigation shows that S.matrix() does indeed equal Matrix(a_list_of_lists) , but it's still not clear how that common matrix relates to the action of [image: S] on the basis vectors.

…

On Mon, Sep 14, 2020 at 4:47 AM Eric Wieser ***@***.***> wrote: Thanks for the report. Here I think is a simpler reproduction (which is built on top of #454 <#454>): >>> from galgebra.ga import Ga>>> g2 = Ga('e_x e_y', g=[1,1])>>> g2a = Ga('e_x e_y', g=[[1, 0], [0, 2]])>>> g2b = Ga('e_x e_y', g=[[0, 1], [1, 0]]) >>> g2.lt([[0, 2], [1, 1]]).matrix() # note: this crashes until #454 is inMatrix([ [0, 1], [2, 1]]) >>> g2a.lt([[0, 2], [1, 1]]).matrix()Matrix([ [0, 2], [2, 2]]) >>> g2b.lt([[0, 2], [1, 1]]).matrix()Matrix([ [1, 0], [1, 2]]) to me, it looks like lt(list) is uniformly broken. You get what looks to me like correct behavior if you use lt(Matrix) instead: >>> from sympy import Matrix>>> g2.lt(Matrix([[0, 2], [1, 1]])).matrix()Matrix([ [0, 2], [1, 1]])>>> g2a.lt(Matrix([[0, 2], [1, 1]])).matrix()Matrix([ [0, 2], [1, 1]])>>> g2b.lt(Matrix([[0, 2], [1, 1]])).matrix()Matrix([ [0, 2], [1, 1]]) I think this only scratches the surface though. #158 <#158> is related. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG2OCID54LI6Y3Y2PHBFONDSFXRCXANCNFSM4RIVJDKA> .

[eric-wieser]

Thanks @Greg1950, \mapsto sounds totally reasonable to me - I've gone ahead and made that change in #458