Ziele Untersuchung
mit Columbo Integrität von
Datenbanken Interaktion und
Portierbarkeit Ergonomie der
Schnittstellen

Angebot Produkte Projekt Beratung

Mittel Analytik Modellierung Sprachen Algebra Logik Hardware Denken Kreativität

Zusammenhänge Gesellschaft Wirtschaft Branche Firma


products/sources/formale Sprachen/GAP/pkg/ace/htm/ (Algebra von RWTH Aachen Version 4.15.1^©) Datei vom 10.3.2025 mit Größe 84 kB

Quelle CHAP004.htm Sprache: HTML

products/sources/formale Sprachen/GAP/pkg/ace/htm/CHAP004.htm

<html><head><title>[ACE] 4 Options for ACE</title></head>
<body text="#000000" bgcolor="#ffffff">
[<a href = "chapters.htm">Up</a>] [<a href ="CHAP003.htm">Previous</a>] [<a href ="CHAP005.htm">Next</a>] [<a href = "theindex.htm">Index</a>]
<h1>4 Options for ACE</h1>

<H3>Sections</H3>
<oL>
<li> <A HREF="CHAP004.htm#SECT001">Passing ACE Options</a>
<li> <A HREF="CHAP004.htm#SECT002">Warnings regarding Options</a>
<li> <A HREF="CHAP004.htm#SECT003">Abbreviations and mixed case for ACE Options</a>
<li> <A HREF="CHAP004.htm#SECT004">Honouring of the order in which ACE Options are passed</a>
<li> <A HREF="CHAP004.htm#SECT005">What happens if no ACE Strategy Option or if no ACE Option is passed</a>
<li> <A HREF="CHAP004.htm#SECT006">Interpretation of ACE Options</a>
<li> <A HREF="CHAP004.htm#SECT007">An Example of passing Options</a>
<li> <A HREF="CHAP004.htm#SECT008">The KnownACEOptions Record</a>
<li> <A HREF="CHAP004.htm#SECT009">The ACEStrategyOptions List</a>
<li> <A HREF="CHAP004.htm#SECT010">ACE Option Synonyms</a>
<li> <A HREF="CHAP004.htm#SECT011">Non-ACE-binary Options</a>
<li> <A HREF="CHAP004.htm#SECT012">ACE Parameter Options</a>
<li> <A HREF="CHAP004.htm#SECT013">General ACE Parameter Options that Modify the Enumeration Process</a>
<li> <A HREF="CHAP004.htm#SECT014">ACE Parameter Options Modifying C Style Definitions</a>
<li> <A HREF="CHAP004.htm#SECT015">ACE Parameter Options for R Style Definitions</a>
<li> <A HREF="CHAP004.htm#SECT016">ACE Parameter Options for Deduction Handling</a>
<li> <A HREF="CHAP004.htm#SECT017">Technical ACE Parameter Options</a>
<li> <A HREF="CHAP004.htm#SECT018">ACE Parameter Options controlling ACE Output</a>
<li> <A HREF="CHAP004.htm#SECT019">ACE Parameter Options that give Names to the Group and Subgroup</a>
<li> <A HREF="CHAP004.htm#SECT020">Options for redirection of ACE Output</a>
<li> <A HREF="CHAP004.htm#SECT021">Other Options</a>
</ol>

ACE offers a wide range of options to direct and guide a coset
enumeration, most of which are available from GAP through the
interface provided by the ACE Package. We describe most of the
options available via the interface in this chapter; other options,
termed strategies, are defined in Chapter <a href="CHAP005.htm">Strategy Options for ACE</a>.
(Strategies are merely special options of ACE that set a number of
options described in this chapter, all at once.) Yet other options,
for which interactive function alternatives are provided in
Chapter <a href="CHAP006.htm">Functions for Using ACE Interactively</a>, or which most GAP
users are unlikely to need, are described in Appendix <a href="CHAP00D.htm">Other ACE Options</a>. From within a GAP session, one may see the complete list
of ACE options, after loading the ACE Package (see
Section <a href="CHAP002.htm#SECT002">Loading the ACE Package</a>), by typing

<pre>
gap> RecNames(KnownACEOptions);
[ "default", "help", "check", "generators", "start", "path", "cycles",
 "normal", "ds", "group", "subgroup", "relators", "order", "max", "rep",
 "system", "silent", "time", "begin", "text", "options", "fill",
 "aceinfile", "aceignore", "aceignoreunknown", "acenowarnings", "aceecho",
 "aceincomment", "aceexampleoptions", "lenlex", "semilenlex", "incomplete",
 "sg", "rl", "aep", "ai", "ao", "aceoutfile", "asis", "bye", "exit", "qui",
 "cc", "cfactor", "ct", "redo", "compaction", "continu", "dmode", "dsize",
 "dr", "dump", "easy", "echo", "enumeration", "felsch", "ffactor", "hard",
 "hlt", "hole", "lookahead", "loop", "mendelsohn", "messages", "monitor",
 "mode", "nc", "no", "oo", "pmode", "psize", "sr", "print", "purec",
 "purer", "rc", "recover", "contiguous", "rfactor", "rt", "row", "sc",
 "stabilising", "sims", "standard", "statistics", "stats", "style", "tw",
 "trace", "workspace" ]

</pre>

(See Section <a href="CHAP004.htm#SECT008">The KnownACEOptions Record</a>.) Also, from within a GAP
session, you may use GAP's help browser (see Chapter The Help System in the GAP Reference Manual); to find out about any
particular ACE option, simply type: ``<code>?option </code><var>option</var><code></code>'', where
<var>option</var> is one of the options listed above without any quotes, e.g.

<pre>
gap> ?option echo
</pre>

will display the section in this manual that describes the <code>echo</code>
option.

We begin this chapter with several sections discussing the nature of
the options provided. Please spend some time reading these sections.
To continue onto the next section on-line using GAP's help browser,
type:

<pre>
gap> ?>
</pre>


<h2><a name="SECT001">4.1 Passing ACE Options</a></h2>

Options are passed to the ACE interface functions in either of the
two usual mechanisms provided by GAP, namely:

<ul>

<li> options may be set globally using the function <code>PushOptions</code>
(see Chapter <a href="../../../doc/ref/chap8.html#X7FD84061873F72A2">Options Stack</a> in the GAP Reference Manual); or

<li> options may be appended to the argument list of any function
call, separated by a colon from the argument list (see <a href="../../../doc/ref/chap4.html#X78C70489791FDF43">Function Calls</a> in the GAP Reference Manual), in which case they are then
passed on recursively to any subsequent inner function call, which may
in turn have options of their own.

</ul>

In general, if ACE is to be used interactively one should avoid
using the global method of passing options. In fact, it is recommended
that prior to calling <code>ACEStart</code> the <code>OptionsStack</code> be empty.


<h2><a name="SECT002">4.2 Warnings regarding Options</a></h2>

As mentioned above, one can set options globally using the function
<code>PushOptions</code> (see Chapter <a href="../../../doc/ref/chap8.html#X7FD84061873F72A2">Options Stack</a> in the GAP Reference
Manual); however, options pushed onto <code>OptionsStack</code>, in this way,
remain there until an explicit <code>PopOptions()</code> call is made. In
contrast, options passed in the usual way behind a colon following a
function's arguments (see Function Calls in the GAP Reference
Manual) are local, and disappear from <code>OptionsStack</code> after the
function has executed successfully; nevertheless, a function, that is
passed options this way, will also see any global options or any
options passed down recursively from functions calling that function,
unless those options are over-ridden by options passed via the
function. Also note that duplication of option names for different
programs may lead to misinterpretations. Since a non-empty
<code>OptionsStack</code> is potentially a mine-field for the unwary user, the
function <code>ResetOptionsStack</code> (see <a href="../../../doc/ref/chap8.html#X83D1190984DA3B85">ResetOptionsStack</a> in the
Reference Manual) is now in the GAP library and

<a name = "SSEC002.1"></a>
<li><code>FlushOptionsStack() F</code>

introduced in version 3.001 of the ACE Package to perform the same
function, is now a synonym for <code>ResetOptionsStack</code>; it simply executes
<code>PopOptions()</code> until <code>OptionsStack</code> is empty.

However, <code>ResetOptionsStack</code> (or <code>FlushOptionsStack</code>) does not wipe
out the options already passed to an interactive ACE process. We
have provided <code>GetACEOptions</code> (see <a href="CHAP006.htm#SSEC005.7">GetACEOptions</a>) to keep track of
options that the ACE binary process still considers active, which
may or may not be still on the <code>OptionsStack</code>. There is the
interactive <code>SetACEOptions</code> (see <a href="CHAP006.htm#SSEC005.8">SetACEOptions</a>) to change such
options, or, of course, you can always elect to use <code>ACEQuit</code>
(see <a href="CHAP006.htm#SSEC001.2">ACEQuit</a>) and then start a new interactive ACE process.

Finally, if <code>ACEIgnoreUnknownDefault := false</code>
(see <a href="CHAP004.htm#SSEC011.2">ACEIgnoreUnknownDefault</a>), there will be situations where an
ACE interface function needs to be told explicitly to ignore
options passed down recursively to it from calling functions. For this
purpose we have provided the options <code>aceignore</code> (see <a href="CHAP004.htm#SSEC011.9">option aceignore</a>) and <code>aceignoreunknown</code> (see <a href="CHAP004.htm#SSEC011.10">option aceignoreunknown</a>).


<h2><a name="SECT003">4.3 Abbreviations and mixed case for ACE Options</a></h2>

Except for limitations imposed by GAP e.g. clashes with GAP
keywords and blank spaces not allowed in keywords, the options of the
ACE interface are the same as for the binary; so, for example, the
options can appear in upper or lower case (or indeed, mixed case) and
most may be abbreviated. Below we only list the options in all lower
case, and in their longest form; where abbreviation is possible we
give the shortest abbreviation in the option's description e.g. for
the <code>mendelsohn</code> option we state that its shortest abbreviation is
<code>mend</code>, which means <code>mende</code>, <code>mendel</code> etc., and indeed, <code>Mend</code> and
<code>MeND</code>, are all valid abbreviations of that option. Some options have
synonyms e.g. <code>cfactor</code> is an alternative for <code>ct</code>.

The complete list of ACE options known to the ACE interface
functions, their abbreviations and the values that they are known to
take may be gleaned from the <code>KnownACEOptions</code> record (see
Section <a href="CHAP004.htm#SECT008">The KnownACEOptions Record</a>).

Options for each of the ACE interface functions
<code>ACECosetTableFromGensAndRels</code>, <code>ACECosetTable</code>, <code>ACEStats</code> and
<code>ACEStart</code> (see Chapter <a href="CHAP006.htm">Functions for Using ACE Interactively</a>),
comprise the few non-ACE-binary options (<code>silent</code>, <code>aceinfile</code>,
<code>aceoutfile</code>, <code>aceignore</code>, <code>aceignoreunknown</code>, <code>acenowarnings</code>,
<code>aceincomment</code>, <code>aceecho</code> and <code>echo</code>) discussed in
Section <a href="CHAP004.htm#SECT011">Non-ACE-binary Options</a>, (almost) all single-word ACE
binary options and <code>purer</code> and <code>purec</code>. The options <code>purer</code> and
<code>purec</code> give the ACE binary options <code>pure r</code> and <code>pure c</code>,
respectively; (they are the only multiple-word ACE binary options
that do not have a single word alternative). The only single-word
ACE binary options that are not available via the ACE
interface are abbreviations that clash with GAP keywords (e.g. <code>fi</code>
for <code>fill</code>, <code>rec</code> for <code>recover</code> and <code>continu</code> for <code>continue</code>). The
detail of this paragraph is probably of little importance to the
GAP user; these comments have been included for the user who wishes
to reconcile the respective functionalities of the ACE interface
and the ACE standalone, and are probably of most value to
standalone users.


<h2><a name="SECT004">4.4 Honouring of the order in which ACE Options are passed</a></h2>

Note: Below we describe the intended behaviour, but unfortunately,
since GAP 4.5 (approximately when ACE 5.1 was released) the
order of options behind the colon is no longer honoured. Until this
is fixed, if the order of ACE options needs to be respected, users
should use ACE interactively (see <a href="CHAP006.htm#SSEC001.1">ACEStart</a>).

It is important to realize that ACE's options (even the
non-strategy options) are not orthogonal, i.e. the order in which
they are put to ACE can be important. For this reason, except for a
few options that have no effect on the course of an enumeration, the
order in which options are passed to the ACE interface is preserved
when those same options are passed to the ACE binary. One of the
reasons for the non-orthogonality of options is to protect the user
from obtaining invalid enumerations from bad combinations of options;
another reason is that commonly one may specify a strategy option and
override some of that strategy's defaults; the general rule is that
the later option prevails. By the way, it's not illegal to select more
than one strategy, but it's not sensible; as just mentioned, the later
one prevails.


<h2><a name="SECT005">4.5 What happens if no ACE Strategy Option or if no ACE Option is passed</a></h2>

If an ACE interface function (<code>ACECosetTableFromGensAndRels</code>,
<code>ACEStats</code>, <code>ACECosetTable</code> or <code>ACEStart</code>) is given no strategy
option, the <code>default</code> strategy (see Chapter <a href="CHAP005.htm">Strategy Options for ACE</a>) is selected, and a number of options that ACE needs to have a
value for are given default values, prior to the execution of any
user options, if any. This ensures that ACE has a value for all its
``run parameters''; three of these are defined from the ACE
interface function arguments; and the remaining ``run parameters'', we
denote by ``ACE Parameter Options''. For user convenience, we have
provided the <code>ACEParameterOptions</code> record (see <a href="CHAP004.htm#SSEC012.1">ACEParameterOptions</a>),
the fields of which are the ``ACE Parameter Options''. The value of
each field (option) of the <code>ACEParameterOptions</code> record is either a
default value or (in the case of an option that is set by a strategy)
a record of default values that ACE assumes when the user does not
define a value for the option (either indirectly by selecting a
strategy option or directly).

If the <code>default</code> strategy does not suffice, most usually a user will
select one of the other strategies from among the ones listed in
Chapter <a href="CHAP005.htm">Strategy Options for ACE</a>, and possibly modify some of the
options by selecting from the options in this chapter. It's not
illegal to select more than one strategy, but it's not sensible; as
mentioned above, the later one prevails.


<h2><a name="SECT006">4.6 Interpretation of ACE Options</a></h2>

Options may be given a value by an assignment to the name (such as
<code>time := </code><var>val</var><code></code>); or be passed without assigning a value, in which
case GAP treats the option as boolean and sets the option to the
value <code>true</code>, which is then interpreted by the ACE interface
functions. Technically speaking the ACE binary itself does not have
boolean options, though it does have some options which are declared
by passing without a value (e.g. the <code>hard</code> strategy option) and
others that are boolean in the C-sense (taking on just the values 0 or
1). The behaviour of the ACE interface functions
(<code>ACECosetTableFromGensAndRels</code>, <code>ACEStats</code>, <code>ACECosetTable</code> or
<code>ACEStart</code>) is essentially to restore as much as is possible a
behaviour that mimics the ACE standalone; a <code>false</code> value is always
translated to 0 and <code>true</code> may be translated to any of no-value, 0 or
1. Any option passed with an assigned value <var>val</var> other than <code>false</code>
or <code>true</code> is passed with the value <var>val</var> to the ACE binary. Since
this may appear confusing, let's consider some examples.

<ul>

<li> The <code>hard</code> strategy option (see <a href="CHAP005.htm#SSEC001.4">option hard</a>) should be
passed without a value, which in turn is passed to the ACE binary
without a value. However, the ACE interface function cannot
distinguish the option <code>hard</code> being passed without a value, from it
being passed via <code>hard := true</code>. Passing <code>hard := false</code> or <code>hard :=
</code><var>val</var><code></code> for any non-<code>true</code> <var>val</var> will however produce a warning message
(unless the option <code>acenowarnings</code> is passed) that the value 0 (for
<code>false</code>) or <var>val</var> is unknown for that option. Nevertheless, despite
the warning, in this event, the ACE interface function passes the
value to the ACE binary. When the ACE binary sees a line that it
doesn't understand it prints a warning and simply ignores it. (So
passing <code>hard := false</code> will produce warnings, but will have no ill
effects.) The reason we still pass unknown values to the ACE
binary is that it's conceivable a future version of the ACE binary
might have several <code>hard</code> strategies, in which case the ACE
interface function will still complain (until it's made aware of the
new possible values) but it will perform in the correct manner if a
value expected by the ACE binary is passed.

<li> The <code>felsch</code> strategy option (see <a href="CHAP005.htm#SSEC001.3">option felsch</a>) may be
passed without a value (which chooses the felsch 0 strategy) or with
the values 0 or 1. Despite the fact that GAP sees this option as
boolean; it is not. There are two Felsch strategies: felsch 0
and felsch 1. To get the felsch 1 strategy, the user must pass
<code>felsch := 1</code>. If the user were to pass <code>felsch := false</code> the result
would be the felsch 0 strategy (since <code>false</code> is always translated
to 0), i.e. the same as how <code>felsch := true</code> would be interpreted. We
could protect the user more from such ideosyncrasies, but we have
erred on the side of simplicity in order to make the interface less
vulnerable to upgrades of the ACE binary.

</ul>

The lesson from the two examples is: check the documentation for an
option to see how it will be interpreted. In general, options
documented (in this chapter) as only being no-value options can be
safely thought of as boolean (i.e. you will get what you expect by
assigning <code>true</code> or <code>false</code>), whereas strategy (no-value) options
should not be thought of as boolean (a <code>false</code> assignment will not
give you what you might have expected).

Options that are unknown to the ACE interface functions and not
ignored (see below), that are passed without a value, are always
passed to the ACE binary as no-value options (except when the
options are ignored); the user can over-ride this behaviour simply by
assigning the intended value. Note that it is perfectly safe to allow
the ACE binary to be passed unknown options, since ACE simply
ignores options it doesn't understand, issues an error message (which
is just a warning and is output by GAP unless <code>acenowarnings</code> (see
<a href="CHAP004.htm#SSEC011.11">option acenowarnings</a>) is passed) and continues on with any other
options passed in exactly the way it would have if the ``unknown''
options had not been passed.

An option is ignored if it is unknown to the ACE interface
functions and one of the following is true:

<ul>
<li> the global variable <code>ACEIgnoreUnknownDefault</code> is set to
<code>false</code> (see <a href="CHAP004.htm#SSEC011.2">ACEIgnoreUnknownDefault</a>) or,

<li> the <code>aceignoreunknown</code> option (see <a href="CHAP004.htm#SSEC011.10">option aceignoreunknown</a>)
is passed, or

<li> the <code>aceignore</code> option is passed and the option is an
element of the list value of <code>aceignore</code> (see <a href="CHAP004.htm#SSEC011.9">option aceignore</a>).

</ul>

<a name = "I0"></a>

<a name = "I1"></a>

It is actually recommended that the user set
<code>ACEIgnoreUnknownDefault</code> to <code>false</code>, since this will allow the user
to see when ACE functions have been passed options that are
``unknown'' to the ACE package. In this way the user will be
informed about misspelt options, for example. So it's a good debugging
tool. Also, if the ACE binary is updated with a version with new
options then these will not be known by the package (the GAP part)
and it will be necessary to set <code>ACEIgnoreUnknownDefault</code> to <code>false</code>
in order for the new options to be passed to the binary. When an
ACE function is invoked indirectly by some function that was called
with non-ACE options the warning messages may begin to be annoying,
and it's then a simple matter to set ACEIgnoreUnknownDefault back to
the ACE 3.003 default value of <code>true</code>.

Warning messages regarding unknown options are printed unless the
<code>acenowarnings</code> (see <a href="CHAP004.htm#SSEC011.11">option acenowarnings</a>) is passed or the option
is ignored.

To see how options are interpreted by an ACE interface function,
pass the <code>echo</code> option.

As mentioned above, any option that the ACE binary doesn't
understand is simply ignored and a warning appears in the output from
ACE. If this occurs, you may wish to check the input fed to ACE
and the output from ACE, which when ACE is run non-interactively
are stored in files whose full path names are recorded in the record
fields <code>ACEData.infile</code> and <code>ACEData.outfile</code>, respectively.
Alternatively, both interactively and non-interactively one can set
the <code>InfoLevel</code> of <code>InfoACE</code> to 3 (see <a href="CHAP001.htm#SSEC009.1">InfoACE</a>), to see the
output from ACE, or to 4 to also see the commands directed to
ACE.


<h2><a name="SECT007">4.7 An Example of passing Options</a></h2>

Continuing with the example of Section <a href="CHAP001.htm#SECT002">Using ACE Directly to Generate a Coset Table</a>, one could set the <code>echo</code> option to be true, use the
<code>hard</code> strategy option, increase the workspace to 107 words and
turn messaging on (but to be fairly infrequent) by setting <code>messages</code>
to a large positive value as follows:

<pre>
gap> ACECosetTable(fgens, rels, [c]
> : echo, hard, Wo := 10^7, mess := 10000);;
</pre>

As mentioned in the previous section, <code>echo</code> may be thought of as a
boolean option, whereas <code>hard</code> is a strategy option (and hence should
be thought of as a no-value option). Also, observe that two options
have been abbreviated: <code>Wo</code> is a mixed case abbreviation of
<code>workspace</code>, and <code>mess</code> is an abbreviation of <code>messages</code>.


<h2><a name="SECT008">4.8 The KnownACEOptions Record</a></h2>

<a name = "SSEC008.1"></a>
<li><code>KnownACEOptions V</code>

is a GAP record whose fields are the ACE options known to the
ACE interface; each field (known ACE option) is assigned to a
list of the form <code>[</code><var>i</var><code>, </code><var>ListOrFunction</var><code>]</code>, where <code></code><var>i</var><code></code> is an integer
representing the length of the shortest abbreviation of the option and
<code></code><var>ListOrFunction</var><code></code> is either a list of (known) allowed values or a
boolean function that may be used to determine if the given value is a
(known) valid value e.g.

<pre>
gap> KnownACEOptions.compaction;
[ 3, [ 0 .. 100 ] ]

</pre>

indicates that the option <code>compaction</code> may be abbreviated to <code>com</code>
and the (known) valid values are in the (integer) range 0 to 100; and

<pre>
gap> KnownACEOptions.ct;
[ 2, <Category "IsInt"> ]

</pre>

indicates that there is essentially no abbreviation of <code>ct</code> (since its
shortest abbreviation is of length 2), and a value of <code>ct</code> is known
to be valid if <code>IsInt</code> returns true for that value.

For user convenience, we provide the function

<a name = "SSEC008.2"></a>
<li><code>ACEOptionData( </code><var>optname</var><code> ) F</code>

which for a string <var>optname</var> representing an ACE option (or a guess
of one) returns a record with the following fields:


<dl compact>

<dt> <code>name</code> <dd> <var>optname</var> (unchanged);

<dt> <code>known</code> <dd> <code>true</code> if <var>optname</var> is a valid mixed case abbreviation
of a known ACE option, and false otherwise;

<dt> <code>fullname</code><dd> the lower case unabbreviated form of <var>optname</var> if the
<code>known</code> field is set <code>true</code>, or <var>optname</var> in all lower case,
otherwise;

<dt> <code>synonyms</code><dd> a list of known ACE options synonymous with
<var>optname</var>, in lowercase unabbreviated form, if the <code>known</code> field is
set <code>true</code>, or a list containing just <var>optname</var> in all lower case,
otherwise;

<dt> <code>abbrev</code> <dd> the shortest lowercase abbreviation of <var>optname</var> if
the <code>known</code> field is set <code>true</code>, or <var>optname</var> in all lower case,
otherwise.

</dl>

For more on synonyms of ACE options, see <a href="CHAP004.htm#SSEC010.1">ACEOptionSynonyms</a>.

The function <code>ACEOptionData</code> provides the user with all the query
facility she should ever need; nevertheless, we provide the following
functions.

<a name = "SSEC008.3"></a>
<li><code>IsKnownACEOption( </code><var>optname</var><code> ) F</code>

returns <code>true</code> if <var>optname</var> is a mixed case abbreviation of a field of
<code>KnownACEOptions</code>, or <code>false</code> otherwise.
<code>IsKnownACEOption(</code><var>optname</var><code>);</code> is equivalent to

<code>ACEOptionData(</code><var>optname</var><code>).known;</code>

<a name = "SSEC008.4"></a>
<li><code>ACEPreferredOptionName( </code><var>optname</var><code> ) F</code>

returns the lowercase unabbreviated first alternative of <var>optname</var> if
it is a known ACE option, or <var>optname</var> in lowercase, otherwise.
<code>ACEPreferredOptionName(</code><var>optname</var><code>);</code> is equivalent to

<code>ACEOptionData(</code><var>optname</var><code>).synonyms[1];</code>

<a name = "SSEC008.5"></a>
<li><code>IsACEParameterOption( </code><var>optname</var><code> ) F</code>

returns true if <var>optname</var> is an ``ACE parameter option''. (ACE
Parameter Options are described in Section <a href="CHAP004.htm#SSEC012.1">ACEParameterOptions</a>).
<code>IsACEParameterOption(</code><var>optname</var><code>);</code> is equivalent to

<code>ACEPreferredOptionName(</code><var>optname</var><code>) in RecNames(ACEParameterOptions);</code>

<a name = "SSEC008.6"></a>
<li><code>IsACEStrategyOption( </code><var>optname</var><code> ) F</code>

returns true if <var>optname</var> is an ``ACE strategy option'' (see
Section <a href="CHAP004.htm#SECT009">The ACEStrategyOptions list</a>).
<code>IsACEStrategyOption(</code><var>optname</var><code>);</code> is equivalent to

<code>ACEPreferredOptionName(</code><var>optname</var><code>) in ACEStrategyOptions;</code>


<h2><a name="SECT009">4.9 The ACEStrategyOptions List</a></h2>

<a name = "SSEC009.1"></a>
<li><code>ACEStrategyOptions V</code>

is a GAP list that contains the strategy options known to the
ACE interface functions:

<pre>
gap> ACEStrategyOptions;
[ "default", "easy", "felsch", "hard", "hlt", "purec", "purer", "sims" ]

</pre>

See Chapter <a href="CHAP005.htm">Strategy Options for ACE</a> for details regarding the
ACE strategy options.


<h2><a name="SECT010">4.10 ACE Option Synonyms</a></h2>

<a name = "SSEC010.1"></a>
<li><code>ACEOptionSynonyms V</code>

is a GAP record. A number of known ACE options have synonyms.
The fields of the <code>ACEOptionSynonyms</code> record are the ``preferred''
option names and the values assigned to the fields are the lists of
synonyms of those option names. What makes an option name
``preferred'' is somewhat arbitrary (in most cases, it is simply the
shortest of a list of synonyms). For a ``preferred'' option name
<var>optname</var> that has synonyms, the complete list of synonyms may be
obtained by concatenating <code>[ </code><var>optname</var><code> ]</code> and
<code>ACEOptionSynonyms.(</code><var>optname</var><code>)</code>, e.g.

<pre>
gap> Concatenation( [ "messages" ], ACEOptionSynonyms.("messages") );
[ "messages", "monitor" ]

</pre>

More generally, for an arbitrary option name <var>optname</var> its list of
synonyms (which may be a list of one element) may be obtained as the
<code>synonyms</code> field of the record returned by <code>ACEOptionData(</code><var>optname</var><code>)</code>
(see <a href="CHAP004.htm#SSEC008.2">ACEOptionData</a>).


<h2><a name="SECT011">4.11 Non-ACE-binary Options</a></h2>

<a name = "SSEC011.1"></a>
<li><code>NonACEbinOptions V</code>

is a GAP list of options that have meaning only for the ACE
Package interface, i.e. options in <code>KnownACEOptions</code> that are not
ACE binary options; each such option is described in detail below.
Except for the options listed in <code>NonACEbinOptions</code> and those
options that are excluded via the <code>aceignore</code> and <code>aceignoreunknown</code>
options (described below), all options that are on the
<code>OptionsStack</code> when an ACE interface function is called, are passed
to the ACE binary. Even options that produce the warning message:
``<code>unknown (maybe new) or bad</code>'', by virtue of not being a field of
<code>KnownACEOptions</code>, are passed to the ACE binary (except that the
options <code>purer</code> and <code>purec</code> are first translated to <code>pure r</code> and <code>pure
c</code>, respectively). When the ACE binary encounters an option that it
doesn't understand it issues a warning and simply ignores it; so
options accidentally passed to ACE are unlikely to pose problems.

We also mention here, since it is related to an option of this
section, the following.

<a name = "SSEC011.2"></a>
<li><code>ACEIgnoreUnknownDefault V</code>

is a global variable (not an option) that is initially set by the
ACE package to <code>true</code>, and is the default action that ACE takes
for options that are unknown to the ACE package (but may be new
options provided in a new version of the ACE binary). Despite the
fact that it is normally set <code>true</code>, it is recommended (especially for
the novice user of the ACE package) to set <code>ACEIgnoreUnknownDefault
:= false</code>; the worst that can happen is being annoyed by a profusion
of warnings of unknown options. For individual functions, the user may
use the option <code>aceignoreunknown</code> (see <a href="CHAP004.htm#SSEC011.10">option aceignoreunknown</a>) to
over-ride the setting of <code>ACEIgnoreUnknownDefault</code>.

Here now, are the few options that are available to the GAP
interface to ACE that have no counterpart in the ACE standalone:


<dl compact>

<dt><a name = "SSEC011.3"></a>
<dt><li><code>silent <dd></code>
Inhibits an <code>Error</code> return when generating a coset table.

If a coset enumeration that invokes <code>ACECosetTableFromGensAndRels</code>
does not finish within the preset limits, an error is raised by the
interface to GAP, unless the option <code>silent</code> or <code>incomplete</code>
(see <a href="CHAP004.htm#SSEC011.6">option incomplete</a>) has been set; in the former case, <code>fail</code> is
returned. This option is included to make the behaviour of
<code>ACECosetTableFromGensAndRels</code> compatible with that of the function
<code>CosetTableFromGensAndRels</code> it replaces. If the option <code>incomplete</code> is
also set, it overrides option <code>silent</code>.

<dt><a name = "SSEC011.4"></a>
<dt><li><code>lenlex <dd></code>
Ensures that <code>ACECosetTable</code> and <code>ACECosetTableFromGensAndRels</code> output
a coset table that is <code>lenlex</code> standardised.

The <code>lenlex</code> scheme, numbers cosets in such a way that their
``preferred'' (coset) representatives, in an alphabet consisting of
the user-submitted generators and their inverses, are ordered first
according to <code>length</code> and then according to a <code>lexical</code> ordering. In
order to describe what the <code>lenlex</code> scheme's lexical ordering is,
let us consider an example. Suppose the generators submitted by the
user are, in user-supplied order, <code>[x, y, a, b]</code>, and represent the
inverses of these generators by the corresponding uppercase letters:
<code>[X, Y, A, B]</code>, then the <code>lexical</code> ordering of <code>lenlex</code> is that
derived from defining <code>x < X < y < Y < a < A .

Notes:
In some circumstances, ACE prefers to swap the first two
generators; such cases are detected by the function
<code>IsACEGeneratorsInPreferredOrder</code> (see
<a href="CHAP001.htm#SSEC002.3">IsACEGeneratorsInPreferredOrder</a>). In such cases, special action is
taken to avoid ACE swapping the first two generators; this action
is described in the notes for <code>ACEStandardCosetNumbering</code>
(see <a href="CHAP006.htm#SSEC007.2">ACEStandardCosetNumbering</a>). When this special action is
invoked, a side-effect is that any setting of the <code>asis</code> (see <a href="CHAP004.htm#SSEC013.1">option asis</a>) option by the user is ignored.

The <code>lenlex</code> standardisation scheme is the default coset table
standardisation scheme of GAP. Alternatively, <code>semilenlex</code> can
be used. Both schemes are described in detail in Section <a href="CHAP003.htm#SECT004">Coset Table Standardisation Schemes</a>.

<dt><a name = "SSEC011.5"></a>
<dt><li><code>semilenlex <dd></code>
Ensures that <code>ACECosetTable</code> and <code>ACECosetTableFromGensAndRels</code> output
a coset table that is <code>semilenlex</code> standardised.

The <code>semilenlex</code> scheme, numbers cosets in such a way that their
``preferred'' (coset) representatives, in an alphabet consisting of
only the user-submitted generators, are ordered first according to
<code>length</code> and then according to a <code>lexical</code> ordering.

<dt><a name = "SSEC011.6"></a>
<dt><li><code>incomplete <dd></code>
Allows the return of an <code>incomplete</code> coset table, when a coset
enumeration does not finish within preset limits.

If a coset enumeration that invokes <code>ACECosetTableFromGensAndRels</code> or
<code>ACECosetTable</code> does not finish within the preset limits, an error is
raised by the interface to GAP, unless the option <code>silent</code>
(see <a href="CHAP004.htm#SSEC011.3">option silent</a>) or <code>incomplete</code> has been set; in the latter
case, a partial coset table, that is a valid GAP list of lists, is
returned. Each position of the table without a valid coset number
entry is filled with a zero. If the option <code>silent</code> is also set,
<code>incomplete</code> prevails. An incomplete table is
returned reduced (i.e. with insignificant coset numbers --- those
appearing only in their place of definition --- removed) and <code>lenlex</code>
standardised (regardless of whether the <code>semilenlex</code> option is in
force). When an incomplete table is returned, a
warning is emitted at <code>InfoACE</code> or <code>InfoWarning</code> level 1.

<dt><a name = "SSEC011.7"></a>
<dt><li><code>aceinfile:=</code><var>filename</var><code> <dd></code>
Creates an ACE input file <var>filename</var> for use with the standalone
only; <var>filename</var> should be a string. (Shortest abbreviation: <code>acein</code>.)

This option is only relevant to <code>ACECosetTableFromGensAndRels</code> and is
ignored if included as an option for invocations of <code>ACEStats</code> and
<code>ACEStart</code>. If this option is used, GAP creates an input file with
filename <var>filename</var> only, and then exits (i.e. the ACE binary is
not called). This option is provided for users who wish to work
directly with the ACE standalone. The full path to the input file
normally used by ACE (i.e. when option <code>aceinfile</code> is not used) is
stored in <code>ACEData.infile</code>.

<dt><a name = "SSEC011.8"></a>
<dt><li><code>aceoutfile:=</code><var>filename</var><code> <dd></code>
Redirects ACE output to file <var>filename</var>; <var>filename</var> should be a
string. (Shortest abbreviation: <code>aceo</code>.)

This is actually a synonym for the <code>ao</code> option. Please refer
to <a href="CHAP004.htm#SSEC020.1">option ao</a>, for further discussion of this option.

<dt><a name = "SSEC011.9"></a>
<dt><li><code>aceignore:=</code><var>optionList</var><code> <dd></code>
Directs an ACE function to ignore the options in <var>optionList</var>;
<var>optionList</var> should be a list of strings.
(Shortest abbreviation: <code>aceig</code>.)

If a function called with its own options, in turn calls an ACE
function for which those options are not intended, the ACE function
will pass those options to the ACE binary. If those options are
unknown to the ACE interface (and <code>ACEIgnoreUnknownDefault :=
false</code> and <code>aceignoreunknown</code> is not passed;
see <a href="CHAP004.htm#SSEC011.2">ACEIgnoreUnknownDefault</a> and <a href="CHAP004.htm#SSEC011.10">option aceignoreunknown</a>) a warning
is issued. Options that are unknown to the ACE binary are simply
ignored by ACE (and a warning that the option was ignored appears
in the ACE output, which the user will not see unless the
<code>InfoLevel</code> of <code>InfoACE</code> or <code>InfoWarning</code> is set to 1). This option
enables the user to avoid such options being passed at all, thus
avoiding the warning messages and also any options that coincidentally
are ACE options but are not intended for the ACE function being
called.

<dt><a name = "SSEC011.10"></a>
<dt><li><code>aceignoreunknown <dd></code>
Directs an ACE function to ignore any options not known to the
ACE interface.
(Shortest abbreviation: <code>aceignoreu</code>.)

This option is provided for similar reasons to <code>aceignore</code>. Normally,
it is safe to include it, to avoid aberrant warning messages from the
ACE interface. However, fairly obviously, it should not be passed
without a value (or set to <code>true</code>) in the situation where a new ACE
binary has been installed with new options that are not listed among
the fields of <code>KnownACEOptions</code>, which you intend to use. Omitting the
<code>aceignoreunknown</code> option is equivalent to setting it to the value of
<code>ACEIgnoreUnknownDefault</code> (see <a href="CHAP004.htm#SSEC011.2">ACEIgnoreUnknownDefault</a>); i.e. it is
superfluous if <code>ACEIgnoreUnknownDefault := true</code> unless
<code>aceignoreunknown</code> is set to <code>false</code>.

<dt><a name = "SSEC011.11"></a>
<dt><li><code>acenowarnings <dd></code>
Inhibits the warning message ``<code>unknown (maybe new) or bad option</code>''
for options not listed in <code>KnownACEOptions</code>.
(Shortest abbreviation: <code>acenow</code>.)

This option suppresses the warning messages for unknown options (to
the ACE interface), but unlike <code>aceignore</code> and <code>aceignoreunknown</code>
still allows them to be passed to the ACE binary.

<a name = "SSEC011.12"></a>
<dt><li><code>echo</code>
<dt><dt><li><code>echo:=2 <dd></code>
Echoes arguments and options (and indicates how options were handled).

Unlike the previous options of this section, there is an ACE
binary option <code>echo</code>. However, the <code>echo</code> option is handled by the
ACE interface and is not passed to the ACE binary. (If you wish
to put <code>echo</code> in a standalone script use the <code>aceecho</code> option
following.) If <code>echo</code> is passed with the value 2 then a list of the
options (together with their values) that are set via ACE defaults
are also echoed to the screen.

<dt><a name = "SSEC011.13"></a>
<dt><li><code>aceecho <dd></code>
The ACE binary's echo command.

This option is only included so that a user can put an <code>echo</code>
statement in an ACE standalone script. Otherwise, use <code>echo</code>
(above).

<dt><a name = "SSEC011.14"></a>
<dt><li><code>aceincomment:=</code><var>string</var><code> <dd></code>
Print comment <var>string</var> in the ACE input; <var>string</var> must be a string.
(Shortest abbreviation: <code>aceinc</code>.)

This option prints the comment <var>string</var> behind a sharp sign (<code>#</code>) in
the input to ACE. Only useful for adding comments (that ACE
ignores) to standalone input files.

<dt><a name = "SSEC011.15"></a>
<dt><li><code>aceexampleoptions <dd></code>
An internal option for <code>ACEExample</code>.

This option is passed internally by <code>ACEExample</code> to the ACE
interface function it calls, when one invokes <code>ACEExample</code> with
options. Its purpose is to provide a mechanism for the over-riding of
an example's options by the user. The option name is deliberately long
and has no abbreviation to discourage user use.

</dl>


<h2><a name="SECT012">4.12 ACE Parameter Options</a></h2>

<a name = "SSEC012.1"></a>
<li><code>ACEParameterOptions V</code>

is a GAP record, whose fields are the ``ACE Parameter Options''.
The ``ACE Parameter Options'' are options which, if not supplied a
value by the user, are supplied a default value by ACE. In fact,
the ``ACE Parameter Options'' are those options that appear (along
with <code>Group Generators</code>, <code>Group Relators</code> and <code>Subgroup Generators</code>,
which are defined from ACE interface function arguments) in the
``Run Parameters'' block of ACE output, when, for example, the
<code>messages</code> option is non-zero.

For each field (ACE parameter option) of the <code>ACEParameterOptions</code>
record, the value assigned is the default value (or a record of
default values) that are supplied by ACE when the option is not
given a value by the user (either indirectly by selecting a strategy
option or directly).

In the cases where the value of a field of the <code>ACEParameterOptions</code>
record is itself a record, the fields of that record are <code>default</code> and
strategies for which the value assigned by that strategy differs from
the <code>default</code> strategy. A ``strategy'', here, is the strategy option
itself, if it is only a no-value option, or the strategy option
concatenated with any of its integer values (as strings), otherwise
(e.g. <code>felsch0</code> and <code>sims9</code> are strategies, and <code>hlt</code> is both a
strategy and a strategy option). As an exercise, the reader might like
to try to reproduce the table at the beginning of Chapter <a href="CHAP005.htm">Strategy Options for ACE</a> using the <code>ACEParameterOptions</code> record. (Hint: you
first need to select those fields of the <code>ACEParameterOptions</code> record
whose values are records with at least two fields.)

Note:
Where an ``ACE Parameter Option'' has synonyms, only the
``preferred'' option name (see <a href="CHAP004.htm#SSEC010.1">ACEOptionSynonyms</a>) appears as a field
of <code>ACEParameterOptions</code>. The complete list of ``ACE Parameter
Options'' may be obtained by

<pre>
gap> Concatenation( List(RecNames(ACEParameterOptions),
> optname -> ACEOptionData(optname).synonyms) );
[ "path", "subgroup", "max", "time", "fill", "ffactor", "asis", "ct",
 "cfactor", "compaction", "dmode", "dsize", "enumeration", "hole",
 "lookahead", "loop", "mendelsohn", "messages", "monitor", "no", "pmode",
 "psize", "rt", "rfactor", "row", "workspace" ]

</pre>

We describe the ``ACE Parameter Options'' in the Sections <a href="CHAP004.htm#SECT013">General ACE Parameter Options that Modify the Enumeration Process</a>, <a href="CHAP004.htm#SECT014">ACE Parameter Options Modifying C Style Definitions</a>, <a href="CHAP004.htm#SECT015">ACE Parameter Options for R Style Definitions</a>, <a href="CHAP004.htm#SECT016">ACE Parameter Options for Deduction Handling</a>, <a href="CHAP004.htm#SECT017">Technical ACE Parameter Options</a>, <a href="CHAP004.htm#SECT018">ACE Parameter Options controlling ACE Output</a>, and <a href="CHAP004.htm#SECT019">ACE Parameter Options that give Names to the Group and Subgroup</a>, following.


<h2><a name="SECT013">4.13 General ACE Parameter Options that Modify the Enumeration Process</a></h2>


<dl compact>

<dt><a name = "SSEC013.1"></a>
<dt><li><code>asis <dd></code>
Do not reduce relators. (Shortest abbreviation: <code>as</code>.)

By default, ACE freely and cyclically reduces the relators, freely
reduces the subgroup generators, and sorts relators and subgroup
generators in length-increasing order. If you do not want this, you
can switch it off by setting the <code>asis</code> option.

Notes: As well as allowing you to use the presentation as it is
given, this is useful for forcing definitions to be made in a
prespecified order, by introducing dummy (i.e., freely trivial)
subgroup generators. (Note that the exact form of the presentation
can have a significant impact on the enumeration statistics.) For
some fine points of the influence of <code>asis</code> being set on the treatment
of involutory generators see the ACE standalone manual.

<a name = "SSEC013.2"></a>
<dt><li><code>ct:=</code><var>val</var><code></code>
<dt><a name = "SSEC013.2"></a>
<dt><li><code>cfactor:=</code><var>val</var><code> <dd></code>
Number of C style definitions per pass; <code></code><var>val</var><code></code> should be an integer.
(Shortest abbreviation of <code>cfactor</code> is <code>c</code>.)

The absolute value of <code></code><var>val</var><code></code> sets the number of C style definitions
per pass through the enumerator's main loop. The sign of val sets
the style. The possible combinations of the values of <code>ct</code> and <code>rt</code>
(described below) are given in the table of enumeration styles in
Section <a href="CHAP003.htm#SECT001">Enumeration Style</a>.

<a name = "SSEC013.3"></a>
<dt><li><code>rt:=</code><var>val</var><code></code>
<dt><a name = "SSEC013.3"></a>
<dt><li><code>rfactor:=</code><var>val</var><code> <dd></code>
Number of R style definitions per pass; <code></code><var>val</var><code></code> should be an integer.
(Shortest abbreviation of <code>rfactor</code> is <code>r</code>.)

The absolute value of <code></code><var>val</var><code></code> sets the number of R style definitions
per pass through the enumerator's main loop. The sign of val sets
the style. The possible combinations of the values of <code>ct</code> (described
above) and <code>rt</code> are given in the table of enumeration styles in
Section <a href="CHAP003.htm#SECT001">Enumeration Style</a>.

<dt><a name = "SSEC013.4"></a>
<dt><li><code>no:=</code><var>val</var><code> <dd></code>
The number of group relators to include in the subgroup;
<code></code><var>val</var><code></code> should be an integer greater than or equal to −1.

It is sometimes helpful to include the group relators into the list of
the subgroup generators, in the sense that they are applied to coset
number 1 at the start of an enumeration. A value of 0 for this option
turns this feature off and the (default) argument of −1 includes all
the relators. A positive argument includes the specified number of
relators, in order. The <code>no</code> option affects only the C style
procedures.

<dt><a name = "SSEC013.5"></a>
<dt><li><code>mendelsohn <dd></code>
Turns on mendelsohn processing. (Shortest abbreviation: <code>mend</code>.)

Mendelsohn style processing during relator scanning/closing is turned
on by giving this option. Off is the default, and here relators are
scanned only from the start (and end) of a relator. Mendelsohn ``on''
means that all (different) cyclic permutations of a relator are
scanned.

The effect of Mendelsohn style processing is case-specific. It can
mean the difference between success or failure, or it can impact the
number of coset numbers required, or it can have no effect on an
enumeration's statistics.

Note: Processing all cyclic permutations of the relators can be very
time-consuming, especially if the presentation is large. So, all
other things being equal, the Mendelsohn flag should normally be left
off.

</dl>


<h2><a name="SECT014">4.14 ACE Parameter Options Modifying C Style Definitions</a></h2>

<a name = "I2"></a>

The next three options are relevant only for making C style
definitions (see Section <a href="CHAP003.htm#SECT001">Enumeration Style</a>). Making definitions in
C style, that is filling the coset table line by line, it can be very
advantageous to switch to making definitions from the preferred
definition stack. Possible definitions can be extracted from this
stack in various ways and the two options <code>pmode</code> and <code>psize</code>
(see <a href="CHAP004.htm#SSEC014.2">option pmode</a> and <a href="CHAP004.htm#SSEC014.3">option psize</a> respectively) regulate this.
However it should be clearly understood that making all definitions
from a preferred definition stack one may violate the condition of
Mendelsohn's theorem, and the option fill (see option fill) can be
used to avoid this.


<dl compact>

<a name = "SSEC014.1"></a>
<dt><li><code>fill:=</code><var>val</var><code></code>
<dt><a name = "SSEC014.1"></a>
<dt><li><code>ffactor:=</code><var>val</var><code> <dd></code>
Controls the preferred definition strategy by setting the fill factor;
<code></code><var>val</var><code></code> must be a non-negative integer.
(Shortest abbreviation of <code>fill</code> is <code>fil</code>, and shortest abbreviation
of <code>ffactor</code> is <code>f</code>.)

Unless prevented by the fill factor, gaps of length one found during
deduction testing are preferentially filled (see <a href="biblio.htm#Hav91"><cite>Hav91</cite></a>).
However, this potentially violates the formal requirement that all
rows in the coset table are eventually filled (and tested against the
relators). The fill factor is used to ensure that some constant
proportion of the coset table is always kept filled. Before defining a
coset number to fill a gap of length one, the enumerator checks
whether <code>fill</code> times the completed part of the table is at least the
total size of the table and, if not, fills coset table rows in
standard order (i.e. C style; see Section <a href="CHAP003.htm#SECT001">Enumeration Style</a>) instead
of filling gaps.

An argument of 0 selects the default value of ⎣5(n+2)/4 ⎦, where n is the number of columns in the table. This
default fill factor allows a moderate amount of gap-filling. If
<code>fill</code> is 1, then there is no gap-filling. A large value of <code>fill</code>
can cause what is in effect infinite looping (resolved by the coset
enumeration failing). However, in general, a large value does work
well. The effects of the various gap-filling strategies vary widely.
It is not clear which values are good general defaults or, indeed,
whether any strategy is always ``not too bad''.

This option is identified as <code>Fi</code> in the ``Run Parameters'' block
(obtained when <code>messages</code> is non-zero) of the ACE output, since for
the ACE binary, <code>fi</code> is an allowed abbreviation of <code>fill</code>. However,
<code>fi</code> is a GAP keyword and so the shortest abbreviation of <code>fill</code>
allowed by the interface functions is <code>fil</code>.

<dt><a name = "SSEC014.2"></a>
<dt><li><code>pmode:=</code><var>val</var><code> <dd></code>
Option for preferred definitions; <code></code><var>val</var><code></code> should be in the integer
range 0 to 3. (Shortest abbreviation: <code>pmod</code>.)

The value of the <code>pmode</code> option determines which definitions are
preferred. If the argument is 0, then Felsch style definitions are
made using the next empty table slot. If the argument is non-zero,
then gaps of length one found during relator scans in Felsch style are
preferentially filled (subject to the value of <code>fill</code>). If the
argument is 1, they are filled immediately, and if it is 2, the
consequent deduction is also made immediately (of course, these are
also put on the deduction stack). If the argument is 3, then the gaps
of length one are noted in the preferred definition queue.

Provided such a gap survives (and no coincidence occurs, which causes
the queue to be discarded) the next coset number will be defined to
fill the oldest gap of length one. The default value is either 0 or 3,
depending on the strategy selected (see Chapter <a href="CHAP005.htm">Strategy Options for ACE</a>). If you want to know more details, read the code.

<dt><a name = "SSEC014.3"></a>
<dt><li><code>psize:=</code><var>val</var><code> <dd></code>
Size of preferred definition queue; <code></code><var>val</var><code></code> must be 0 or 2n, for
some integer n > 0. (Shortest abbreviation: <code>psiz</code>.)

The preferred definition queue is implemented as a ring, dropping
earliest entries. An argument of 0 selects the default size of 256.
Each queue slot takes two words (i.e., 8 bytes), and the queue can
store up to 2n−1 entries.

</dl>


<h2><a name="SECT015">4.15 ACE Parameter Options for R Style Definitions</a></h2>

<a name = "I3"></a>


<dl compact>

<dt><a name = "SSEC015.1"></a>
<dt><li><code>row:=</code><var>val</var><code> <dd></code>
Set the ``row filling'' option; <code></code><var>val</var><code></code> is either 0 or 1.

By default, ``row filling'' is on (i.e. <code>true</code> or 1). To turn it off
set <code>row</code> to <code>false</code> or 0 (both are translated to 0 when passed to the
ACE binary). When making HLT style (i.e. R style; see
Section <a href="CHAP003.htm#SECT001">Enumeration Style</a>) definitions, rows of the coset table are
scanned for holes after its coset number has been applied to all
relators, and definitions are made to fill any holes encountered. This
will, in particular, guarantee fulfilment of the condition of
Mendelsohn's Theorem. Failure to do so can cause even simple
--> --------------------

--> maximum size reached

--> --------------------

quality99%

¤ Dauer der Verarbeitung: 0.25 Sekunden (vorverarbeitet) ¤

Wurzel

Suchen

Beweissystem der NASA

Beweissystem Isabelle

NIST Cobol Testsuite

Cephes Mathematical Library

Wiener Entwicklungsmethode

Haftungshinweis

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.