Construction for invariant/equivariant submodules

[mkoeppe]

We introduce a construction functor for invariant and equivariant submodules.

sage.modules.with_basis.invariant.FiniteDimensionalInvariantModule gets a construction method.

In follow-up ticket #34499, also the tensor modules with prescribed monoterm symmetries from #30229 will get a construction method. An illustration of this application, capturing symmetric and antisymmetric matrices, is included as an example. (See #32029, #30276.)

CC: @tscrim @trevorkarn @egourgoulhon @anneschilling

Component: linear algebra

Author: Matthias Koeppe

Branch/Commit: 7fe5763

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/34495

[mkoeppe]

Branch: u/mkoeppe/construction_for_invariant_equivariant_submodules

[sagetrac-git]

Commit: 1ee5470

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

1ee5470

FiniteDimensionalInvariantModule.construction: New

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

e7f2f05

src/sage/categories/pushout.py: Add example

[sagetrac-git]

Changed commit from 1ee5470 to e7f2f05

[mkoeppe]

Author: Matthias Koeppe

[sagetrac-git]

Changed commit from e7f2f05 to 9e09c2f

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

9e09c2f

src/sage/categories/pushout.py: Remove unfinished example

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

86d9602

src/sage/categories/pushout.py: Add missing doctests

[sagetrac-git]

Changed commit from 9e09c2f to 86d9602

[sagetrac-git]

Changed commit from 86d9602 to 8ddcaa1

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

8ddcaa1

src/sage/categories/pushout.py: Add copyright according to 'git blame -w --date=format:%Y src/sage/categories/pushout.py | sort -k2'

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

bfd6eee

src/sage/modules/with_basis/invariant.py: Update copyright

[sagetrac-git]

Changed commit from 8ddcaa1 to bfd6eee

[sagetrac-git]

Changed commit from bfd6eee to 7fe5763

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

7fe5763

src/sage/algebras/orlik_{solomon,terao}.py: No construction for subclasses of FiniteDimensionalInvariantModule

[tscrim]

comment:13

Are we sure that the invariant module cannot get bigger when we extend scalars? I think the answer is no because the multiplicity of 1 as a root of the minimal polynomial of the matrix that encodes the group action. What I am worried about is a situation similar to what happens for a C₄ action over R versus C with the 2 dimensional rotation representation. Do you agree with my reasoning (or have an alternative proof)?

If you are not expecting this to work with pushouts (at least, this is the only reason I know for having the constructor functors), what is your reasoning for adding the construction functor? It starts feeling like unnecessary weight for the class on its own.

Also, I am curious what your thoughts are about the OS/OT algebra invariants not having a construction functor. It seems to suggest that the invariant_module() hook has a deficiency.

[mkoeppe]

comment:14

Yes, this is for pushouts.

[mkoeppe]

comment:15

Replying to Travis Scrimshaw:

Are we sure that the invariant module cannot get bigger when we extend scalars?

Are you asking why the constructed pushout is a correct pushout? In the end, this will depend on the Action doing the right thing on the elements of the larger module. If it doesn't, then all bets are off.

[tscrim]

comment:16

Replying to Matthias Köppe:

Replying to Travis Scrimshaw:

Are we sure that the invariant module cannot get bigger when we extend scalars?

Are you asking why the constructed pushout is a correct pushout? In the end, this will depend on the Action doing the right thing on the elements of the larger module. If it doesn't, then all bets are off.

Ah, right, because it goes through the hook and doesn’t try to simply change the ring of the class. Perhaps then my question is an optimization one. Can we simply just change the base field (IIRC, it doesn’t work over general commutative rings, maybe not even ZZ, but I am not sure offhand) and not go through the (likely expensive) linear algebra computation? Although this creates some issues for subclasses with different construction signatures and forcing things to be overriden… I am wondering if we can find a good solution to that.

[mkoeppe]

comment:17

There will be easy cases and hard cases.

In my immediate application (#34499), it does not matter because the invariant module is not actually computed using linear algebra.

[tscrim]

comment:18

True, and more specific cases (e.g., the FiniteDimensionalInvariantModule) could then implement their own version rather than going through the hook. The invariant_module() hook might need some more thought at some point about its signature since it was just considered in a more local context.

Only thing left is the failures in the (graded) free resolutions. I don’t think they are related, but I don’t know what would cause them to fail in general.

[tscrim]

Reviewer: Travis Scrimshaw

[mkoeppe]

comment:19

Replying to Travis Scrimshaw:

Only thing left is the failures in the (graded) free resolutions. I don’t think they are related, but I don’t know what would cause them to fail in general.

Maybe just someone's broken patchbot? I don't see these failures in the Build&Test run

[mkoeppe]

comment:20

I've run it again locally, with --long. Can't reproduce these failures in sage.homology.

[tscrim]

comment:21

Then it should be unrelated.

[mkoeppe]

comment:22

Thanks for the review!

[vbraun]

Changed branch from u/mkoeppe/construction_for_invariant_equivariant_submodules to 7fe5763