#Main Codes#

We mainly design the framework around the notion of a block linear code. The framework will provide main codes families, should be flexible enough to manipulate standard codes with puncturing, concatenation, direct product), and it should be easy to complement it and add new codes for a seasoned programmer. We will implement

(Generalised) Reed-Solomon codes
Cyclic codes
Alternant codes, Classical Goppa codes (not AG)
Reed-Muller, Hamming, Simplex, Hadamard codes (binary and q-ary)

and modifiers and combinators

Duality
Subfield subcode
Concatenation, Product
Puncturing, Shortening, Extending

These modifiers will preserve as much functionality as possible from the parent code, i.e. bounds on minimum distance, decoding algorithms, etc. We will provide tools for benchmarking and simulating channels.

#More Codes # As the project mature, we may consider, with the help of interested people

LDPC
Polar codes
Algebraic-Geometry codes

We do not aim at providing full functionalities for convolutional codes, poly-alphabetic codes, codes over rings, non-linear codes, quantum codes.

#Bound and tables# We have in mind to provide the classical bounds, perhaps perform dynamic lookup on codetables, etc.

Functionality for any linear block code

Basic

Computing k precisely
Encoding/Unencoding
Information set
Systematic encoding

Functionality for any linear block code

Basic

Computing k precisely
Encoding/Unencoding
Information set
Systematic encoding

Advanced

Computing minimum distance precisely
Information Set Decoding. Warning: there are numerous variants and much recent progress. As usual, binary codes is a very special case.
Support Splittting Algorithm
Weight distribution, McWilliams transform
Wagner's algorithm. It is an exponentail decoding algorithm where there are exponentially many solutions (high error rate). Based on generalization of birthday paradix.

A modifier should preserve as much functionality as possible from the parent code, i.e. bounds on minimum distance, decoding algorithms, etc.

Possible other modifiers

Generalised concatenation

notations and definitions

After basic design and roadmap has been laid out (~3 months)

People interested at this point are those who already have a relatively strong interest in Sage, but that have not yet used Sage (or haven't done so systematically) for their research or teaching in coding theory. This could include people who currently use Magma but would like to switch.

People that we get hooked at this stage will have a good chance of providing useful feedback on our design (while there is still time for medium and major changes), and of being reviewers of Sage code later on.

Suggested people:

Alexander Zeh and Antonia Wachter-Zeh
Fernando Pinero
Jean-Louis Roch
Ulm team: Mostafa Mohammed, Sven Puchinger and Sven Mülich

Once we have several code classes etc. already accepted in Sage ... (6-9 months)

At this point, it will be much more clear how much can be accomplished in this project, and we will be able to present very convincing and strong examples of what can be done. Also, we will be quickly closing the gap to what Magma provides, and can therefore provide convincing arguments that if free of choice, researchers in coding theory should use Sage. "Discussion" of the design can take place on a much higher level since a lot of code is already in place.

Therefore, we can reach people who are not particularly that interested in Sage to begin with, or senior researchers who do not have the time to join on the detailed side. We should also try to reach early researchers and PhDs.

Suggested people - Daniel Bernstein - PhD advisors around the world

(Who?)

##Quality insurance## * We will reference our code, provide academic references, preferably with open access, for the algorithms, notions,

For the Sage Coding Day (~18 months)

Idea: Make it a "Sage for Coding and Combinatorics" and co-organise with Nathann Cohen?

Interface with Other Domains

By "Interface", we mean both in terms of theory, and in terms of concrete Sage design.

Crypto:
- McEliece
- Sidelnikov-Shestakov attack?
Lattices:

(codes from lattices and vice versa).

Damien Stehle?
Matroids:

?
Designs :

?

Discussions on Design

Compiling Sage

When checking out this repository for the first time, simply run make in the folder to build Sage. If you are lucky, all goes well and a few hours later, Sage is built.
After git pulling a new version from the repo, run sage -br to rebuild Sage much quicker. This usually takes only a few minutes, depending on the changes that were pulled.

When Sage makes a new release, beta or stable, this repository will merge in the changes of that release. Occasionally, this has so deep changes that sage -br is not sufficient (i.e. the build may fail with strange errors, or Sage starts behaving weirdly). In that case, the safest is to do a full recompilation:
```
make distclean
make
```
The most time-consuming part of compiling Sage is ATLAS, the linear algebra package, which on almost any system runs a series of tuning tests which takes several hours. One can avoid the recompilation of ATLAS (whenever doing an otherwise full recompilation as above) by "caching" the previous compilation of ATLAS:
1. Create an empty folder outside the folder tree of this repository, e.g. in ~/local/atlas. We'll call this path $ATLAS.
2. Goto the folder <sage-path>/local/lib.
3. Copy all the files libatlas.*, libcblas.*, libf77blas.*, liblapack.*, libptcblas.*, libptf77blas.* into $ATLAS.
4. Before running the above full recompilation, set the SAGE_ATLAS_LIB environment variable to $ATLAS. To avoid forgetting this, you can create a small script to do this, e.g.
```
#!/bin/bash
export SAGE_ATLAS_LIB=$HOME/local/atlas
time make
```
The Sage compilation process can also run in multiple processes in parallel. For this simply invoke make with a specific flag: make -j2 in order to use e.g. two processes.

WARNING: My (jsrn) builds have multiple times failed when attempting to run in parallel.

An interesting thread about make behaviour and strategy on sage-devel : https://groups.google.com/forum/#!topic/sage-devel/CZ5HNKsOmSk

About the Wiki

This wiki uses the Markdown syntax.

The wiki itself is actually a git repository, which means you can clone it, edit it locally/offline, add images or any other file type, and push it back to us. It will be live immediately.

Go ahead and try:

$ git clone https://lucasdavid@bitbucket.org/lucasdavid/sage_coding_project.git/wiki

Wiki pages are normal files, with the .md extension. You can edit them locally, as well as creating new ones.

Syntax highlighting

You can also highlight snippets of text (we use the excellent Pygments library).

Here's an example of some Python code:

#!python

def wiki_rocks(text):
    formatter = lambda t: "funky"+t
    return formatter(text)

You can check out the source of this page to see how that's done, and make sure to bookmark the vast library of Pygment lexers, we accept the 'short name' or the 'mimetype' of anything in there.