[sage-combinat-devel] Re: Tensors on free modules of finite rank

2014-03-10 Thread Travis Scrimshaw 
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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Tensors on free modules of finite rank

2014-03-10 Thread Eric Gourgoulhon 

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.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Tensors on free modules of finite rank

2014-03-10 Thread Nicolas M. Thiery 
On Mon, Mar 10, 2014 at 04:48:14PM +, 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.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Tensors on free modules of finite rank

2014-03-10 Thread Nicolas M. Thiery 
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

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" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Tensors on free modules of finite rank

2014-03-10 Thread Eric Gourgoulhon 


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. 

>   John
>
>
>
> On Monday, March 10, 2014 9:09:01 AM UTC-7, Eric Gourgoulhon wrote:
>>
>> 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/ I

[sage-combinat-devel] Re: Tensors on free modules of finite rank

2014-03-10 Thread Simon King 
Hi John,

On 2014-03-10, 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,

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.

> 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.)

+1

Instead of implementing a new version of free modules, one should
perhaps modernise the old sage.modules.module.Module

> 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...

+1

If I was to implement a module, I would of course look into sage.modules
first, but wouldn't guess that sage.combinat is relevant.

Best regards,
Simon


-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Tensors on free modules of finite rank

2014-03-10 Thread John H Palmieri 
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



On Monday, March 10, 2014 9:09:01 AM UTC-7, Eric Gourgoulhon wrote:
>
> 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_g