Submodules of TensorFreeModule defined by the symmetries of a Components object

[mkoeppe]

We generalize FiniteRankFreeModule.tensor_module by giving it optional arguments sym, antisym; if given, a submodule of the tensor module spanned by the tensors with these prescribed symmetries is created.

The new methods symmetric_power and dual_symmetric_power provide two important special cases.

The implementation makes the standard bases of tensor modules (and of their new submodules) explicit objects. The basis method now works for tensor modules, not just the base module, and returns an instance of the new class TensorFreeSubmoduleBasis_sym, which represents the standard basis corresponding to an instance of the Components class (or one of its subclasses).

Follow-ups:

• TensorFreeModule.isomorphism_with_fixed_basis #34427 TensorFreeModule.isomorphism_with_fixed_basis
• Make ExtPowerFreeModule a quotient of TensorFreeModule #30242 Make ExtPowerFreeModule a quotient of TensorFreeModule
• Refactor Components into parent & element #30307 Refactor Components into parent (a ModuleWithBasis) & element

Depends on #30300
Depends on #34424
Depends on #34451
Depends on #34474

CC: @egourgoulhon @tscrim @mjungmath @slel @honglizhaobob

Component: linear algebra

Author: Matthias Koeppe

Branch/Commit: fc66ad1

Reviewer: Eric Gourgoulhon

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

[egourgoulhon]

comment:2

The current design of ExtPowerFreeModule, ExtPowerDualFreeModule and TensorFreeModule is such that they cannot have their own bases, although they are mathematically free modules and they inherit from FiniteRankFreeModule. This is because all the basis management is performed at the level of the base module. Indeed, any choice of basis in the base module gives birth uniquely to a basis in each of the tensor modules and exterior power modules.
For instance:

sage: M = FiniteRankFreeModule(ZZ, 2, name='M')
sage: e = M.basis('e')
sage: t = M.tensor((1, 1), name='t'); t
Type-(1,1) tensor t on the Rank-2 free module M over the Integer Ring

The components are set and displayed with respect to the basis e = (e_0, e_1) of the base module M and its dual basis (e^0, e^1):

sage: t[e, :] = [[1, 0], [-2, 0]]
sage: t.display(e)  # equivalent to t.display()
t = e_0*e^0 - 2 e_1*e^0
sage: t.components(e)
2-indices components w.r.t. Basis (e_0,e_1) on the Rank-2 free module M 
 over the Integer Ring

The same feature holds for ExtPowerDualFreeModule elements:

sage: a = M.alternating_form(2, name='a')
sage: a.parent()
2nd exterior power of the dual of the Rank-2 free module M over the Integer Ring
sage: a[e, 0, 1] = 3
sage: a.display(e)  # equivalent to a.display()
a = 3 e^0/\e^1
sage: a.components(e)
Fully antisymmetric 2-indices components w.r.t. Basis (e_0,e_1) on the Rank-2 
 free module M over the Integer Ring

If we introduce proper bases for the derived modules ExtPowerFreeModule, ExtPowerDualFreeModule and TensorFreeModule, then t.display() would become ambiguous: shall we want a display w.r.t. to the default basis of M or to the default basis of t.parent()? Moreover, the storage of components is currently performed with respect to bases of the base module. Introducing bases in the tensor modules shall of course not lead to duplicate storage.

If we keep this design (which I would favor at this stage), then, for the sake of clarity,

sage: A = M.exterior_power(2)
sage: A.basis('w')

shall return a NotImplementedError and not a TypeError, with a message like only bases on the base module are implemented.

[mkoeppe]

comment:4

Thanks a lot for the explanation.

Yes, a NotImplementedError with a clear message would be an improvement.

It could also be considered whether these three classes should really be subclasses of FiniteRankFreeModule, or perhaps rather a new common baseclass.

[egourgoulhon]

comment:6

Replying to @mkoeppe:

It could also be considered whether these three classes should really be subclasses of FiniteRankFreeModule, or perhaps rather a new common baseclass.

Yes, indeed!

[mkoeppe]

comment:7

Replying to @egourgoulhon:

all the basis management is performed at the level of the base module. Indeed, any choice of basis in the base module gives birth uniquely to a basis in each of the tensor modules and exterior power modules.

Given this, I am also wondering whether perhaps there should be a subclass of Basis_abstract that would make these bases explicit.

[mkoeppe]

Branch: u/mkoeppe/extpowerfreemodule__extpowerdualfreemodule__tensorfreemodule_cannot_create_a_basis

[mkoeppe]

comment:9

Preliminary branch

---

New commits:

862aca8

WIP: Implement TensorFreeModule.basis with new class FreeModuleCompTensorBasis

[mkoeppe]

Commit: 862aca8

[sagetrac-git]

Changed commit from 862aca8 to 3bd0a8a

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

3bd0a8a

TensorFreeSubmodule_comp, TensorFreeSubmoduleBasis_comp: New

[sagetrac-git]

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

c4d8d07

Move basis method to TensorFreeModule

[sagetrac-git]

Changed commit from 3bd0a8a to c4d8d07

[mkoeppe]

comment:13

Here's an early draft, comments welcome

[egourgoulhon]

comment:14

Replying to @mkoeppe:

Here's an early draft, comments welcome

Thanks. It seems that the file tensor_free_submodule_basis.py is missing in the ticket branch.

[sagetrac-git]

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

270ebb3

Add missing file

[sagetrac-git]

Changed commit from c4d8d07 to 270ebb3

[mkoeppe]

comment:16

Sorry, here you go.

[sagetrac-git]

Changed commit from 270ebb3 to 22bb5ac

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

a734bf8	TensorFreeSubmodule_comp, TensorFreeSubmoduleBasis_comp: New
fdd6646	Move basis method to TensorFreeModule
a61f8e7	Add missing file
c01a5e9	FiniteRankFreeModule: Add methods is_submodule, ambient_module
1aedfa4	TensorFreeModule: Remove duplicate method 'basis'
22bb5ac	TensorFreeSubmodule_comp.is_submodule: New

[sagetrac-git]

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

6ed9e40	TensorFreeSubmodule_comp.ambient_module: New
80af815	Fix doctests

[mkoeppe]

comment:121

Thank you!

[sagetrac-git]

Changed commit from 45bf6f3 to fc66ad1

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

803f7e4	Make FiniteRankFreeModule.tensor_module(0, 1) return the dual (#34474)
0648daa	Merge #34474
fc66ad1	FiniteRankFreeModule.dual_symmetric_power: Update for changes in #34474

[mkoeppe]

Changed dependencies from #30300, #34424, #34451 to #30300, #34424, #34451, #34474

[mkoeppe]

comment:123

I've merged #34474 to resolve a merge conflict

---

New commits:

803f7e4	Make FiniteRankFreeModule.tensor_module(0, 1) return the dual (#34474)
0648daa	Merge #34474
fc66ad1	FiniteRankFreeModule.dual_symmetric_power: Update for changes in #34474

[egourgoulhon]

comment:124

Replying to Matthias Köppe:

I've merged #34474 to resolve a merge conflict

OK.

At the moment, we have:

sage: M = FiniteRankFreeModule(ZZ, 2, name='M')
sage: e = M.basis('e')
sage: S = M.tensor_module(2, 0, sym=(0,1))
sage: s = M.tensor((2, 0), sym=(0,1))
sage: s[0,1] = 2
sage: s.display()
2 e_0⊗e_1 + 2 e_1⊗e_0
sage: s.parent() is S
False
sage: s.parent()
Free module of type-(2,0) tensors on the Rank-2 free module M over the Integer Ring

but I guess s.parent() being S should be for a follow-up ticket...

[mkoeppe]

comment:125

Yes, #34482 goes roughly into this direction.

[egourgoulhon]

comment:126

Replying to Matthias Köppe:

Yes, #34482 goes roughly into this direction.

OK very good.

[vbraun]

Changed branch from u/mkoeppe/extpowerfreemodule__extpowerdualfreemodule__tensorfreemodule_cannot_create_a_basis to fc66ad1