I'm copying this question from over at SO, since there is no tag about the MAGMA cas over there, as I only just figured out. Hope someone can answer over here. Not asking for migration because I've been waiting for an answer for a month and over now, and I don't want to risk waiting even longer for the migration to happen. Perhaps this is off-topic. I'll bear the closure.
We devised a function in class to test if the nilpotency class of a group is or not the sum of those of its p-Sylows. The original was the first one below, without the
n:=NilpotencyClass(G)line. I got a strange result, as you will see below. The teacher got a different strange result:3 1. But the groupGwasn't abelian, so we would have found a non-Abelian class 1 nilpotent group, which is absurd. Then we tried isolating the function, also because a classmate of mine had the function properly working. That solved the problem. Curious about this mystery, I tried to isolate the problem, and found it came straight out of the function. I tried calculating the returnedNilpotencyClassat the start of the function and it worked. If I don't, even outside the function I still getNilpotencyClass(G)=32767! So I have the following code:
TestNilpotencyClass := function(G)
n:=NilpotencyClass(G);
if not IsNilpotent(G) then
return 0;
end if;
N := #G;
somma := 0;
for pn in Factorisation(N) do
p := pn[1];
P := SylowSubgroup(G,p);
c := NilpotencyClass(P);
somma +:= c;
end for;
return somma, n;
end function;
TestNilpotencyClassb := function(G)
if not IsNilpotent(G) then
return 0;
end if;
NilpotencyClass(G);
N := #G;
somma := 0;
for pn in Factorisation(N) do
p := pn[1];
P := SylowSubgroup(G,p);
c := NilpotencyClass(P);
somma +:= c;
end for;
return somma, NilpotencyClass(G);
end function;
TestNilpotencyClassc := function(G)
if (not IsNilpotent(G)) then
return 0;
end if;
NilpotencyClass(G);
N := #G;
somma := 0;
for pn in Factorisation(N) do
p := pn[1];
P := SylowSubgroup(G,p);
c := NilpotencyClass(P);
somma +:= c;
end for;
return somma, NilpotencyClass(G);
end function;
TestNilpotencyClassd := function(G)
if (not (IsNilpotent(G))) then
return 0;
end if;
NilpotencyClass(G);
N := #G;
somma := 0;
for pn in Factorisation(N) do
p := pn[1];
P := SylowSubgroup(G,p);
c := NilpotencyClass(P);
somma +:= c;
end for;
return somma, NilpotencyClass(G);
end function;
G:=SmallGroups(40)[11];
TestNilpotencyClass(G);
TestNilpotencyClassb(G);
TestNilpotencyClassc(G);
TestNilpotencyClassd(G);
Loading this on MAGMA yields the following result:
3 2
32767
3 32767
32767
3 32767
32767
3 32767
Where is that 32767 coming from? Notice how it is 2^(15)-1. Why is this miscalculation being produced?
Update: I tried copy-pasting the code to MAGMA and the result was the same. Furthermore, after quitting and reopening, I tried copy-pasting only the first function, then computing the
NilpotencyClass, then using the function, and here's the result:
host-001:~ michelegorini$ magma
Magma V2.20-4 (STUDENT) Fri Dec 19 2014 17:29:45 [Seed = 1006321001]
Type ? for help. Type <Ctrl>-D to quit.
TestNilpotencyClass := function(G)
n:=NilpotencyClass(G);
if not IsNilpotent(G) then
return 0;
end if;
N := #G;
somma := 0;
for pn in Factorisation(N) do
p := pn[1];
P := SylowSubgroup(G,p);
c := NilpotencyClass(P);
somma +:= c;
end for;
return somma, n;
end function;> TestNilpotencyClass := function(G)
function> n:=NilpotencyClass(G);
function> if not IsNilpotent(G) then
function|if> return 0;
function|if> end if;
function> N := #G;
function> somma := 0;
function> for pn in Factorisation(N) do
function|for> p := pn[1];
function|for> P := SylowSubgroup(G,p);
function|for> c := NilpotencyClass(P);
function|for> somma +:= c;
function|for> end for;
function> return somma, n;
function> end function;
> G:=SmallGroups(40)[11];
> TestNilpotencyClass(G);
3 2
> NilpotencyClass(G);
32767
> TestNilpotencyClass(G);
3 32767
> TestNilpotencyClass(SmallGroups(40)[11]);
3 2
> NilpotencyClass(SmallGroups(40)[11]);
2
This is a bug in MAGMA; once nilpotence is established for a PC group, the return value of NilpotencyClass() is garbage. The first call gives the correct value, but later calls will fail.
This has been fixed for the next patch release (some time in May). In the meantime, a workaround would be to use (for instance)