Some tests in sage.coding.* are very slow
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.
Comments (6)
-
reporter -
repo owner Up.
-
repo owner 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
andExtendedBinaryGolayCode
.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...
-
reporter 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.
-
repo owner Agreed.
Note that some of these are actually very, very easy to change. For instance,
Extended[Binary | Ternary]GolayCode
just returns aLinearCode
whose generator matrix is hardcoded in the function. AsBinary[Ternary]GolayCode
also returns aLInearCode
built form a hardcoded matrix, we can remove theExtended
methods while introducing our newExtendedCode
class.If one needs to extend a
Binary/Ternary Golay code
later one, wellC = codes.BinaryGolayCode() Cext = codes.ExtendedCode(C)
will do the same, in a better way.
-
reporter Heh, yeah that seems like a safe bet :-) Nothing can be less informative than simply a
LinearCode
. - Log in to comment
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...