> ^ From:

> < ^ Subject:

In his letter David Sibley asked:

> Is the order of the conjugacy classes in <G>.conjugacyClasses the same as

> the order of columns in the table? The manual implies this, but does

> not say it directly.

The order *is* the same, though the manual is somehow evasive in this point.

All routines computing character tables of groups (i.e. CharTablePGroup and

also the forthcoming Dixon-Algorithm) will use the order of the classes of the

group. The only requirement is, that the class of the identity *must* be in

the first position. If the classes are not yet given, the routines compute

them, and use them in the computed order.

However, be careful with SortClassesCharTable: In GAP 3.1 this will *not*

rearrange the conjugacy classes of the group, given in 'Table.group'. This

will be fixed in GAP 3.2.

Is there some way to get the (very nice) output of DisplayCharTable

directed to a file?

I would suggest the following routine, which will do the required task. It

is used by

PrintCharTable(file,table);

or --- alternatively --- by

PrintCharTable(file,table,width);

where width is the length of the rows of the final output device, e.g. the

printer:

PrintCharTable := function(arg)

local file,table,width,screensize;

file:=arg[1];

table:=arg[2];

if Length(arg)>2 then

width:=arg[3];

else

# this is the standard print width

width:=80;

fi;

# get screen size

screensize:=SizeScreen();

# resize screen

SizeScreen([width,screensize[2]]);

PrintTo(file,DisplayCharTable(table));

# resize screen to standard size

SizeScreen(screensize);

end;

> What does the message

>

> #I TransformingPermutations: no bijection of row families

>

> mean? (This might not be exactly right. It's from memory.) I don't

> see it very often, though I've been using TransformingPermutations quite

> a bit, so I assume it's something unusual.

>

TransformingPremutations first tries to map the rows --- regarded as sets of

their elements --- of the first matrix onto the rows of the second matrix.

The existence of such a mapping is necessary for the existence of

transforming permutations.

The same observation is valid for the columns, thus the same test is done

therefore.

If one of these two tests fail --- which can be checked quite easily ---

the two matrices cannot be equivalent. This will eliminate the need to start

the (expensive) routine, trying to map the matrices onto each other.

The meaning of the printed message is just a 'false', but it is a *fast*

'false'.

I hope this helps,

Alexander

> < [top]