# The Operads package

This is an implementation of the operadic Buchberger algorithm from Vladimir Dotsenko & Anton Khoroshkin: Groebner bases for operads (arXiv:0812.4069).

In writing this package, invaluable help has been given by Vladimir Dotsenko and Eric Hoffbeck.

The user is recommended to run this from within the GHC interpreter for exploration, and to write small Haskell scripts for batch processing. We hope herewithin to give enough of an overview of the available functionality to help the user figure out how to use the software package.

A declaration of a new variable is done in a Haskell script by a statement on the form

var = value

and in the interpreter by a statement on the form

let var = value

Using these, the following instructions should help get you started. I will be writing the instructions aiming for use in the interpreter, for quick starts.

It is possible to force types by following a declaration by :: and the type signature you'll which. This enables you, for instance, to pick a ground ring without having to set coefficients explicitly - see the examples below.

Note that the Buchberger algorithm in its current shape expects at least a division ring as scalar ring.

The expected workflow for a normal user is as follows.

write the generators of the operadic ideal using

`corolla`

and`leaf`

to construct buildingblocks and`nsCompose`

,`shuffleCompose`

and`symmetricCompose`

to assemble them into trees. The trees, subsequently, may be assembled into tree polynomials by

picking an ordering. We have currently

`PathLex`

and`ForestLex`

implemented, and recommend using`PathLex`

.assembling trees and coefficients into an element of the free operad, using

`+`

for addition of operadic elements and`.*.`

for scalar multiplication.

Useful functions for doing this includes, furthermore:

`oet`

- takes a tree and an ordering and gives an operad element. You will have to
specify the relevant type for this to work -- but we provide the extra type
`FreeOperad`

that only asks for a*LabelType*to cover most common uses:

oet tree :: OperadElementLabelTypeScalarType/TreeOrdering

`oek`

- takes a tree, an ordering and a coefficient and gives an operad element

oek tree PathLex (3::Rational)

Example:

let t1 = nsCompose 1 (corolla`a`

[2,1]) (corolla`b`

[1,2]) let b = corolla`l`

[1,2] let lb1 = shuffleCompose 1 [1,2,3] b b let lb2 = shuffleCompose 1 [1,3,2] b b let lb3 = shuffleCompose 2 [1,2,3] b b let lo1 = oet lb1 :: FreeOperad Char let lo2 = oet lb2 :: FreeOperad Char let lo3 = oet lb3 :: FreeOperad Char

Note that while the Haskell compiler in general is very skilled at guessing types of objects, the system guessing will give up if the type is not well defined. There are several different monomial orders allowed, and they are encoded in the type system -- hence the need to annotate the instantiation of elements in the free operad with appropriate types.

assemble all generators into a list. Lists are formed by enclosing the elements, separated by commas, in square brackets. Lists must have identical type on all its elements - hence, for instance, you cannot have operadic elements with different monomial orderings in the same list.

Example:

let lgb = [lo1 - lo2 - lo3, 2.*.lo1 + 3.*. lo3]

run the algorithm on your basis and wait for it to finish. The entry point to the Buchberger algorithm is, not surprisingly,

`operadicBuchberger`

.

Example:

let grobner = operadicBuchberger lgb

The output of `operadicBuchberger`

, if it finishes, is a finite Gröbner basis for the ideal spanned
by the original generators. If this is quadratic then the operad presented by this ideal is Koszul -
this may be tested with something like:

all (==2) $ concatMap operationDegrees grobner

If you wish to inspect elements yourself, the recommended way to do it is by using the `pP`

function,
which outputs most of the interesting elements in a human-readable format. For objects that don't work
with pP, just writing the variable name on its own will print it in some format.

The difference here is related to the ability to save computational states to disk. There are two
different functions that will represent a tree or an element of an operad as a String: `show`

and `pp`

.
Using the former guarantees (with the same version of the source code) that the data can be read back
into the system and reused later one; whereas using `pp`

will build a human readable string.

[Skip to Readme]

## Properties

Versions | 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 1.0 |
---|---|

Change log | CHANGELOG |

Dependencies | array, base, containers, mtl, QuickCheck [details] |

License | BSD3 |

Copyright | © 2009 Mikael Vejdemo Johansson |

Author | Mikael Vejdemo Johansson |

Maintainer | mik@stanford.edu |

Category | Math |

Home page | http://math.stanford.edu/~mik/operads |

Bug tracker | mailto:mik@stanford.edu |

Uploaded | Wed Apr 29 09:15:23 UTC 2009 by MikaelVejdemoJohansson |

Distributions | NixOS:1.0 |

Executables | OperadTest |

Downloads | 2393 total (209 in the last 30 days) |

Rating | (no votes yet) [estimated by rule of succession] |

Your Rating | |

Status | Docs not available [build log] All reported builds failed as of 2017-01-01 [all 8 reports] Hackage Matrix CI |

## Modules

*Math*- Math.Operad

## Flags

Name | Description | Default | Type |
---|---|---|---|

mapoperad | Use the Data.Map based storage for formal linear combinations. | Disabled | Automatic |

polybag | Use the head bag based storage for formal linear combinations. | Disabled | Automatic |

Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info

## Downloads

- Operads-0.5.tar.gz [browse] (Cabal source package)
- Package description (included in the package)