GUAVA projects, problems and bugs

This is a web page for to-do projects, known problems and bugs for GUAVA 2.4. These have all been corrected in GUAVA 3.1, which is the latest version.

GUAVA projects

An algorithm (even a slow one) for IsEquivalent which does not require Leon's external C code should be implemented.
Further improvement of the AutomorphismGroup and PermutationGroup commands would be welcomed.
Algorithms for (multi-point) algebraic geometric codes associated to plane curves should be programmed and "special" decoding methods should be implemented. In general, this required an implementation of routines to compute the Riemann-Roch space of a divisor.
The ViewObj method for generator matrices should be changed.
Codes on bipartite graphs (Tanner, IEEE Trans Info Theory 27, 1981), expander codes (Sipser and Spielman , IEEE Trans Info Theory 42, 1996), and "special" decoding methods should be implemented.
"good" LDPC codes (the literature is huge) should be constructed and "special" decoding methods should be implemented.
Expand on the group actions on "classical" Goppa codes. There is already a start of this in GUAVA 2.4. What is needed (other than probably correcting some bugs) is a way to determine (using GAP and maybe the connection with Atlas) which representations arise from these group actions. This type of thing is looked at in section 5.7 of the GUAVA manual http://cadigweb.ew.usna.edu/~wdj/gap/GUAVA/htm/chap5.html#s7ss21
All of Leon's C code (which is distributed with GUAVA and is used to make certain computations much faster) should be rewritten slightly (using finite field routines from NTL, for example) and bug-checked.
Number field codes (also called "Chinese remainder codes" or "arithmetic residue codes", see for example pdf paper) should be constructed and "special" decoding methods should be implemented. ("Fast" decoding methods are theoretically of some interest.)

Known GUAVA bugs

GAP version 4.4.2 and earlier contained a problem in the non-commented and undocumented GAP kernel function 'DIST_VEC_CLOS_VEC' (discovered by Christian Ringe and Frank Luebeck). This has been corrected.

C1+C2 (where C1 and C2 are linear codes) does not seem to work. However, DirectSumCode(C1,C2) does.

Cary Huffman discovered some very obscure bugs in Leon's programs for computing automorphism group of a code - the command hangs (or has other odd behavior) in rare examples. This is being looked into. Here is one of his examples:

#buggy example for AutomorphismGroup(C);
G:=Z(2)*[ [ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,1, 1, 0, 0, 0, 0, 0, 0, 0, 0 ],\
[ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1,0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 1 ],\
[ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0,1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 1, 1 ],\
 [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0 ],\
[ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1 ],\
[ 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0,1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0 ],\
[ 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0 ],\
 [ 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0,1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0 ],\
[ 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0,1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0 ],\
 [ 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1,0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ],\
[ 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0,1, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ],\
 [ 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1,0, 1, 1, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ],\
[ 0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,1, 1, 1, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ],\
 [ 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 1, 1,1, 1, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ],\
[ 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 1, 1, 1,1, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ],\
 [ 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1, 0, 0,1, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ],\
[ 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 1, 0, 0, 1,1, 0, 1, 0, 0, 0, 1, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0 ] ];

This is the generator matrix of a binary [34,17,6] code which should have an automorphism group of size 192.

There is a bug in inform.c, as reported in an email from 10-23-2006 below:

My name is Ian McLoughlin. I'm a PhD student at the National
University of Ireland, Galway. I'm emailing you because you are listed
on its website as the maintainer of the GAP package Guava so apologies
if I have the wrong person.

I tried compiling Guava 2.7 today and it failed. I'm using GCC
4.1.1(from gcc --version: "gcc (GCC) 4.1.1 (Gentoo 4.1.1)").

The problem was with the file
gap4r4/pkg/guava2.7/src/leon/src/inform.c. In it the obsolete macro
CLK_TIC is used. I think it should be changed to CLOCKS_PER_SEC(see
http://www.gnu.org/software/libc/manual/html_node/CPU-Time.html#CPU-Time
and search for CLK_TCK).

There are about 15 occurances of CLK_TCK in inform.c. Changing all of
them to CLOCKS_PER_SEC enabled me to compile Guava without any more
problems(although I haven't tested it much so it could cause runtime
errors).

Not a bug but something to be aware of:
```
gap> x:=Indeterminate(GF(2));;pol:=x^3+x+1;;
gap> H:=GeneratorPolCode(pol,7,GF(2));
gap> IsEquivalent(H,HammingCode(3,GF(2)));
```
This does not work on a windows OS. This may be because the command IsEquivalent calls an external program (which requires a linux/unix system) from J. S. Leon for dealing with automorphism groups of codes and isomorphism testing functions. If this program is not installed correctly then command IsEquivalent (as well as AutomorphismGroup) will not work.

Last modified 11-7-2007 by wdj. Homepage, GUAVA