Tensors on free modules of finite rank
49 views
Skip to first unread message
Eric Gourgoulhon
Mar 10, 2014, 12:09:01 PM3/10/14
to sage-...@googlegroups.com
Hi,
A new enhancement, devoted to tensors on generic free modules of finite rank, has been submitted to trac (ticket #15916). By *generic*, it is meant *without any distinguished basis*.
Description
This ticket implements:
- tensor products of the type M\otimes ...\otimes M \otimes M^* \otimes...\otimes M^* (k factors of M and l factors of M*, say)
where M is a free module of finite rank over a commutative ring R and M^* is its dual
- the elements of the above tensor products, considered as tensors of type (k,l) on M, i.e. multilinear forms (M^*)^k \times M^l --> R, thanks to the canonical isomorphism M^** = M (which holds since M is a free module of finite rank)
- the following tensor operations:
* operations inherent to the module structure (addition, multiplication by a ring element)
* tensor product of two tensors
* tensor contraction
* symmetry / antisymmetry handling (on subset of the tensor arguments or on all arguments)
* exterior product of alternating forms
No distinguished basis is assumed on the free module M; on the contrary many bases can be introduced. Each tensor has then various representations, via its components in the various bases.
Motivation and context
The ticket has been motivated by tensors on smooth manifolds over \RR, within the SageManifolds project. In this context, tensors on free modules appear at two places:
- tensors on tangent spaces:
* commutative ring R = real field \RR
* free module M = tangent vector space at a given manifold's point
- tensor fields on a manifold:
* commutative ring R = the set C^\infty(N) of smooth functions N--> \RR, where N is a parallelizable open set of the manifold
* free module M = the set X(N) of smooth vector fields on N (since N is parallelizable, this is a free module; its rank is the manifold's dimension)
Documentation
Apart from the numerous doctests in the code, some pieces of documentation are
- the tutorial worksheet posted here (the pdf version is here)
- the reference manual (the pdf version is here); it can also be generated via the command
sage -docbuild tensors_free_module html
See also this page.
Remarks
1/ Although developed in the context of SageManifolds, the ticket is self-contained and does not depend on other parts of SageManifolds. It this respect, it can be viewed as some attempt to include a first subset of SageManifolds in Sage, with a moderate size: the ticket comprises 9391 lines of Python code (most of them being doctests), while at present SageManifolds contains 29240 lines of code.
2/ The ticket follows Sage's Parent/Element scheme and the (new) category framework. In particular, the ticket's free module class (FiniteFreeModule) passes the module TestSuite.
3/ It turned out to be necessary to develop a new class to implement free modules of finite rank. Indeed, the category of free modules does not exist yet in Sage: only those of generic modules (Modules) or free modules with a distinguished basis (ModulesWithBasis) are available. Now, the tangent space at a given point of a manifold is a vector space without any distinguished basis (in other words, while the tangent space is isomorphic to \RR^n, there is no *canonical* isomorphism, each isomorphism relying on the choice of some coordinate chart). The new class, FiniteFreeModule, does not rely on any distinguished basis. It inherits directly from sage.modules.module.Module. In particular, it does not inherit from sage.modules.module.Module_old.FreeModule_generic since the latter does not conform to the new coercion model and seems to assume a distinguished basis (cf. its method basis()).
Eric.
A new enhancement, devoted to tensors on generic free modules of finite rank, has been submitted to trac (ticket #15916). By *generic*, it is meant *without any distinguished basis*.
Description
This ticket implements:
- tensor products of the type M\otimes ...\otimes M \otimes M^* \otimes...\otimes M^* (k factors of M and l factors of M*, say)
where M is a free module of finite rank over a commutative ring R and M^* is its dual
- the elements of the above tensor products, considered as tensors of type (k,l) on M, i.e. multilinear forms (M^*)^k \times M^l --> R, thanks to the canonical isomorphism M^** = M (which holds since M is a free module of finite rank)
- the following tensor operations:
* operations inherent to the module structure (addition, multiplication by a ring element)
* tensor product of two tensors
* tensor contraction
* symmetry / antisymmetry handling (on subset of the tensor arguments or on all arguments)
* exterior product of alternating forms
No distinguished basis is assumed on the free module M; on the contrary many bases can be introduced. Each tensor has then various representations, via its components in the various bases.
Motivation and context
The ticket has been motivated by tensors on smooth manifolds over \RR, within the SageManifolds project. In this context, tensors on free modules appear at two places:
- tensors on tangent spaces:
* commutative ring R = real field \RR
* free module M = tangent vector space at a given manifold's point
- tensor fields on a manifold:
* commutative ring R = the set C^\infty(N) of smooth functions N--> \RR, where N is a parallelizable open set of the manifold
* free module M = the set X(N) of smooth vector fields on N (since N is parallelizable, this is a free module; its rank is the manifold's dimension)
Documentation
Apart from the numerous doctests in the code, some pieces of documentation are
- the tutorial worksheet posted here (the pdf version is here)
- the reference manual (the pdf version is here); it can also be generated via the command
sage -docbuild tensors_free_module html
See also this page.
Remarks
1/ Although developed in the context of SageManifolds, the ticket is self-contained and does not depend on other parts of SageManifolds. It this respect, it can be viewed as some attempt to include a first subset of SageManifolds in Sage, with a moderate size: the ticket comprises 9391 lines of Python code (most of them being doctests), while at present SageManifolds contains 29240 lines of code.
2/ The ticket follows Sage's Parent/Element scheme and the (new) category framework. In particular, the ticket's free module class (FiniteFreeModule) passes the module TestSuite.
3/ It turned out to be necessary to develop a new class to implement free modules of finite rank. Indeed, the category of free modules does not exist yet in Sage: only those of generic modules (Modules) or free modules with a distinguished basis (ModulesWithBasis) are available. Now, the tangent space at a given point of a manifold is a vector space without any distinguished basis (in other words, while the tangent space is isomorphic to \RR^n, there is no *canonical* isomorphism, each isomorphism relying on the choice of some coordinate chart). The new class, FiniteFreeModule, does not rely on any distinguished basis. It inherits directly from sage.modules.module.Module. In particular, it does not inherit from sage.modules.module.Module_old.FreeModule_generic since the latter does not conform to the new coercion model and seems to assume a distinguished basis (cf. its method basis()).
Eric.
John H Palmieri
Mar 10, 2014, 12:30:15 PM3/10/14
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Quick question: why not use the class sage.modules.free_module.FreeModule_generic?
Longer question/comment (not directed at you, but at the general situation in Sage): is it a problem to have multiple parallel developments of free modules, one in sage.modules.free_module, one in sage.combinat.free_module, and then possibly a new one in this ticket? (It doesn't seem like a good idea to me.) Should they all be unified somehow? Are there any plans to do that? For my own uses, the version in combinat.free_module has been the most relevant, but it's not in an obvious place; there is nothing intrinsically combinatorial about it, is there? We could move it to sage.module.free_module_with_basis, for example...
John
Longer question/comment (not directed at you, but at the general situation in Sage): is it a problem to have multiple parallel developments of free modules, one in sage.modules.free_module, one in sage.combinat.free_module, and then possibly a new one in this ticket? (It doesn't seem like a good idea to me.) Should they all be unified somehow? Are there any plans to do that? For my own uses, the version in combinat.free_module has been the most relevant, but it's not in an obvious place; there is nothing intrinsically combinatorial about it, is there? We could move it to sage.module.free_module_with_basis, for example...
John
Eric Gourgoulhon
Mar 10, 2014, 1:29:41 PM3/10/14
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Le lundi 10 mars 2014 17:30:15 UTC+1, John H Palmieri a écrit :
Quick question: why not use the class sage.modules.free_module.FreeModule_generic?
I first intended to use it but then I realized that this class does not conform to the new coercion model: it inherits from sage.modules.module.Module_old
So I though that to start a new project, it is better not to use it.
(Sorry I mispelled the full name of the class in my message: it is sage.modules.free_module.FreeModule_generic and not sage.modules.module.Module_old.FreeModule_generic).
Probably the best thing would be to introduce a new category FreeModules.
I hope to discuss / work on this during SageDay 57.
Longer question/comment (not directed at you, but at the general situation in Sage): is it a problem to have multiple parallel developments of free modules, one in sage.modules.free_module, one in sage.combinat.free_module, and then possibly a new one in this ticket? (It doesn't seem like a good idea to me.) Should they all be unified somehow? Are there any plans to do that? For my own uses, the version in combinat.free_module has been the most relevant, but it's not in an obvious place; there is nothing intrinsically combinatorial about it, is there? We could move it to sage.module.free_module_with_basis, for example...
I guess this is a good topic for discussion at SD 57.
Eric.
Nicolas M. Thiery
Mar 10, 2014, 1:36:39 PM3/10/14
to sage-comb...@googlegroups.com, sage-...@googlegroups.com
On Mon, Mar 10, 2014 at 09:30:15AM -0700, John H Palmieri wrote:
> Longer question/comment (not directed at you, but at the general situation
> in Sage): is it a problem to have multiple parallel developments of free
> modules, one in sage.modules.free_module, one in
> sage.combinat.free_module, and then possibly a new one in this ticket? (It
> doesn't seem like a good idea to me.) Should they all be unified somehow?
> Are there any plans to do that? For my own uses, the version in
> combinat.free_module has been the most relevant, but it's not in an
> obvious place; there is nothing intrinsically combinatorial about it, is
> there? We could move it to sage.module.free_module_with_basis, for
> example...
Yes, there is a plan which is along the lines you point out: see #10673
> Longer question/comment (not directed at you, but at the general situation
> in Sage): is it a problem to have multiple parallel developments of free
> modules, one in sage.modules.free_module, one in
> sage.combinat.free_module, and then possibly a new one in this ticket? (It
> doesn't seem like a good idea to me.) Should they all be unified somehow?
> Are there any plans to do that? For my own uses, the version in
> combinat.free_module has been the most relevant, but it's not in an
> obvious place; there is nothing intrinsically combinatorial about it, is
> there? We could move it to sage.module.free_module_with_basis, for
> example...
Eric's free modules are of a different nature though, since it's about
having several/may bases simultaneously and handling the changes of
bases.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
Nicolas M. Thiery
Mar 10, 2014, 1:39:41 PM3/10/14
to sage-comb...@googlegroups.com, sage-...@googlegroups.com
On Mon, Mar 10, 2014 at 04:48:14PM +0000, Simon King wrote:
> Is it a problem to have a multitude of different implementations of
> polynomials in Sage?
>
> All different implementations of polynomial rings inherit from a base class
> that is specific to polynomials. However, sage.modules.free_module.FreeModule_generic
> inherits from sage.modules.Module_old, whereas sage.combinat.free_module.CombinatorialFreeModule
> (which is a bad choice of a name, I think) inherits from sage.modules.module.Module
> (not Module_old). That's suspicious.
In both cases, I believe the most important is that the various
implementations inherit from the same category. And then, if really
useful, from a common class.
> Is it a problem to have a multitude of different implementations of
> polynomials in Sage?
>
> All different implementations of polynomial rings inherit from a base class
> that is specific to polynomials. However, sage.modules.free_module.FreeModule_generic
> inherits from sage.modules.Module_old, whereas sage.combinat.free_module.CombinatorialFreeModule
> (which is a bad choice of a name, I think) inherits from sage.modules.module.Module
> (not Module_old). That's suspicious.
In both cases, I believe the most important is that the various
implementations inherit from the same category. And then, if really
useful, from a common class.
Eric Gourgoulhon
Mar 10, 2014, 3:08:55 PM3/10/14
to sage-...@googlegroups.com, sage-comb...@googlegroups.com, Nicolas M. Thiery
Le lundi 10 mars 2014 18:36:39 UTC+1, Nicolas M. Thiéry a écrit :
Yes, there is a plan which is along the lines you point out: see #10673
Eric's free modules are of a different nature though, since it's about
having several/may bases simultaneously and handling the changes of
bases.
That's the point: one cannot say that the tangent space at a given point of a manifold is R^n: it is instead a generic n-dimensional vector space over R. The identification (isomorphism) with R^n relies on some specific choice of a coordinate chart (or more generally of a local frame). Hence the need for *generic* free modules, with arbitrary bases on them.
Eric.
Travis Scrimshaw
Mar 10, 2014, 6:45:58 PM3/10/14
to sage-comb...@googlegroups.com, sage-...@googlegroups.com
Although at some point we do need to unify CombinatorialFreeModule with the other sage (sparse) modules. However I am opposed to a category for free modules since they are the same object. Instead I would put common functionality into a common base class which implements a generic coercion map between its various subclasses.
Best,
Travis
Reply all
Reply to author
Forward
0 new messages