Some tests in sage.coding.* are very slow

[Johan Rosenkilde]

Some of the long-tests in sage.coding.* are among the very slowest of all tests in Sage. This is the top of the output of my latest run of make ptestlong:

sage -t --long src/sage/coding/codecan/autgroup_can_label.pyx
    [82 tests, 12.39 s]
sage -t --long src/sage/coding/code_constructions.py
    [232 tests, 11.29 s]
sage -t --long src/sage/coding/delsarte_bounds.py
    [19 tests, 2.80 s]
sage -t --long src/sage/coding/codecan/codecan.pxd
    [0 tests, 0.00 s]
sage -t --long src/sage/coding/code_bounds.py
    [37 tests, 6.22 s]
sage -t --long src/sage/coding/codecan/codecan.pyx
    [69 tests, 2.63 s]
sage -t --long src/sage/coding/source_coding/huffman.py
    [62 tests, 1.84 s]
sage -t --long src/sage/misc/dev_tools.py
    [63 tests, 1.10 s]
sage -t --long src/sage/coding/channel_constructions.py
    [77 tests, 0.18 s]
sage -t --long src/sage/coding/sd_codes.py
    [18 tests, 0.17 s]
...

That's a complete misunderstanding of the point of doc-tests. Much smaller examples should be found and used instead.

[Johan Rosenkilde]

Ok, so some of the later tests are actually much slower. But still, there's no reason that code_constructions should be so slow. Some of the long tests are due to a completely unnecessary minimum distance computation...

[David Lucas]

Up.

[David Lucas]

Well, I browsed through the class, and there's indeed a lot of useless doctests. Furthermore, there's also a lot of code "classes" which seem completely useless to me, like having ExtendedTernaryGolayCode and ExtendedBinaryGolayCode.

I suggest we just let this on stand-by for now, and completely clean this file (doctests + methods) at some point in the future.

I don't find that really useful to fix doctests of method that should be removed...

[Johan Rosenkilde]

I agree. Those code-building functions should die at some point, but it might not be within the lifetime of ACTIS. We basically have to balance spending time on 1) cleaning up functionality we don't really care about so that the whole coding theory package is presented well; or 2) adding new, awesomer functionality we're actually proud of. Considering that we are 2/3 through ACTIS now, I vote for only doing 1)-things when they are buggy or extremely glaring.

[David Lucas]

Agreed.

Note that some of these are actually very, very easy to change. For instance, Extended[Binary | Ternary]GolayCode just returns a LinearCode whose generator matrix is hardcoded in the function. As Binary[Ternary]GolayCode also returns a LInearCode built form a hardcoded matrix, we can remove the Extended methods while introducing our new ExtendedCode class.

If one needs to extend a Binary/Ternary Golay code later one, well

C = codes.BinaryGolayCode()
Cext = codes.ExtendedCode(C)

will do the same, in a better way.

[Johan Rosenkilde]

Heh, yeah that seems like a safe bet :-) Nothing can be less informative than simply a LinearCode.