Throughout this manual for the use of <font face="Gill Sans,Helvetica,Arial">ACE</font> as a <font face="Gill Sans,Helvetica,Arial">GAP</font> package, we
shall assume that the reader already knows the basic ideas of coset
enumeration, as can be found for example in <a href="biblio.htm#Neu82"><cite>Neu82</cite></a>. There, a
simple proof is given for the fact that a coset enumeration for a
subgroup of finite index in a finitely presented group must eventually
terminate with the correct result, provided the enumeration process
obeys a simple condition (Mendelsohn's condition) formulated in
Lemma 1 and Theorem 2 of <a href="biblio.htm#Neu82"><cite>Neu82</cite></a>. This basic condition leaves
room for a great variety of <strong>strategies</strong> for coset enumeration; two
``classical'' ones have been known for a long time as the <strong>Felsch
strategy</strong> and the <strong>HLT strategy</strong> (for Haselgrove, Leech and Trotter).
Extensive experimental studies on many strategies can be found
in <a href="biblio.htm#CDHW73"><cite>CDHW73</cite></a>, <a href="biblio.htm#Hav91"><cite>Hav91</cite></a>, <a href="biblio.htm#HR99ace"><cite>HR99ace</cite></a>, and <a href="biblio.htm#HR01"><cite>HR01</cite></a>, in
particular.
<p>
A few basic points should be particularly understood:
<p>
<ul>
<p>
<li> ``Subgroup (generator) and relator tables'' that are used in
the description of coset enumeration in <a href="biblio.htm#Neu82"><cite>Neu82</cite></a>, and to which we
will also occasionally refer in this manual, do <strong>not</strong> physically exist
in the implementation of coset enumeration in <font face="Gill Sans,Helvetica,Arial">ACE</font>. For a
terminology that is closer to the actual implementation and also to
the formulations in the manual for the <font face="Gill Sans,Helvetica,Arial">ACE</font> standalone see
<a href="biblio.htm#CDHW73"><cite>CDHW73</cite></a> and <a href="biblio.htm#Hav91"><cite>Hav91</cite></a>.
<p>
<a name = "I3"></a>
<a name = "I3"></a>
<a name = "I4"></a>
<a name = "I3"></a>
<a name = "I4"></a>
<a name = "I5"></a>
<li> Coset enumeration proceeds by defining <strong>coset numbers</strong> that
really denote possible representatives for cosets written as words in
the generators of the group. At the time of their generation it is not
guaranteed that any two of these words do indeed represent different
cosets. The state of an enumeration at any time is stored in a
2-dimensional array known as a <strong>coset table</strong> whose rows are indexed by
coset numbers and whose columns are indexed by the group generators
and their inverses. Entries of the coset table that are not yet
defined are known as <strong>holes</strong> (typically they are filled with 0,
i.e. an invalid coset number).
<p>
<a name = "I6"></a>
<a name = "I6"></a>
<a name = "I7"></a>
<a name = "I6"></a>
<a name = "I7"></a>
<li> It is customary in talking about coset enumeration to speak
of <strong>cosets</strong> when really coset numbers are meant. While we try to avoid
this in this interface manual, in certain word combinations such as
<strong>coset application</strong> we will follow this custom.
<p>
<a name = "I8"></a>
<a name = "I8"></a>
<a name = "I9"></a>
<li> The definition of a coset number may lead to <strong>deductions</strong>
from the ``closing of rows in subgroup or relator tables''. These are
kept in a <strong>deduction stack</strong>.
<p>
<a name = "I10"></a>
<a name = "I10"></a>
<a name = "I11"></a>
<li> Also it may be found that (different) words in the
generators defining different coset numbers really lie in the same
coset of the given subgroup. This is called a <strong>coincidence</strong> and will
eventually lead to the elimination of the larger of the two coset
numbers. Until this elimination has been performed pending
coincidences are kept in a <strong>queue of coincidences</strong>.
<p>
<a name = "I12"></a>
<a name = "I12"></a>
<a name = "I13"></a>
<a name = "I14"></a>
<li> A definition that will actually close a row in a subgroup or
relator table will immediately yield twice as many entries in the
coset table as other definitions. Such definitions are called
<strong>preferred definitions</strong>, the places in rows of a subgroup or relator table that they close are also referred to as ``gaps of length one''
or minimal gaps. Such gaps can be found at little extra cost when
``relators are traced from a given coset number''. <font face="Gill Sans,Helvetica,Arial">ACE</font> keeps a
selection of them in a <strong>preferred definition stack</strong> for use in some
definition strategies (see <a href="biblio.htm#Hav91"><cite>Hav91</cite></a>).
<p>
</ul>
<p>
It will also be necessary to understand some further basic features of
the implementation and the corresponding terminology which we will
explain in the sequel.
<p>
<p>
<h2><a name="SECT001">3.1 Enumeration Style</a></h2>
<p><p>
The first main decision for any coset enumeration is in which sequence
to make definitions. When a new coset number has to be defined, in
<font face="Gill Sans,Helvetica,Arial">ACE</font> there are basically three possible methods to choose from:
<p>
<ul>
<p>
<a name = "I15"></a>
<li> One may fill the next empty entry in the coset table by
scanning from the left/top of the coset table towards the right/bottom
-- that is, in order row by row. This is called <strong>C style definition</strong>
(for <strong>C</strong>oset Table Based definition) of coset numbers. In fact a
procedure needs to follow a method like this to some extent for the
proofs that coset enumeration eventually terminates in the case of
finite index (see <a href="biblio.htm#Neu82"><cite>Neu82</cite></a>).
<p>
<a name = "I16"></a>
<li> For an <strong>R style definition</strong> (for <strong>R</strong>elator Based
definition), the order in which coset numbers are defined is
explicitly prescribed by the order in which rows of (the subgroup
generator tables and) the relator tables are filled by making
definitions.
<p>
<a name = "I17"></a>
<a name = "I18"></a>
<a name = "I19"></a>
<li> One may choose definitions from a <strong>Preferred Definition
Stack</strong>. In this stack possibilities for definition of coset numbers
are stored that will close a certain row of a relator table. Using
these <strong>preferred definitions</strong> is sometimes also referred to as a
<strong>minimal gaps strategy</strong>. The idea of using these is that by closing a
row in a relator table, thus, one will immediately get a consequence.
We will come back to the obvious question of where one obtains this
``preferred definition stack''.
<p>
</ul>
<p>
The <strong>enumeration style</strong> is mainly determined by the balance between
C style and R style definitions, which is controlled by the values of
the <code>ct</code> and <code>rt</code> options (see <a href="CHAP004.htm#SSEC013.2">option ct</a> and <a href="CHAP004.htm#SSEC013.3">optionrt</a>).
<p>
However this still leaves us with plenty of freedom for the design of
definition strategies, freedom which can, for example, be used to
great advantage in Felsch-type strategies. Though it is not strictly
necessary, before embarking on further enumeration, Felsch-type
programs generally start off by ensuring that each of the given
subgroup generators produces a cycle of coset numbers at coset 1. To
explain the idea, an example may help. Suppose <i>a</i>,<i>b</i> are the group
generators and <i>w</i>=<i>Abab</i> is a subgroup generator, where <i>A</i> represents
the inverse of <i>a</i>; then to say that ``(1,<i>i</i>,<i>j</i>,<i>k</i>) is a cycle of
coset numbers produced at coset 1 by <i>w</i>'' means that the successive
application of the ``letters'' <i>A</i>,<i>b</i>,<i>a</i>,<i>b</i> of <i>w</i> takes one
successively from coset 1, through cosets <i>i</i>, <i>j</i> and <i>k</i>, and back
to coset 1, i.e. <i>A</i> applied to coset 1 results in coset <i>i</i>, <i>b</i>
applied to coset <i>i</i> results in coset <i>j</i>, <i>a</i> applied to coset <i>j</i>
results in coset <i>k</i>, and finally <i>b</i> applied to coset <i>k</i> takes us
back to coset 1. In this way, a hypothetical subgroup table is
filled first. The use of this and other possibilities leads to the
following table of <strong>enumeration styles</strong>.
<p>
<pre> Rt value Ct value style name
-----------------------------------------
<dt><strong>C style</strong> <dd>
In this style, most definitions are made in the next empty coset table
slot and are (in principle) tested in all essentially different
positions in the relators; i.e. this is a Felsch-like style.
<p>
However, in C style, some definitions may be made following a
preferred definition strategy, controlled by the <code>pmode</code> and <code>psize</code>
options (see <a href="CHAP004.htm#SSEC014.2">option pmode</a> and <a href="CHAP004.htm#SSEC014.3">option psize</a>).
<p>
<a name = "I21"></a>
<dt><strong>Cr style</strong> <dd>
is like C style except that a single R style pass is done after the
initial C style pass.
<p>
<a name = "I22"></a>
<dt><strong>CR style</strong> <dd>
In this style, alternate passes of C style and R style are performed.
<p>
<a name = "I23"></a>
<dt><strong>R style</strong> <dd>
In this style, all the definitions are made via relator scans;
i.e. this is an HLT-like style.
<p>
<a name = "I24"></a>
<dt><strong>R* style</strong> <dd>
makes definitions the same as R style, but tests all definitions as
for C style.
<p>
<a name = "I25"></a>
<dt><strong>Rc style</strong> <dd>
is like R style, except that a single C style pass is done after the
initial R style pass.
<p>
<a name = "I26"></a>
<dt><strong>R/C style</strong> <dd>
In this style, we run in R style until an overflow, perform a
lookahead on the entire table, and then switch to CR style.
<p>
<a name = "I27"></a>
<a name = "I28"></a>
<dt><strong>Defaulted R/C</strong> (=<strong>R/C (defaulted)</strong> ) <strong>style</strong> <dd>
is the default style used if you call <font face="Gill Sans,Helvetica,Arial">ACE</font> without specifying
options. In it, we use R/C style with <code>ct</code> set to 1000 and <code>rt</code> set to
approximately 2000 divided by the total length of the relators in an
attempt to balance R style and C style definitions when we switch to
CR style.
<p>
</dl>
<p>
<p>
<h2><a name="SECT002">3.2 Finding Deductions, Coincidences, and Preferred Definitions</a></h2>
<p><p>
<a name = "I29"></a>
First, let us broadly discuss strategies and how they influence
``definitions''. By <strong>definition</strong> we mean the allocation of a coset
number. In a complete coset table each group relator produces a cycle
of cosets numbers at each coset number, in particular, at coset 1;
i.e. for each relator <i>w</i>, and for each coset number <i>i</i>, successive
application of the letters of <i>w</i> trace through a sequence of coset
numbers that begins and ends in <i>i</i> (see Section <a href="CHAP003.htm#SECT001">Enumeration Style</a>
for an example). It has been found to be a good general rule to use
the given group relators as subgroup generators. This ensures the
early definition of some useful coset numbers, and is the basis of the
<code>default</code> strategy (see <a href="CHAP005.htm#SSEC001.1">option default</a>). The number of group
relators included as subgroup generators is determined by the <code>no</code> option (see <a href="CHAP004.htm#SSEC013.4">option no</a>). Over a wide range of examples the use of
group relators in this way has been shown to produce generally
beneficial results in terms of the maximum number of cosets numbers
defined at any one time and the total number of coset numbers defined.
In <a href="biblio.htm#CDHW73"><cite>CDHW73</cite></a>, it was reported that for some Macdonald group
<i>G</i>(α,β) examples, (pure) Felsch-type strategies (that don't
include the given group relators as subgroup generators) e.g. the
<code>felsch := 0</code> strategy (see <a href="CHAP005.htm#SSEC001.3">option felsch</a>) defined significantly
more coset numbers than HLT-type (e.g. the <code>hlt</code> strategy, see <a href="CHAP005.htm#SSEC001.5">option hlt</a>) strategies. The comparison of these strategies in terms of total
number of coset numbers defined, in <a href="biblio.htm#Hav91"><cite>Hav91</cite></a>, for the enumeration
of the cosets of a certain index 40 subgroup of the <i>G</i>(3,21)
Macdonald group were 91 for HLT versus 16067 for a pure Felsch-type
strategy. For the Felsch strategy with the group relators included as
subgroup generators, as for the <code>felsch := 1</code> strategy (see <a href="CHAP005.htm#SSEC001.3">option felsch</a>) the total number of coset numbers defined reduced markedly to
59.
<p>
<a name = "I30"></a>
A <strong>deduction</strong> occurs when the scanning of a relator results in the
assignment of a coset tablebody entry. A completed table is only
valid if every table entry has been tested in all essentially
different positions in all relators. This testing can either be done
directly (Felsch strategy) or via relator scanning (HLT strategy). If
it is done directly, then more than one deduction can be waiting to be
processed at any one time. The untested deductions are stored in a
stack. How this stack is managed is determined by the <code>dmode</code> option
(see <a href="CHAP004.htm#SSEC016.1">option dmode</a>), and its size is controlled by the <code>dsize</code> option
(see <a href="CHAP004.htm#SSEC016.2">option dsize</a>).
<p>
<a name = "I31"></a>
<a name = "I31"></a>
<a name = "I32"></a>
As already mentioned a <strong>coincidence</strong> occurs when it is determined that
two coset numbers in fact represent the same coset. When this occurs
the larger coset number becomes a <strong>dead coset number</strong> and the
coincidence is placed in a queue. When and how these dead coset
numbers are eventually eliminated is controlled by the options
<code>dmode</code>, <code>path</code> and <code>compaction</code> (see <a href="CHAP004.htm#SSEC016.1">option dmode</a>, <a href="CHAP004.htm#SSEC017.4">option path</a>
and <a href="CHAP004.htm#SSEC017.5">option compaction</a>). The user may also force coincidences to
occur (see Section <a href="CHAP003.htm#SECT003">Finding Subgroups</a>), which, however, may change
the subgroup whose cosets are enumerated.
<p>
<a name = "I33"></a>
The key to performance of coset enumeration procedures is good
selection of the next coset number to be defined. Leech
in <a href="biblio.htm#Lee77"><cite>Lee77</cite></a> and <a href="biblio.htm#Lee84"><cite>Lee84</cite></a> showed how a number of coset
enumerations could be simplified by removing coset numbers needlessly
defined by computer implementations. Human enumerators intelligently
choose which coset number should be defined next, based on the value
of each potential definition. In particular, definitions which close
relator cycles (or at least shorten gaps in cycles) are favoured. A
definition which actually closes a relator cycle immediately yields
twice as many table entries (deductions) as other definitions. The
value of the <code>pmode</code> option (see <a href="CHAP004.htm#SSEC014.2">option pmode</a>) determines which
definitions are <strong>preferred</strong>; if the value of the <code>pmode</code> option is
non-zero, depending on the <code>pmode</code> value, gaps of length one found
during relator C style (i.e. Felsch-like) scans are either filled
immediately (subject to the value of <code>fill</code>) or noted in the
<strong>preferred definition stack</strong>. The preferred definition stack is
implemented as a ring of size determined by the <code>psize</code> option
(see <a href="CHAP004.htm#SSEC014.3">option psize</a>). However, making preferred definitions carelessly
can violate the conditions required for guaranteed termination of the
coset enumeration procedure in the case of finite index. To avoid such
a violation <font face="Gill Sans,Helvetica,Arial">ACE</font> ensures a fraction of the coset table is filled
before a preferred definition is made; the reciprocal of this
fraction, the <code>fill factor</code>, is manipulated via the <code>fill</code> option
(see <a href="CHAP004.htm#SSEC014.1">option fill</a>). In <a href="biblio.htm#Hav91"><cite>Hav91</cite></a>, the <code>felsch := 1</code> type
enumeration of the cosets of the certain index 40 subgroup of the
<i>G</i>(3,21) Macdonald group was further improved to require a total
number of coset numbers of just 43 by incorporating the use of
preferred definitions.
<p>
<p>
<h2><a name="SECT003">3.3 Finding Subgroups</a></h2>
<p><p>
<a name = "I34"></a>
The <font face="Gill Sans,Helvetica,Arial">ACE</font> package, via its interactive <font face="Gill Sans,Helvetica,Arial">ACE</font> interface functions
(described in Chapter <a href="CHAP006.htm">Functions for Using ACE Interactively</a>),
provides the possibility of searching for subgroups. To do this one
starts at a known subgroup (possibly the trivial subgroup). Then one
may augment it by adding new subgroup generators either explicitly via
<code>ACEAddSubgroupGenerators</code> (see <a href="CHAP006.htm#SSEC007.4">ACEAddSubgroupGenerators</a>) or
implicitly by introducing <strong>coincidences</strong> (see <code>ACECosetCoincidence</code>:
<a href="CHAP006.htm#SSEC007.7">ACECosetCoincidence</a>, or <code>ACERandomCoincidences</code>:
<a href="CHAP006.htm#SSEC007.8">ACERandomCoincidences</a>). Also, one may descend to smaller subgroups
by deleting subgroup generators via <code>ACEDeleteSubgroupGenerators</code>
(see <a href="CHAP006.htm#SSEC007.6">ACEDeleteSubgroupGenerators</a>).
<p>
<p>
<h2><a name="SECT004">3.4 Coset Table Standardisation Schemes</a></h2>
<p><p>
<a name = "I35"></a>
The default standardisation scheme for <font face="Gill Sans,Helvetica,Arial">GAP</font> and the
standardisation scheme provided by <font face="Gill Sans,Helvetica,Arial">ACE</font> is the <code>lenlex</code> scheme, of
Charles Sims <a href="biblio.htm#Sim94"><cite>Sim94</cite></a>. This scheme numbers cosets first according
to word-length and then according to a lexical ordering of coset
representatives. Each coset representative is a word in an alphabet
consisting of the user-supplied generators and their inverses, and the
lexical ordering of <code>lenlex</code> is that implied by ordering that alphabet
so that each generator is followed by its inverse, and the generators
appear in user-supplied order. See below for an example which gives
the first 20 lines of the <code>lenlex</code> standard coset table of the
(infinite) group with presentation 〈<i>x</i>, <i>y</i>, <i>a</i>, <i>b</i> | <i>x</i><sup>2</sup>, <i>y</i><sup>3</sup>, <i>a</i><sup>4</sup>, <i>b</i><sup>2</sup>〉.
<p>
In the table each inverse of a generator is represented by the
corresponding uppercase letter (<i>X</i> represents the inverse of <i>x</i>
etc.), and the lexical ordering of the representatives is that implied
by defining an ordering of the alphabet of user-supplied generators
and their inverses to be <i>x</i> < <i>X</i> < <i>y</i> < <i>Y</i> < <i>a</i> < <i>A</i> < <i>b</i> < <i>B</i>.
<p>
A <code>lenlex</code> standard coset table whose columns correspond, in order, to
the already-described alphabet, of generators and their inverses, has
an important property: a scan of the body of the table row by row from
left to right, encounters new coset numbers in numeric order. Observe
that the table below has this property: the definition of coset 1 is
implicit; the first coset number we encounter in the tablebody is 2,
then 2 again, 3, 4, 5, 6, 7, then 7 again, etc.
<p>
With the <code>lenlex</code> option (see <a href="CHAP004.htm#SSEC011.4">option lenlex</a>), the coset tableoutput
by <code>ACECosetTable</code> or <code>ACECosetTableFromGensAndRels</code> is standardised
according to the <code>lenlex</code> scheme.
<p>
<pre>
coset no. | x X y Y a A b B rep've
-----------+------------------------------------------------------------------
1 | 2 2 3 4 5 6 7 7
2 | 1 1 8 9 10 11 12 12 x
3 | 13 13 4 1 14 15 16 16 y
4 | 17 17 1 3 18 19 20 20 Y
5 | 21 21 22 23 24 1 25 25 a
6 | 26 26 27 28 1 24 29 29 A
7 | 30 30 31 32 33 34 1 1 b
8 | 35 35 9 2 36 37 38 38 xy
9 | 39 39 2 8 40 41 42 42 xY
10 | 43 43 44 45 46 2 47 47 xa
11 | 48 48 49 50 2 46 51 51 xA
12 | 52 52 53 54 55 56 2 2 xb
13 | 3 3 57 58 59 60 61 61 yx
14 | 62 62 63 64 65 3 66 66 ya
15 | 67 67 68 69 3 65 70 70 yA
16 | 71 71 72 73 74 75 3 3 yb
17 | 4 4 76 77 78 79 80 80 Yx
18 | 81 81 82 83 84 4 85 85 Ya
19 | 86 86 87 88 4 84 89 89 YA
20 | 90 90 91 92 93 94 4 4 Yb
</pre>
<p>
<a name = "I36"></a>
Another standardisation scheme for coset tables numbers cosets according to
coset representative word-length in the group generators and lexical
ordering imposed by the user-supplied ordering of the group
generators; it is known as <code>semilenlex</code> since though like <code>lenlex</code>,
generator inverses do not feature. Here again is 20 lines of the coset table of the group with presentation 〈<i>x</i>, <i>y</i>, <i>a</i>, <i>b</i> | <i>x</i><sup>2</sup>, <i>y</i><sup>3</sup>, <i>a</i><sup>4</sup>, <i>b</i><sup>2</sup>〉, this time <code>semilenlex</code> standardised.
<p>
<pre>
coset no. | x y a b rep've
-----------+--------------------------------------
1 | 2 3 4 5
2 | 1 6 7 8 x
3 | 9 10 11 12 y
4 | 13 14 15 16 a
5 | 17 18 19 1 b
6 | 20 21 22 23 xy
7 | 24 25 2 26 xa
8 | 27 28 29 2 xb
9 | 3 30 31 32 yx
10 | 33 1 34 35 yy
11 | 36 37 38 39 ya
12 | 40 41 42 3 yb
13 | 4 43 44 45 ax
14 | 46 47 48 49 ay
15 | 50 51 52 53 aa
16 | 54 55 56 4 ab
17 | 5 57 58 59 bx
18 | 60 61 62 63 by
19 | 64 65 66 67 ba
20 | 6 68 69 70 xyx
</pre>
<p>
The term <code>semilenlex</code> was coined by Edmund Robertson and Joachim
Neubüser, for the scheme's applicability to semigroups
where generator inverses need not exist. This scheme ensures that as
one scans the columns corresponding to the group generators (in
user-supplied order) row by row, one encounters new coset numbers in
numeric order.
<p>
Observe that the representatives are ordered according to length and
then the lexical ordering implied by defining <i>x</i> < <i>y</i> < <i>a</i> < <i>b</i> (with some
words omitted due to their equivalence to words that precede them in
the ordering). Also observe that as one scans the body of the table
row by row from left to right new coset numbers appear in numeric
order without gaps (2, 3, 4, 5, then 1 which we have implicitly
already seen, 6, 7, etc.).
<p>
<p>
<h2><a name="SECT005">3.5 Coset Statistics Terminology</a></h2>
<p><p>
<a name = "I37"></a>
<a name = "I37"></a>
<a name = "I38"></a>
<a name = "I37"></a>
<a name = "I38"></a>
<a name = "I39"></a>
<a name = "I40"></a>
<a name = "I40"></a>
<a name = "I41"></a>
<a name = "I40"></a>
<a name = "I41"></a>
<a name = "I42"></a>
There are three statistics involved in the counting of coset number
definitions: <code>activecosets</code>, <code>maxcosets</code> and <code>totcosets</code>; these are
three of the fields of the record returned by <code>ACEStats</code> (see Section <a href="CHAP001.htm#SECT003">Using ACE Directly to Test whether a Coset Enumeration Terminates</a>), and they correspond to the <code>a</code>, <code>m</code> and <code>t</code> statistics
of an <font face="Gill Sans,Helvetica,Arial">ACE</font> ``results message'' (see Appendix <a href="CHAP00A.htm">The Meanings of ACE's Output Messages). As already described, coset enumeration proceeds by
defining coset numbers; <code>totcosets</code> counts <strong>all</strong> such definitions made
during an enumeration. During the coset enumeration process,
<strong>coincidences</strong> usually occur, resulting in the larger of each
coincident pair becoming a <strong>dead coset number</strong>. The statistic
<code>activecosets</code> is the count of coset numbers left <strong>alive</strong> (i.e. not
dead) at the end of an enumeration; and <code>maxcosets</code> is the maximum
number of <strong>alive</strong> cosets at any point of an enumeration.
<p>
In practice, the statistics <code>maxcosets</code> and <code>totcosets</code> tend to be of
a similar order, though, of course, <code>maxcosets</code> can never be more than
<code>totcosets</code>.
<p>
<p>
<h2><a name="SECT006">3.6 Other Terminology</a></h2>
<p><p>
<a name = "I43"></a>
<a name = "I43"></a>
<a name = "I44"></a>
<a name = "I43"></a>
<a name = "I44"></a>
<a name = "I45"></a>
In various places in this manual, we will refer to a (main) <strong>loop</strong> or
a <strong>pass</strong> through such a loop. We don't intend to give a precise
meaning to these terms. The reader will need to forgive us for giving
somewhat circular definitions in our attempt to make these terms less
nebulous. It is sufficient to appreciate that the <font face="Gill Sans,Helvetica,Arial">ACE</font> enumerator is
organised as a state machine, where each <strong>state</strong> is a value of the
coset table held internally by <font face="Gill Sans,Helvetica,Arial">ACE</font> at the end of each ``main
loop''. Each step from one state to the next (i.e. each passage
through the main loop) performs an ``action'' (i.e., <code>lookahead</code>,
<code>compaction</code>; see <a href="CHAP004.htm#SSEC015.2">option lookahead</a> and <a href="CHAP004.htm#SSEC017.5">option compaction</a>) or a
block of actions (i.e., <code>|ct|</code> coset number definitions, <code>|rt|</code> coset
number applications). <font face="Gill Sans,Helvetica,Arial">ACE</font> counts the number of passes through the
main loop; if the option <code>loop</code> (see <a href="CHAP004.htm#SSEC017.3">option loop</a>) is set to a
positive integer, <font face="Gill Sans,Helvetica,Arial">ACE</font> makes an early return when the loop count
hits the value of <code>loop</code>.
<p>
<p>
[<a href = "chapters.htm">Up</a>] [<a href ="CHAP002.htm">Previous</a>] [<a href ="CHAP004.htm">Next</a>] [<a href = "theindex.htm">Index</a>]
<P>
<address>ACE manual<br>April 2025
</address></body></html>
¤ Dauer der Verarbeitung: 0.31 Sekunden
(vorverarbeitet)
¤
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung ist noch experimentell.