Frequently Asked Questions

General Obtaining GAP Installation Hardware/OS Usage Complaints Computing with GAP Programming GAP

6. Complaints

6.2: My calculation does not finish (or GAP runs out of memory).

Depending on the size or representation of objects, some harmless-looking commands can involve very expensive (in terms of runtime and of memory use) routines. Typical examples are (without any claim towards completeness):

• Isomorphism tests,
• Calculation of all subgroups,
• Calculations with finitely presented structures.

In these cases the calculation might seemingly run forever or terminate after a while with an error message that GAP could not get more memory.

A few ways around such problems are:

• Is there a better representation? Typically PcGroups (only possible for solvable groups) are more efficient than permutation groups are more efficient than matrix groups are more efficient than Fp groups. Use IsomorphismPermGroup (or similar) to transfer the calculation into a group in a better representation.
• Is there another operation (probably not as general as the one you are using) whose result would be sufficient? (For example it is sufficient to search for p-subgroups inside a Sylow subgroup.)
• Is there information you have about the object that GAP will have to find out? Good candidates are the size of a group (use SetSize) or solvability (use SetIsSolvableGroup).
• Is the amount of data produced by the calculation feasible for the machine you are using?
• If you are sure that you need this type of calculation, and that there is no better representation or function, it might be necessary to get a bigger computer. (You should also set the -o start option that limits the maximal memory use, and is intended to avoid a GAP job accidentally trashing a multiuser machine, to the memory size of your machine. See also the section Command Line Options in the Reference Manual).
• Does your computation use mutable lists when immutable lists might be better?

  In some cases, this can slow down your computation so much that it doesn't finish. Using immutable lists allows computed properties to be cached, so that further checking of the property is instantaneous. In the example below, the comments were introduced after the interaction.

  # create a mutable, sorted list

  gap> a:=List([0..20000],i->WordAlp("a",i));;
  gap> IsSortedList(a);
  true
  gap> time;
  256
  gap> IsSortedList(a);
  true
  gap> time;
  260
  

  # Time to check if it is sorted is about the same every occasion

  gap> KnownPropertiesOfObject(a);
  [ "IsFinite", "IsSmallList" ]
  

  # not much is known about a

  gap> b:=Immutable(a);;
  gap> KnownPropertiesOfObject(b);
  [ "IsFinite", "IsSmallList" ]
  

  # also not much is known about b # check sortedness for the first time

  gap> IsSortedList(b);
  true
  gap> time;
  284
  

  # about the same time it took for a. now, check again

  gap> IsSortedList(b);
  true
  gap> time;
  0
  

  # caching miracle! In this process, a lot was learned about b:

  gap> KnownPropertiesOfObject(b);
  [ "IS_SSORT_LIST", "IsFinite", "IsSmallList", "IsSortedList", "IsDuplicateFree" ]
  

  This example point to an important consequence: lookup in b is much faster than searching in a, since, as b is known to be sorted, binary search is used for the lookup. An amusing instance of a painful learning experience in the subject appears in the Forum thread starting in http://mail.gap-system.org/pipermail/forum/2008/002169.html.