Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submodules of TensorFreeModule defined by the symmetries of a Components object #30229

Closed
mkoeppe opened this issue Jul 27, 2020 · 195 comments
Closed

Comments

@mkoeppe
Copy link
Contributor

mkoeppe commented Jul 27, 2020

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:

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

@mkoeppe mkoeppe added this to the sage-9.2 milestone Jul 27, 2020
@mkoeppe mkoeppe changed the title ExtPowerFreeModule and TensorFreeModule cannot create a basis ExtPowerFreeModule, ExtPowerDualFreeModule, TensorFreeModule cannot create a basis Jul 27, 2020
@egourgoulhon
Copy link
Member

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.

@slel

This comment has been minimized.

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Jul 27, 2020

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.

@mkoeppe

This comment has been minimized.

@egourgoulhon

This comment has been minimized.

@egourgoulhon
Copy link
Member

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
Copy link
Contributor Author

mkoeppe commented Jul 27, 2020

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
Copy link
Contributor Author

mkoeppe commented Jul 31, 2020

@mkoeppe

This comment has been minimized.

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Jul 31, 2020

comment:9

Preliminary branch


New commits:

862aca8WIP: Implement TensorFreeModule.basis with new class FreeModuleCompTensorBasis

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Jul 31, 2020

Commit: 862aca8

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 1, 2020

Changed commit from 862aca8 to 3bd0a8a

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 1, 2020

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

3bd0a8aTensorFreeSubmodule_comp, TensorFreeSubmoduleBasis_comp: New

@mkoeppe

This comment has been minimized.

@mkoeppe mkoeppe changed the title ExtPowerFreeModule, ExtPowerDualFreeModule, TensorFreeModule cannot create a basis Submodules of TensorFreeModule defined by the symmetries of a Components object Aug 1, 2020
@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 1, 2020

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

c4d8d07Move basis method to TensorFreeModule

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 1, 2020

Changed commit from 3bd0a8a to c4d8d07

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Aug 1, 2020

comment:13

Here's an early draft, comments welcome

@egourgoulhon
Copy link
Member

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
Copy link
Mannequin

sagetrac-git mannequin commented Aug 1, 2020

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

270ebb3Add missing file

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 1, 2020

Changed commit from c4d8d07 to 270ebb3

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Aug 1, 2020

comment:16

Sorry, here you go.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 3, 2020

Changed commit from 270ebb3 to 22bb5ac

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 3, 2020

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

a734bf8TensorFreeSubmodule_comp, TensorFreeSubmoduleBasis_comp: New
fdd6646Move basis method to TensorFreeModule
a61f8e7Add missing file
c01a5e9FiniteRankFreeModule: Add methods is_submodule, ambient_module
1aedfa4TensorFreeModule: Remove duplicate method 'basis'
22bb5acTensorFreeSubmodule_comp.is_submodule: New

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 3, 2020

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

6ed9e40TensorFreeSubmodule_comp.ambient_module: New
80af815Fix doctests

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 2, 2022

Changed commit from 64e3c1d to 7474abb

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 2, 2022

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

7474abbFiniteRankFreeModule_abstract.tensor_product: Handle submodules with symmetries

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 2, 2022

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

ed3c8d9src/sage/tensor/modules/finite_rank_free_module.py (FiniteRankFreeModule_abstract.is_submodule): Fix typo in doctest

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 2, 2022

Changed commit from 7474abb to ed3c8d9

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 2, 2022

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

fd89892src/sage/tensor/modules/tensor_free_submodule[_basis].py, finite_rank_free_module.py: Update AUTHORS
644933asrc/sage/tensor/modules/finite_rank_free_module.py: Update copyright according to git blame -w --date=format:%Y FILE | sort -k2

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 2, 2022

Changed commit from ed3c8d9 to 644933a

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 2, 2022

Changed commit from 644933a to 45bf6f3

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 2, 2022

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

45bf6f3FiniteRankFreeModule_abstract.tensor_product: Add comment

@egourgoulhon
Copy link
Member

comment:120

Looks good! Thanks.

@egourgoulhon
Copy link
Member

Reviewer: Eric Gourgoulhon

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Sep 4, 2022

comment:121

Thank you!

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 4, 2022

Changed commit from 45bf6f3 to fc66ad1

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 4, 2022

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

803f7e4Make FiniteRankFreeModule.tensor_module(0, 1) return the dual (#34474)
0648daaMerge #34474
fc66ad1FiniteRankFreeModule.dual_symmetric_power: Update for changes in #34474

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Sep 4, 2022

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

@mkoeppe
Copy link
Contributor Author

mkoeppe commented Sep 4, 2022

comment:123

I've merged #34474 to resolve a merge conflict


New commits:

803f7e4Make FiniteRankFreeModule.tensor_module(0, 1) return the dual (#34474)
0648daaMerge #34474
fc66ad1FiniteRankFreeModule.dual_symmetric_power: Update for changes in #34474

@egourgoulhon
Copy link
Member

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
Copy link
Contributor Author

mkoeppe commented Sep 4, 2022

comment:125

Yes, #34482 goes roughly into this direction.

@egourgoulhon
Copy link
Member

comment:126

Replying to Matthias Köppe:

Yes, #34482 goes roughly into this direction.

OK very good.

@mkoeppe mkoeppe modified the milestones: sage-9.7, sage-9.8 Sep 19, 2022
@vbraun
Copy link
Member

vbraun commented Sep 22, 2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants