See http://igd.univ-lyon1.fr/home/chapoton/intro.ps.gz for a short intro to 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::?

OperadWithBasiswhich inherits respectively from Cat::?GradedModuleand Cat::?GradedModuleWithBasis.For the moment, we will probably only consider operads with basis, which inherits their data structure from Dom::?

FreeModule.

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?

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

- Cat::?

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__ - ???

- Cat::?

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?

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

Same thing.