Sage: Ticket #29886: Add generator of symmetric matrices
https://trac.sagemath.org/ticket/29886
<p>
We add a method to the <code>MatrixSpace</code> class that returns a generator over
the symmetric matrices in the space. The "symmetry" is defined by the user.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/29886
Trac 1.2Samuel LelièvreThu, 18 Jun 2020 03:28:44 GMT
https://trac.sagemath.org/ticket/29886#comment:1
https://trac.sagemath.org/ticket/29886#comment:1
<p>
Remove space before closing parenthesis:
</p>
<pre class="wiki">- def symmetric_matrices(self, f, g=None ):
+ def symmetric_matrices(self, f, g=None):
</pre><p>
Typo: doesn't contains -> doesn't contain.
</p>
<p>
Use a space after each comma in code,
and around <code>+</code> signs.
</p>
<p>
Use double backticks, e.g. <code>``f``</code> or <code>``ValueError``</code>
for code formatting in docstrings.
</p>
<p>
Typo "funcition" -> function.
</p>
<p>
Use code formatting for <code>None</code>:
<code>if it is None</code> -> <code>if it is ``None``</code>
</p>
<pre class="wiki">- skew-symmetric matrices:
+ Skew-symmetric matrices:
</pre><p>
Typo: <code>MetricSpace</code> -> <code>MatrixSpace</code>.
</p>
<p>
Hint: after making changes, rebuild Sage and test with
</p>
<pre class="wiki">sage -t src/sage/matrix/matrix_space.py
</pre><p>
before pushing. That would catch things such as <code>MetricSpace</code>.
</p>
<p>
Replace this doctest whose output is hard to parse:
</p>
<pre class="wiki">sage: gen = MS.symmetric_matrices(f)
sage: for M in gen:
....: print(M)
</pre><p>
by this one whose output takes up less space and is easier to parse:
</p>
<pre class="wiki">sage: list(MS.symmetric_matrices(f))
</pre><p>
Likewise, replace this:
</p>
<pre class="wiki">sage: gen = MS.symmetric_matrices(f)
sage: i = 0
sage: for M in gen:
....: i+= 1
....: print(M)
....: if i == 3: break
</pre><p>
with this more concise:
</p>
<pre class="wiki">sage: gen = MS.symmetric_matrices(f)
sage: [next(gen) for _ in range(3)]
</pre><p>
Remove spaces around <code>M</code> in <code>def make_symmetric( M ):</code>.
</p>
<p>
Simplify "can't have symmetric matrices if they are not square"
to "symmetric matrices must be square" or "only square matrices
can be symmetric".
</p>
<p>
Use a space after <code>#</code> for comments, for instance:
</p>
<pre class="wiki">- #When the base ring is not finite,
+ # When the base ring is not finite,
</pre><p>
For inline comments, double space before <code>#</code> and single space after.
For instance:
</p>
<pre class="wiki">matrix_entries = [] # entries of matrix with lower half 0
</pre><p>
No need to comment <code>#make M symmetric</code> before
<code>make_symmetric(M)</code>, function name says it all.
</p>
<p>
Rather than importing
</p>
<pre class="wiki">import sage.combinat.integer_vector
</pre><p>
and using <code>sage.combinat.integer_vector.IntegerVectors</code>, instead import
</p>
<pre class="wiki">from sage.combinat.integer_vector import IntegerVectors
</pre><p>
and then use <code>IntegerVectors</code>.
</p>
TicketSamuel LelièvreThu, 18 Jun 2020 03:43:52 GMT
https://trac.sagemath.org/ticket/29886#comment:2
https://trac.sagemath.org/ticket/29886#comment:2
<p>
The <a class="ext-link" href="https://www.python.org/dev/peps/pep-0008/"><span class="icon"></span>PEP-0008 Python style guide</a>
and <a class="ext-link" href="https://www.python.org/dev/peps/pep-0257/"><span class="icon"></span>PEP-0257 Docstring conventions</a>
are recommended reading.
</p>
<p>
I should read them again too, I realise I need a refresher on some points there.
</p>
TicketgitThu, 18 Jun 2020 12:53:07 GMTcommit changed
https://trac.sagemath.org/ticket/29886#comment:3
https://trac.sagemath.org/ticket/29886#comment:3
<ul>
<li><strong>commit</strong>
changed from <em>a24e6a07971f44715896523d15b8c61633ef9e52</em> to <em>9b5145b551a552ece2f31c0cf6a42b7c10d08f89</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=1b38de3b2ce0c4449e1826575d40ad2b3f582ad8"><span class="icon"></span>1b38de3</a></td><td><code>fixed formatting</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=9b5145b551a552ece2f31c0cf6a42b7c10d08f89"><span class="icon"></span>9b5145b</a></td><td><code>removed trailing whitespaces</code>
</td></tr></table>
Ticketgh-Ivo-MaffeiThu, 18 Jun 2020 12:53:59 GMTstatus, author changed
https://trac.sagemath.org/ticket/29886#comment:4
https://trac.sagemath.org/ticket/29886#comment:4
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>author</strong>
changed from <em>gh-Ivo-Maffei</em> to <em>Ivo Maffei</em>
</li>
</ul>
Ticketgh-Ivo-MaffeiThu, 18 Jun 2020 12:55:43 GMT
https://trac.sagemath.org/ticket/29886#comment:5
https://trac.sagemath.org/ticket/29886#comment:5
<p>
Thanks for the detailed review.
I think I fixed all formatting issues now.
I also took the liberty to change a bit the <code>__iter__</code> method.
</p>
TicketSamuel LelièvreThu, 18 Jun 2020 15:44:48 GMTdescription, summary changed
https://trac.sagemath.org/ticket/29886#comment:6
https://trac.sagemath.org/ticket/29886#comment:6
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/29886?action=diff&version=6">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Generator of symmetric matrices.</em> to <em>Add generator of symmetric matrices</em>
</li>
</ul>
<p>
Use <code>is None</code> to test if something is <code>None</code>:
</p>
<pre class="wiki">- if g == None:
+ if g is None:
</pre><p>
I would also use <code>f=None</code> to mean <code>f</code> is the identity --
giving the standard "symmetric" matrices:
</p>
<pre class="wiki">if f is None:
f = lambda x: x
</pre><p>
I would write the input as:
</p>
<pre class="wiki">- ``f`` -- function or ``None`` (optional; default: ``None``);
if ``None``, use the identity function
- ``g`` -- function or ``None`` (optional; default: ``None``);
if ``None``, use the same function as for ``f``
</pre><p>
Need to decide what symmetric should mean
</p>
<ul><li>Among possible definitions:
<ul><li>subdiagonal entries are images by <code></code>f<code></code> of the
corresponding superdiagonal entries, i.e.
for any <code>i < j</code> we have <code>A[j,i] = f(A[i,j])</code>
</li><li>nondiagonal entries are images by <code></code>f<code></code>
of their mirror entries, i.e.
for any <code>i != j</code> we have <code>A[j,i] = f(A[i,j])</code>
</li></ul></li><li>These are the same if <code>f</code> is an involution;
if that is assumed it needs to be said
</li><li>Accordingly, do all or only half the checks
</li></ul><p>
I would avoid formulas in the docstring's first sentence
and clarify in a second sentence:
</p>
<pre class="wiki">Return a generator of all matrices in this matrix space
that are "symmetric" as defined by `f` and `g`.
This means subdiagonal entries are images by ``f``
of the corresponding superdiagonal entries, i.e.
for any ``i < j`` we have ``A[j,i] = f(A[i,j])``,
and diagonal elements are stable by ``g`` ,
i.e. for any ``i`` we have ``A[i,i] = g(A[i,i])``.
The default value of ``None`` for ``f`` means
``f`` is the identity, and the default value
of ``None`` for ``g`` means ``g`` is ``f``.
</pre><p>
Need <code>::</code> here to start the doctest block:
</p>
<pre class="wiki">Skew-symmetric matrices::
</pre><p>
I would use <code>v</code> rather than <code>iv</code> for the loop variable.
</p>
<p>
Comments could be more concise:
</p>
<pre class="wiki">- # If the number of entries is zero, then just
- # yield the empty matrix in that case and return
+ # If no entries, yield empty matrix and return
if number_of_entries == 0:
yield self(0)
return
</pre><pre class="wiki">- # When the base ring is not finite, then we should go
- # through and yield the matrices by "weight", which is
- # the total number of iterations that need to be done
- # on the base ring to reach the matrix.
+ # For infinite rings, yield matrices by "weight",
+ # i.e. by number of iterations needed to reach them.
</pre><pre class="wiki">- # In the finite case, we do a similar thing except that
- # instead of checking if the diagonal is correct after creating the vector
- # we can select all possible diagonal elements a priori
+ For finite rings, allow all ring elements on the diagonal a priori.
</pre>
TicketgitTue, 30 Jun 2020 11:58:42 GMTcommit changed
https://trac.sagemath.org/ticket/29886#comment:7
https://trac.sagemath.org/ticket/29886#comment:7
<ul>
<li><strong>commit</strong>
changed from <em>9b5145b551a552ece2f31c0cf6a42b7c10d08f89</em> to <em>08fc8931f350c764b29aa1f76ac2a504de7cac5b</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=08fc8931f350c764b29aa1f76ac2a504de7cac5b"><span class="icon"></span>08fc893</a></td><td><code>fixed more code formatting; allow f=None for nomal symmetric matrices</code>
</td></tr></table>
Ticketgh-Ivo-MaffeiTue, 30 Jun 2020 11:59:28 GMT
https://trac.sagemath.org/ticket/29886#comment:8
https://trac.sagemath.org/ticket/29886#comment:8
<p>
Thanks for the review!! I apologise for the delay. I got caught in other tickets.
</p>
TicketDima PasechnikMon, 10 Aug 2020 14:36:41 GMT
https://trac.sagemath.org/ticket/29886#comment:9
https://trac.sagemath.org/ticket/29886#comment:9
<p>
reviewer name?
</p>
Ticketgh-Ivo-MaffeiMon, 10 Aug 2020 15:07:18 GMT
https://trac.sagemath.org/ticket/29886#comment:10
https://trac.sagemath.org/ticket/29886#comment:10
<p>
@slelievre (Samuel Lelièvre) did some reviewing, but never green lighted this. They probably never felt sure about the code.
</p>
TicketDima PasechnikMon, 10 Aug 2020 15:10:49 GMTcc, reviewer set
https://trac.sagemath.org/ticket/29886#comment:11
https://trac.sagemath.org/ticket/29886#comment:11
<ul>
<li><strong>cc</strong>
<em>Matthias Köppe</em> added
</li>
<li><strong>reviewer</strong>
set to <em>Samuel Lelièvre</em>
</li>
</ul>
<p>
Matthias, does it fit into the tensors stuff you are working on?
</p>
TicketDima PasechnikMon, 10 Aug 2020 15:11:24 GMTreviewer changed
https://trac.sagemath.org/ticket/29886#comment:12
https://trac.sagemath.org/ticket/29886#comment:12
<ul>
<li><strong>reviewer</strong>
changed from <em>Samuel Lelièvre</em> to <em>Samuel Lelièvre, ...</em>
</li>
</ul>
TicketMatthias KöppeMon, 10 Aug 2020 15:26:07 GMT
https://trac.sagemath.org/ticket/29886#comment:13
https://trac.sagemath.org/ticket/29886#comment:13
<p>
Yes, I think it does. In <a class="closed ticket" href="https://trac.sagemath.org/ticket/30229" title="#30229: defect: Submodules of TensorFreeModule defined by the symmetries of a ... (closed: fixed)">#30229</a> I define free modules of tensors with prescribed index symmetries. This covers the case of symmetric and antisymmetric matrices, of course. There is a basis and so if the base ring is an enumerated set, so is the module.
</p>
TicketDima PasechnikMon, 10 Aug 2020 15:45:59 GMT
https://trac.sagemath.org/ticket/29886#comment:14
https://trac.sagemath.org/ticket/29886#comment:14
<p>
I think that skew-symmetric matrices are requested often enough for them to warrant a named function (which would just forward naturally to what you altready implemented).
</p>
TicketMatthias KöppeMon, 10 Aug 2020 15:49:41 GMT
https://trac.sagemath.org/ticket/29886#comment:15
https://trac.sagemath.org/ticket/29886#comment:15
<p>
I agree that it would be nice to have facilities in matrix space for symmetric and skew-symmetric matrices, but I think it would be better to define the subspaces/modules of these matrices than to define enumeration methods. Enumeration comes for free from our general facilities for enumerated sets.
</p>
Ticketgh-Ivo-MaffeiMon, 10 Aug 2020 16:20:44 GMT
https://trac.sagemath.org/ticket/29886#comment:16
https://trac.sagemath.org/ticket/29886#comment:16
<p>
So you suggest having a general <code>SymmetricMatrixSpace</code> class which extends <code>MatrixSpace</code> or having the "standard" <code>SymmetricMatrixSpace</code> and <code>SkewSymmetricMatrixSpace</code> classes and leaving everything else to an enumeration method?
</p>
TicketMatthias KöppeMon, 10 Aug 2020 16:36:14 GMTcc changed
https://trac.sagemath.org/ticket/29886#comment:17
https://trac.sagemath.org/ticket/29886#comment:17
<ul>
<li><strong>cc</strong>
<em>Travis Scrimshaw</em> added
</li>
</ul>
<p>
I don't think new classes are really needed. Instead, just methods that construct submodules.
</p>
<p>
Unfortunately, currently <code>MatrixSpace</code> does not fully implement the category of modules with bases (see (<code>sage.categories.modules_with_basis</code>) that it claims to belong to.
</p>
<pre class="wiki">sage: M = MatrixSpace(QQ, 3, 3)
sage: M in ModulesWithBasis(QQ)
True
sage: A = M([[0, 0, 1], [0, 0, 0], [0, 0, 0]])
sage: A
[0 0 1]
[0 0 0]
[0 0 0]
sage: M.submodule([A])
AttributeError: 'MatrixSpace_with_category' object has no attribute 'get_order'
</pre><p>
I would suggest to start with fixing the implementation of this functionality of <code>MatrixSpace</code>.
</p>
<p>
Then in the next step, you can define the methods that construct the specific modules that you need.
</p>
TicketDima PasechnikMon, 10 Aug 2020 16:54:07 GMT
https://trac.sagemath.org/ticket/29886#comment:18
https://trac.sagemath.org/ticket/29886#comment:18
<p>
I am inclined to wave this through, as it's needed for Ivo's GSoC project, and the time is tight.
</p>
TicketMatthias KöppeMon, 10 Aug 2020 16:59:07 GMT
https://trac.sagemath.org/ticket/29886#comment:19
https://trac.sagemath.org/ticket/29886#comment:19
<p>
I don't object to adding these specific enumeration methods,
but I think adding this interface with the generality of this <code>f</code> and <code>g</code> thing is not a good idea, because a future implementation along the lines that we just discussed will not be able to support general f and g.
</p>
TicketMatthias KöppeMon, 10 Aug 2020 17:05:03 GMT
https://trac.sagemath.org/ticket/29886#comment:20
https://trac.sagemath.org/ticket/29886#comment:20
<p>
See <a class="new ticket" href="https://trac.sagemath.org/ticket/30276" title="#30276: enhancement: Phased permutation groups (new)">#30276</a> for the type of symmetry that we hope to support.
</p>
TicketTravis ScrimshawTue, 11 Aug 2020 00:49:23 GMTstatus changed
https://trac.sagemath.org/ticket/29886#comment:21
https://trac.sagemath.org/ticket/29886#comment:21
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
I usually thing of the sub/superdiagonal matrices as just being the entries immediately off the diagonal, not in all of the lower/upper triangular part.
</p>
<p>
A lot of what this method does is really confusing to me. The algorithm should be explained in the docstring, in particular the order which it is iterating through everything.
</p>
<p>
I also somewhat agree with Matthias here. I would first expect this to return a subspace, which doesn't work for generic <code>f</code> and <code>g</code>. Plus the word "symmetric" seems misleading to me for generic <code>f</code> and <code>g</code>. Perhaps as a middle ground, we call this <code>symmetric_matrices_iterator()</code>.
</p>
<p>
Comments from a quick look at the code:
</p>
<p>
I don't see why you need to do <code>v2.clone()</code> since you never modify it. You simply get a sublist that to reassign to <code>v</code>.
</p>
<p>
<code>self(0)</code> -> <code>self.zero()</code>.
</p>
<p>
This is very strange: <code>for _ in range(nrows):</code>. I don't understand this code block.
</p>
TicketDima PasechnikTue, 11 Aug 2020 11:12:18 GMT
https://trac.sagemath.org/ticket/29886#comment:22
https://trac.sagemath.org/ticket/29886#comment:22
<p>
I suggest to implement here only the minimum needed for the GSoC tickets to be done (on a different branch, to preserve this, I suppose).
</p>
Ticketgh-Ivo-MaffeiTue, 11 Aug 2020 12:22:03 GMTattachment set
https://trac.sagemath.org/ticket/29886
https://trac.sagemath.org/ticket/29886
<ul>
<li><strong>attachment</strong>
set to <em>traceback.txt</em>
</li>
</ul>
<p>
mutable matrices issue full traceback
</p>
Ticketgh-Ivo-MaffeiTue, 11 Aug 2020 12:22:11 GMT
https://trac.sagemath.org/ticket/29886#comment:23
https://trac.sagemath.org/ticket/29886#comment:23
<p>
I spent some time looking at the <code>submodule</code> method to see if there was some easy fix. I think I got 90% of the way.
There were some issues in the method <code>sage.categories.finite_dimensional_modules_with_basis.echelon_form</code>.
</p>
<div class="wiki-code"><div xmlns="http://www.w3.org/1999/xhtml" class="diff">
<ul class="entries">
<li class="entry">
<h2>
<a>src/sage/categories/finite_dimensional_modules_with_basis.py</a>
</h2>
<pre>diff --git a/src/sage/categories/finite_dimensional_modules_with_basis.py b/src/sage/categories/finite_dimensional_modules_with_basis.py
</pre>
<table class="trac-diff inline" summary="Differences" cellspacing="0">
<colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup>
<thead>
<tr>
<th title="File a/src/sage/categories/finite_dimensional_modules_with_basis.py">
a
</th>
<th title="File b/src/sage/categories/finite_dimensional_modules_with_basis.py">
b
</th>
<td><em> class FiniteDimensionalModulesWithBasis(CategoryWithAxiom_over_base_ring):</em> </td>
</tr>
</thead>
<tbody class="unmod">
<tr>
<th>337</th><th>337</th><td class="l"><span> sage: C.echelon_form([x[0] - x[1], 2*x[1] - 2*x[2], x[0] - x[2]])</span></td>
</tr><tr>
<th>338</th><th>338</th><td class="l"><span> [x[0] - x[2], x[1] - x[2]]</span></td>
</tr><tr>
<th>339</th><th>339</th><td class="l"><span> """</span></td>
</tr><tr>
<th>340</th><th>340</th><td class="l"><span> if order is not None:</span></td>
</tr>
</tbody><tbody class="mod">
<tr class="first">
<th>341</th><th> </th><td class="l"><span> order = self._compute_support_order(order)</span></td>
</tr>
<tr>
<th> </th><th>341</th><td class="r"><span> order = self._compute_support_order(elements, order)</span></td>
</tr><tr>
<th> </th><th>342</th><td class="r"><span></span></td>
</tr><tr>
<th> </th><th>343</th><td class="r"><span> # order may be an ordering of the support of elements</span></td>
</tr><tr>
<th> </th><th>344</th><td class="r"><span> # hence not an ordering of the whole basis as needed below</span></td>
</tr><tr>
<th> </th><th>345</th><td class="r"><span> # so we extend order to an ordering of the whole basis</span></td>
</tr><tr>
<th> </th><th>346</th><td class="r"><span> orderList = list(order)</span></td>
</tr><tr>
<th> </th><th>347</th><td class="r"><span> for k in self.basis().keys():</span></td>
</tr><tr>
<th> </th><th>348</th><td class="r"><span> if k not in orderList:</span></td>
</tr><tr>
<th> </th><th>349</th><td class="r"><span> orderList.append(k)</span></td>
</tr><tr>
<th> </th><th>350</th><td class="r"><span></span></td>
</tr><tr>
<th> </th><th>351</th><td class="r"><span> full_order = tuple(orderList)</span></td>
</tr><tr>
<th> </th><th>352</th><td class="r"><span></span></td>
</tr><tr class="last">
<th> </th><th>353</th><td class="r"><span> </span></td>
</tr>
</tbody><tbody class="unmod">
<tr>
<th>342</th><th>354</th><td class="l"><span> from sage.matrix.constructor import matrix</span></td>
</tr>
</tbody><tbody class="mod">
<tr class="first">
<th>343</th><th> </th><td class="l"><span> mat = matrix(self.base_ring(), [g._vector_(order=<del></del>order) for g in elements])</span></td>
</tr>
<tr class="last">
<th> </th><th>355</th><td class="r"><span> mat = matrix(self.base_ring(), [g._vector_(order=<ins>full_</ins>order) for g in elements])</span></td>
</tr>
</tbody><tbody class="unmod">
<tr>
<th>344</th><th>356</th><td class="l"><span> # Echelonizing a matrix over a field returned the rref</span></td>
</tr><tr>
<th>345</th><th>357</th><td class="l"><span> if row_reduced and self.base_ring() not in Fields():</span></td>
</tr><tr>
<th>346</th><th>358</th><td class="l"><span> try:</span></td>
</tr>
</tbody>
</table>
</li>
</ul>
</div></div><p>
After applying that patch there is an issue with mutable matrices not being hashable. The issue seems to lie in <code>sage.misc.cachefunc</code> and I don't have enough knowledge of python or the inner working of Sage to proceed.
</p>
<p>
Honestly, I had a huge amount of issues with matrices/vectors not being hashable, so I wonder why aren't they immutable by default.
</p>
TicketMatthias KöppeTue, 11 Aug 2020 14:02:05 GMT
https://trac.sagemath.org/ticket/29886#comment:24
https://trac.sagemath.org/ticket/29886#comment:24
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/29886#comment:22" title="Comment 22">dimpase</a>:
</p>
<blockquote class="citation">
<p>
I suggest to implement here only the minimum needed for the GSoC tickets to be done (on a different branch, to preserve this, I suppose).
</p>
</blockquote>
<p>
I have opened <a class="closed ticket" href="https://trac.sagemath.org/ticket/30334" title="#30334: defect: MatrixSpace.submodule does not work (closed: invalid)">#30334</a> for the <code>MatrixSpace.submodule</code> issue.
</p>
TicketMatthias KöppeTue, 11 Aug 2020 14:16:51 GMT
https://trac.sagemath.org/ticket/29886#comment:25
https://trac.sagemath.org/ticket/29886#comment:25
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/30334" title="#30334: defect: MatrixSpace.submodule does not work (closed: invalid)">#30334</a> is not urgent.
</p>
<p>
Given that <code>submodule</code> does not work, my suggestion for the present ticket would be the following. First implement a method named perhaps <code>MatrixSpace.symmetric_submodule_basis(phase=1)</code>. As in <a class="new ticket" href="https://trac.sagemath.org/ticket/30276" title="#30276: enhancement: Phased permutation groups (new)">#30276</a>, for <code>phase=1</code>, return a basis of the submodule of the symmetric matrices, and for <code>phase=-1</code>, skew-symmetric matrices. Error for all other values of <code>phase</code>.
</p>
Ticketgh-Ivo-MaffeiTue, 11 Aug 2020 15:59:42 GMT
https://trac.sagemath.org/ticket/29886#comment:26
https://trac.sagemath.org/ticket/29886#comment:26
<p>
I don't fully understand <a class="closed ticket" href="https://trac.sagemath.org/ticket/30334" title="#30334: defect: MatrixSpace.submodule does not work (closed: invalid)">#30334</a>. What I'm using this method for, is to generate skew-symmetric matrices with diagonal entries 0 (the standard definition <code>A^T = -A</code> would allow diagonal entries 1 in GF(2)) and Hermitian matrices.
Can these be achieved for some <code>phase</code>?
</p>
TicketMatthias KöppeTue, 11 Aug 2020 16:11:08 GMT
https://trac.sagemath.org/ticket/29886#comment:27
https://trac.sagemath.org/ticket/29886#comment:27
<p>
That's important information - from looking at the code it was not clear to me what generality you need.
</p>
<p>
For Hermitian matrices - over what field?
</p>
Ticketgh-Ivo-MaffeiTue, 11 Aug 2020 16:17:26 GMT
https://trac.sagemath.org/ticket/29886#comment:28
https://trac.sagemath.org/ticket/29886#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/29886#comment:27" title="Comment 27">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
For Hermitian matrices - over what field?
</p>
</blockquote>
<p>
Finite fields <code>GF(r^2)</code>. Practically only <code>GF(4)</code> and <code>GF(9)</code>.
</p>
TicketMatthias KöppeTue, 11 Aug 2020 16:45:36 GMT
https://trac.sagemath.org/ticket/29886#comment:29
https://trac.sagemath.org/ticket/29886#comment:29
<p>
Unfortunately the Hermitian matrices over a field k do not form a subspace (over k)...
</p>
Ticketgh-Ivo-MaffeiTue, 11 Aug 2020 17:26:02 GMT
https://trac.sagemath.org/ticket/29886#comment:30
https://trac.sagemath.org/ticket/29886#comment:30
<p>
They form a subgroup and they seem quite common...
If you think there is no place for a generator of some sort here, then I'll just have the hermitian matrices created where I use them, so that nothing is exposed to the user.
</p>
TicketDima PasechnikTue, 11 Aug 2020 21:32:36 GMT
https://trac.sagemath.org/ticket/29886#comment:31
https://trac.sagemath.org/ticket/29886#comment:31
<p>
well, Hermitian matrices form a subspace over the fixed (by the automorphism) subfield. Probably our matrices aren't flexible enough for this, though.
</p>
TicketMatthias KöppeThu, 13 Aug 2020 17:39:05 GMT
https://trac.sagemath.org/ticket/29886#comment:32
https://trac.sagemath.org/ticket/29886#comment:32
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/29886#comment:22" title="Comment 22">dimpase</a>:
</p>
<blockquote class="citation">
<p>
I suggest to implement here only the minimum needed for the GSoC tickets to be done (on a different branch, to preserve this, I suppose).
</p>
</blockquote>
<p>
To move forward, I'd suggest to move this methods to the code where they are needed. It can be be refactored later when we figure out the right framework.
</p>
TicketMatthias KöppeSat, 24 Oct 2020 20:15:01 GMTmilestone changed
https://trac.sagemath.org/ticket/29886#comment:33
https://trac.sagemath.org/ticket/29886#comment:33
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.2</em> to <em>sage-9.3</em>
</li>
</ul>
TicketMatthias KöppeSat, 13 Feb 2021 20:51:01 GMTmilestone changed
https://trac.sagemath.org/ticket/29886#comment:34
https://trac.sagemath.org/ticket/29886#comment:34
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.3</em> to <em>sage-9.4</em>
</li>
</ul>
<p>
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
</p>
TicketSamuel LelièvreSat, 03 Jul 2021 10:51:01 GMT
https://trac.sagemath.org/ticket/29886#comment:35
https://trac.sagemath.org/ticket/29886#comment:35
<p>
Submodules of matrix spaces are taken care of at <a class="closed ticket" href="https://trac.sagemath.org/ticket/31995" title="#31995: defect: Submodules of a MatrixSpace (closed: fixed)">#31995</a> (superseding <a class="closed ticket" href="https://trac.sagemath.org/ticket/30334" title="#30334: defect: MatrixSpace.submodule does not work (closed: invalid)">#30334</a>).
</p>
TicketMatthias KöppeMon, 19 Jul 2021 00:44:56 GMTmilestone changed
https://trac.sagemath.org/ticket/29886#comment:36
https://trac.sagemath.org/ticket/29886#comment:36
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.4</em> to <em>sage-9.5</em>
</li>
</ul>
<p>
Setting a new milestone for this ticket based on a cursory review.
</p>
TicketMatthias KöppeSat, 18 Dec 2021 19:24:17 GMTmilestone changed
https://trac.sagemath.org/ticket/29886#comment:37
https://trac.sagemath.org/ticket/29886#comment:37
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.5</em> to <em>sage-9.6</em>
</li>
</ul>
TicketMatthias KöppeSat, 02 Apr 2022 20:27:49 GMTmilestone changed
https://trac.sagemath.org/ticket/29886#comment:38
https://trac.sagemath.org/ticket/29886#comment:38
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.6</em> to <em>sage-9.7</em>
</li>
</ul>
TicketMatthias KöppeMon, 19 Sep 2022 18:58:47 GMTmilestone changed
https://trac.sagemath.org/ticket/29886#comment:39
https://trac.sagemath.org/ticket/29886#comment:39
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.7</em> to <em>sage-9.8</em>
</li>
</ul>
Ticket