Operads

Discussion board for the specifications of Operads

See http://igd.univ-lyon1.fr/home/chapoton/intro.ps.gz for a short intro to operads

Data representation for operads

We have choosed to use a single domain to represent the full operad, instead of considering it as a collection of vector spaces. So, the underlying linear structure is that of a graded module. Most likely only homogeneous elements will be considered. The degree of an homogeneous element specifies in which space of the operad it lies.

In practice, we have two new categories, Cat::Operad and Cat::?OperadWithBasis which inherits respectively from Cat::?GradedModule and Cat::?GradedModuleWithBasis.

For the moment, we will probably only consider operads with basis, which inherits their data structure from Dom::?FreeModule.

Specifications for the operad basic entries and operations

Proper name for the operad operations?

• composition
• compose
• _fconcat (probably not because _fconcat(f,g,h) is supposed to return the composition of f,g, and h

Order of arguments for computing the composition of f by g at position i in f:

• composition(f, g, i) ?

• composition(i, f, g) ?

  Current (bad) argument: the first order allows to use operators::makeBilinear

  The second version is coherent with partial specialization with respect to i.

• Does it make sense to set composition(f,g,i) to zero when i is bigger than the degree of i? This would allow to have composition(f,g,i) be defined for any choices of f, g, and h.# Unit and embeding of the ground ring

Note: one, oneBasis, fromCoeffRing are the same as in Cat::Algebra/Cat::?AlgebraWithBasis. So, we should setup a common super category. Any suggestions for a good name?

Specifications for the composition $f o g = \sum_i composition(f,g,i)$ ?

Operads with generators

Note: that's a general thing that we are attacking here. The idea is very similar to Cat::?ModuleWithBasis: this category states that there are generators (we used the term basis), and that there is a way to decompose an object in terms of those generators. The same thing should be done coherently for Cat::?AlgebraWithGenerators, Cat::?CommutativeAlgebraWithGenerators, Cat::?LieAlgebraWithGenerators, ...

We need to find a good generic naming scheme, as well as, for each kind of Cat::?BlahWithGenerators, a practical way of representing the decomposition of an element in terms of the generators, generalizing the poly2list approach. From this decomposition, one can then do things like extending functions on the generators into morphisms of the domain.

Note that those categories do not impose that there is no relation between the generators. It's the responsibility of the user to make sure that the functions he defines by extension are indeed compatible with the relations.

A related, but different, thing to do is to define the corresponding free domains (Dom::?FreeModule, Dom::?FreeAlgebra, Dom::?FreeCommutativeAlgebra, ...).

Proposed naming scheme

Cat::?OperadWithGenerators

The category of operads with a distinguished set of generators

dom::operadGenerators

The generators of the operad, as elements of the operad

dom::operadGeneratorsIndices

A combinatorial class which indexes the generators

dom::operadToList

Decomposes an element of the operad in terms of generators Better name?

dom::operadFromList

Reciprocal operation

operadMorphism(f)

Build a morphism of operads from a function f: generator -> ...

Proposed data structure for the representation of the decomposition of an element of the domain in terms of the generators

(c: coeff; g: index of a generator)

Cat::?ModuleWithBasis

[ [ c1, g1], ...]

Cat::?AlgebraWithGenerators

[ [ c1, [ g1, g2, g3, ...] ], ...]

Note: the way exponents are represented here is similar to the one in ?SymmetricFunctions::p/e/h

Cat::?CommutativeAlgebraWithGenerators

[ [ c1, [ [g1, power1], [g2, power2], ...], ...]

Note: that one is very similar to poly2list, except that we use a sparse structure for the exponents, whereas poly2list uses a dense one.

Cat::?LieAlgebraWithGenerators

???

Cat::?OperadWithGenerators

???

Cleanup of the specifications of operators::make*:

Providing a method operadMorphism(f) is fine as long as only one source domain is concerned. Trouble comes when one wants to define bilinear morphisms and such which concern several domains at a time.

My current dream would be to be able to do something like:

operators::morphism(f, Prototype=[ DomA (OperadMorphism),
                                   Dom::Rational,
                                   DomC (AlgebraMorphism),
                                   DomD * (RingMorphism)
                                   -> E ])

That would build a function that is a morphism of operad for its 1st argument, a morphism of algebra wrt its 3rd argument, and a ring morphism wrt all its remaining argument, from a function

 f:  (DomA::generatorsIndices,
      Dom::Rational,
      DomC::generatorsIndices,
      DomD::generatorsIndices *)
     -> E

Any suggestions for a proper syntax for this?

Functors to construct the various algebras and Hopf algebras associated to an operad

Plan: first do the construction by hand on a few examples to get an idea of what is automatizable here.

"Representations" of operads

Same thing.