



                              Cover
         The Admissible Search Based Machine Learning System
                            Version 2.0
                    Tuesday 16th August, 1995






                            User Manual

                            written by
                            Fred Brkich
                          Geoffrey I. Webb





                School of Computing and Mathematics
                         Deakin University
                  Geelong, Vic.,  3217,  Australia



                School of Computing and Mathematics
                         Deakin University,
                        Geelong  Vic.  3217
                             Australia.
                          (052)  27 2606.

    The user interface for cover has been kept as close as
    possible to the user interface for the commercial induction
    system Einstein.  In particular, many of the command line
    options are identical to the corresponding options for
    Autonomous Einstein and the format of the input files is
    identical to that for Einstein with the exception that cover
    does not accept the input of pre-existing rules for
    refinement.   Sections of this manual are substantially
    copied, with permission, from the Autonomous Einstein User
    Manual. Einstein is distributed by

                UniLink Ltd
                Deakin University
                Geelong, Vic, 3217
                Australia.


Einstein is a registered trademark of UniLink Ltd.
Autonomous Einstein is a trademark of UniLink Ltd.

 * *  Table of Contents
 * *

Section 1:      Machine Learning and Cover

                What you need
                What you get


Section 2:      Quick Start

                What Cover accepts
                Invoking Cover
                Cover Output
                Summary


Section 3:      Cover in Detail

                Domain Data
                Input Files
                Preference Functions
                The OPUS Search Algorithm
                Using Cover
                Output
                Error Formats
                Summary

Section 4:      Domain Information in Detail

                Ordinal Attributes
                Categorical Attributes
                Missing Values
                Summary


Section 5:      Input Files

                Input Files - Declarations Section

                    * Declaration Types
                      integer
                      real
                      name list
                      range

                    * Declaration Qualifiers
                      ordinal
                      nominal
                      optional
                      ignored
                      decision
                      a number
                      Multiple Qualifiers

                    * Declaration Restrictions
                      Attributes
                      Values
                      Total Values

                    DECLARATION ERRORS
                    Declarations Summary


                Input Files - The Examples Section

                    Unobtainable Values
                    Example New File
                    Example Declarations

                    EXAMPLES ERRORS
                    Examples Summary


Section 6:      Rule Evaluation - The Training and Evaluation Sets

                Default Output
                Brief Output


Section 7:      Preference Functions

                Laplace
                Complete and Consistent


Section 8:      Using Cover - The Command Line Arguments

                Entering Commands
                Most Common Decision

                COMMAND LINE ERRORS
                Summary


Section 9:      Output

                Rule Format
                Example Output
                Summary

Machine Learning and Cover

    A machine learning system examines a domain of examples and builds
    a classification rule.  A classification rule, or class
    description, is an expression that describes a class of objects
    or examples.  The nature of the examples which a machine learning
    system examines will vary greatly depending upon the domain to
    which it is being applied.  To provide some illustrations, for a
    medical domain the examples may be patients.  For a mineral
    exploration domain the examples may be geological regions.  For a
    loans approval domain the examples may be loan applications.

    Cover is a machine learning system which will enable you to
    produce classifications in the form of if-then rules, i.e.  each
    classification rule will be a rule which consists of a condition
    and a conclusion.  Cover takes these rules to be true implications
    given the examples it has examined in its training set.

    What You    In order to run Cover you will need the following
    Need        items:

                    * Sun 4 compatible computer
                    * SunOS or Solaris operating system
                    * The Cover program (binary file)
                    * Suitably formatted domain information

    What You    The Cover binary file
    Get         User Manual
                Example Data Files



Quick Start

    The quickest way for you to begin using Cover is to make a copy
    of the supplied file 'people.all' and to then invoke Cover using
    its default settings. This is achieved by using the command line
    'cover people.all' (see below).  By simply adding or removing
    examples of your choice in this file you will be able to observe
    various changes in Cover's output class descriptions.

    What Cover  Input domain information must consist of two parts,
    Accepts     both described more fully below.  The first part
                will basically 'declare' the attributes, the data
                type and form of each attribute, and the variable
                names defining the domain in question. The variable
                names are the values that the attribute may assume.
                The second part will use the attributes so declared to
                describe objects in the domain.  These objects are
                the 'examples'.

                Cover places no restriction on the forms of
                filenames, so you may call your own files by
                whatever names you wish.


    Example     Declarations and Examples from the file 'people.all':
    (Single
     File)
                                  names of two possible values
                                  for attribute 'bachelor'
                                        ----
                                       |    |
         keyword -->    attributes     v    v
                        bachelor:    { yes, no }  decision  <-- keyword
                        gender:      [0:1]                    (qualifier)
                        status:      {married, single}
                        hair_colour: {fair, dark, brown}

         keyword -->    examples
                        0 yes single fair
                        0 yes single brown
                        0 no married dark
                        0 no married fair
                        1 no single fair
                        1 no single brown
                        1 no married dark

    Invoking    You will be able to call Cover in many ways
    Cover       depending upon your individual requirements.
                The simplest way to call Cover is with a single
                argument, the name of an input file.

    Example               $ cover people.all


    Cover       By default, Cover outputs a heading, then a list of
    Output      the rules created, then a summary line. The rules are
                'unordered', in other words, each output rule may be
                understood and considered in isolation from all other
                rules.

    Example Output

                COVER version 1.0
                Copyright (c) 1993 Geoff Webb, Deakin University, Geelong, Australia.

                IF      gender is 0
                        status is single
                THEN bachelor = yes [3/0:3.00]

                IF      gender is 1
                THEN bachelor = no [3/0:3.00]

                IF      status is married
                THEN bachelor = no [2/0:2.00]

                1 fiftieths of a second  (+ 0 input time) for 3 rules from 8 examples


    Summary     This section has just shown you the simplest way to use
                Cover.  It has illustrated the two sorts of data
                that Cover requires ('declarations' and 'examples'),
                and one different way in which Cover is able to
                accept the data.  You have seen the simplest way in
                which Cover may be invoked and an example of Cover's
                default output.  If you modify the given examples
                you will also see a variety of class descriptions.


Cover In Detail

    Given an appropriate preference function and a training set of
    examples, Cover will develop a complete disjunctive class
    description by inferring, in turn, a series of single disjuncts.
    Cover employs two levels of search. At the inner level Cover
    uses a search algorithm (Optimal Pruning for Unordered Search
    (OPUS)) which performs admissible search to build descriptions
    for complex real world domains within reasonable amounts of
    time.  At the outer level Cover searches for a complete
    disjunctive class description in the way covering algorithms
    usually do.

      --------------------------------------------------------
       Admissible search in OPUS examines all possible best
       solutions and is guaranteed to find the best solution.
      --------------------------------------------------------

    Domain      Whichever preference function you choose you will
    Data        need to understand and present relevant domain data
                in a form acceptable to Cover.  Examples you are
                interested in can be described using attributes and
                their associated values.

                Attributes may be qualified as 'ordinal' or 'nominal'.

    Input Files If you want Cover to develop classification rules not
                only must you provide Cover with descriptions of
                attributes and decisions to be considered, you must
                also provide Cover with a set of examples to examine.
                To these ends, you must provide a data file.  A data
		file must be a text file that describes relevant
		attributes and decisions and provides the examples
		with which Cover is to work.

                Examples may be divided into two groups, though this
                is not strictly necessary.  One group providing
                initial 'training' examples, the other group
                providing 'evaluation' examples.  The 'evaluation'
                examples will be used to 'evaluate' the correctness
                of the classification rules Cover has developed
                using the training set.  

    Preference  Currently Cover supports two distinct preference
    Functions   functions: the defaul, Laplace, and 'Complete and
                Consistent'.

    The OPUS    OPUS takes as inputs a preference function, a training
    Search      set of examples, and a set of specialisation
    Algorithm   operators.  It outputs a set of operators, taken
                from the set of specialization operators, that
                creates a classification rule that maximizes the
                preference function with respect to the training set
                of examples.

                ----------------------------------------------------------
                For a detailed discussion of the OPUS algorithm, refer to
                Deakin University School of Computing and Mathematics
                Technical Report C93/17.  An abbreviated version of this
                paper is also available as, G. Webb (1993) "Systematic search
             	for categorical attribute-value data-driven machine
             	learning", In N. Foo & C. Rowles (Eds) AI'93.  World
             	Scientific, Singapore.
                ----------------------------------------------------------

    Using       You may invoke Cover via command line arguments which
    Cover       control three different types of function. The first
                set of arguments control input and output functions.
                The second set controls the strategies employed during
                rule induction.  The final set of arguments controls
                the manner in which rules are applied once
                developed.

    Output      By default, Cover outputs a heading, then a list of
                the classification rules induced, followed by a
                summary line.  If there is an evaluation set, the
                output is concluded with a summary of the
                performance of the rules when applied to the
                evaluation set.  An option exists to allow you to
                select 'brief' output.

    Error       The error messages created by Cover generally take
    Formats     the form of a header, followed by the message
                itself, followed by a trailer. For example:

                        <header><message><trailer>

                where say,

                header  =  FORMAT ERROR:
                message =  Unobtainable values not allowed for decision
                trailer =  on line 4 of people_aux.all.

                Since the header and trailer information, where it
                occurs, is self-explanatory, the discussion of error
                messages in this manual will concentrate on the central
                message itself.

    Summary     In this section you have been given a brief overview
                of each of the remaining sections of this manual,
                including a note about the format of error messages
                in Cover.  With the exception of the details of the
                OPUS search algorithm, which you may obtain as a
                technical report, the remainder of this manual presents
                Cover's details in the order in which they have
                been presented above.  If this is your first encounter
                with Cover you may now consider reading all the
                remaining sections, if not, you may consult those
                which you find relevant for your current purposes.


Domain Information In Detail

    A example will be described to Cover in terms of its attributes.
    Each attribute can be thought of as a topic on which the system
    requires information.  For a medical domain the relevant
    attributes might describe the signs and symptoms exhibited by
    a patient, for example, his or her temperature, pulse and blood
    pressure.  For a mineral exploration domain relevant attributes
    might describe the geological details of the region.  For a
    loans approval domain relevant attributes might describe the
    financial status of the applicant.

    Ordinal      Ordinal attributes are ordered.  That is, it makes
    Attributes   sense to say of any two values of an ordinal
                 attribute, that one is less than the other.  For
                 example, the values high, normal, and low will be
                 ordinal if it makes sense to say that low is less
                 than high.

                 ------------------------------------------------------
                 Caution: Cover's treatment of ordinal values in
                 version 2.0 has not been refined and is extremely
                 inefficient and possibly faulty. Use it with care.
                 ------------------------------------------------------


    Categorical  All attributes that are not ordinal are categorical.
    Attributes   For example, the values male and female for a gender
                 attribute are categorical, as it does not make sense to
                 say that one is less than the other.  Note that
                 numbers are often used to record values for categorical
                 attributes.  For example, the values for a gender
                 attribute may be recorded as 0 or 1 where 0
                 represents male and 1 represents female.  In this case
                 it is important to qualify the attribute as
                 'nominal'.  Otherwise, Cover will assume that 0 is
                 less than 1 and develop classification rules
                 accordingly.

    Missing      In some circumstances, it will not be possible to
    Values       provide values for all attributes for all examples.
                 For instance, some tests may be expensive or even
                 dangerous to perform, and so are only performed
                 occasionally.  As a result, the information,
                 although important, may be available only for a
                 subset of the data.  Cover uses a special attribute
                 value, unobtainable, to represent missing values.
                 An attribute may only have unobtainable values if
                 the attribute is declared with the keyword 'optional'.

    Summary      You have now been given a brief overview of each of the
                 remaining sections in the Cover User Manual.  With
                 the exception of the OPUS search algorithm, the
                 remainder of this manual presents the essential
                 features of Cover in the order in which they have
                 been presented above.  If this is your first
                 encounter with Cover you may prefer to read all of
                 the remaining sections, if not, you may consult
                 only those sections relevant to your current needs.


Input Files

    A data file may store examples and declarations associated with
    the particular project you are working on.  It may have two
    sections.  First is the declarations section.  Second may come
    the examples section.  The declarations section defines the
    attributes that are to be used by the system.  The examples
    section provides the values for the attributes for each example.

    Should you choose to present declarations and examples in
    separate files you may do so, and provide the relevant command
    line arguments when you invoke Cover (see below, 'Using Cover -
    The Command Line Arguments').


Input Files - Declarations Section

    The declarations section starts with the keyword 'attributes'.
    This is followed by the attribute declarations. Each attribute
    declaration starts with the attribute's name. This is followed
    by a colon.  Next appear the type specification and declaration
    qualifiers in any order.

    * Declaration Types

      A type specification consists of one of the following -

      integer     the keyword 'integer' (for an integer attribute);

      real        the keyword 'real' (for a real attribute);  or

      name list   a list of names enclosed in '{' and '}'
                  brackets (for an attribute whose values are names
                  rather than numbers.) 

      Example     {low, medium, high}
      Name List

      range       - two integer numbers enclosed in '[' and ']' brackets
                  and separated by a colon (':').  This specifies an
                  attribute that may assume any integer value greater
                  than or equal to the first value and less than or
                  equal to the second value.  A range attribute that
                  is declared to be ordinal (see below) is treated as
                  an integer attribute.  In this case, there is no
                  attempt to limit the input values for the attribute
                  to the declared range.  The intended use for a range
                  is to create categorical numeric attributes.

      Example     [1:10]
      Range
      Specifier


    * Declaration Qualifiers

      The following declaration qualifiers are allowed -

      ordinal     - for ordinal attributes.  Real and integer
                  attributes must be ordinal and do not require an
                  ordinal declaration qualifier.  If a name list is
                  declared to be ordinal then the values are
                  considered ordered in the sequence they appear in
                  the name list declaration.  The first value is
                  lowest and the last value is highest.

      nominal     - for nominal attributes.  The nominal declaration
                  qualifier is not permitted for real and integer
                  attributes.  Name lists and ranges default to
                  nominal.  As a result, it should never be
                  necessary to explicitly include this declaration.

      optional    - for attributes that may have unobtainable values.
                  Declaring as optional attributes that do not have 
                  unobtainable values increases the number of values
		  in a nominal attribute and slows the system, but has 
		  no other effect.  Failing to declare an attribute
		  that has unobtainable values as 'optional' will
		  result in an error when the examples are read into
		  the system. 

      ignored     - for attributes that appear in the examples section
                  but which Cover should ignore.  Type specifications
		  for ignored attributes are not enforced.  Any name or
		  number will be accepted as a value for an ignored
		  attribute.

      decision    - declares that the attribute represents a decision.
                  Decisions must be nominal attributes.
                  The decision may appear at any point in the list
                  of attribute values.

                  There must be exactly one decision attribute for
                  each project.

      a number    (following the declaration of a real attribute)
                  specifies the precision (number of significant
                  decimal places) for that attribute.  The default
                  precision is 2. If a value for an attribute of a
                  example is specified to greater than the declared
                  precision it is rounded off to the closest value
                  within the allowed precision.  A number may only
                  appear as a declaration qualifier for a real
                  attribute.

      Multiple    In some situations Cover allows you to qualify
      Qualifiers  value declarations with more than one qualifier
                  keyword. For example,

                   <attribute name>: { names++ } ordinal optional

                  is acceptable (see 'Input Files - The Examples
                  Section' for an illustration).


      All declarations should appear on a single line with the
      single exception that name lists may be spread over multiple
      lines.

      The names of attributes and of the values for a name list
      attribute must start with an alphabetic character and can
      include any printable characters other than '[', ']', '{',
      '|', '}', '~', ',', ':' and '!'.  The case of alphabetic
      characters is not significant.  For example, 'low' and 'LOW'
      are treated as identical.  A name may be any length, but any
      characters after the first twenty are ignored by Cover.


    * Declaration Restrictions

      Attributes  A new project file may contain up to 128 attributes
                  and one decision.

      Values      Nominal attributes are restricted to a maximum of
                  128 values.

      Total       Cover will not accept a project with more than
      Values      1,000 values in total.


      DECLARATION ERRORS

      The following is a list of most commonly encountered errors
      relating to declarations. It includes those errors which
      violate declarations restrictions in the current version of
      Cover.


      "Missing keyword ATTRIBUTES"

            When Cover assumes it is reading a declarations file,
            but encounters anything other than the keyword 'attributes'
            on the first line.

      "Encountered unexpected text following keyword ATTRIBUTES"

            When Cover encounters anything but an end of line character
            after the keyword 'attributes'.

      "Missing ':'"

            When Cover has already read an attribute name and is
            expecting to read a colon but reads something else.

      "No decision declared"

            One of the declared attributes must be qualified
            with the keyword 'decision' before Cover is able to
            build classification rules. This error message occurs
            when you have not done this.

      "<qualifier> qualifier not permitted in this context"

            Occurs when an inappropriate keyword qualifier is used
            to qualify a value declaration.  For example, the
            keyword 'real' must not be used to qualify a value name
            list.

      "<declaration type> not permitted in this context"

            <declaration type> may be either "range
            specification" or "name list specification".


      "<qualifier> is not an allowed qualifier"

            Occurs when Cover cannot recognise <qualifier> as a
            valid qualifier keyword.

      "Missing <item> in range specification"

            <item> may refer to an opening or closing square
            bracket, an integer value, or a colon. Remember that
            the correct form for a range specification is
            '[<integer>:<integer>]'.

      "Syntax error in name list"

            Within a name list, value names must be syntactically
            correct.

      "Number of declared attributes exceeds system capacity"

            More than 128 attributes have been declared.

      "Unobtainable values not allowed for decision"

            It is not permissible to use the keyword 'optional'
            together with the keyword 'decision' to qualify a
            list of value names.

      "Maximum must be larger than minimum"

            The maximum value (or second value) in a range must be
            larger than the minimum value (or first value).

      "Number of declared attribute values exceeds system capacity"

            The total number of values for a project cannot exceed
            1,000.


    Declarations    The 'Input Files - Declarations Section' has
    Summary         provided you with a detailed look at the
                    'declarations ' component of Cover's input data.
                    This included discussions of declaration data
                    types and qualifiers, declaration restrictions,
                    and int he case of attributes a suggested way of
                    overcoming those restrictions.  You have been
                    presented with the syntax which Cover recognizes
                    for names, and finally with a list of errors you
                    may encounter relating to the declarations
                    section of your input.  The following
                    sub-section of 'Input Files' will present a
                    detailed discussion of the second part of
                    Cover's required input data, your examples.


Input Files - The Examples Section

    The declarations section may be followed by the examples section.
    If it is, the examples section is introduced by the keyword
    'examples'.  If it is not, your examples must be presented to
    Cover in a separate file, and the keyword 'examples' must NOT be
    used.  In any event, Cover will accept any number of examples.
    Each example is represented by a list of attribute values in the
    order they were declared in the attribute declarations.  Each
    value must be separated from the next by at least one of a
    space, a tab, or a comma.


    Unobtainable  unobtainable values are marked by the inclusion of
    Values        a question mark '?' in place of the value of an attribute.


    The following shows the contents of a new file 'people_aux.all',
    which is a simple extension of the data file 'people.all'
    presented in 'Quick Start'.  Six attributes are declared and
    seven examples are provided.

    Example       attributes
    New File      gender:       [0:1]
                  bachelor:     { yes, no }  decision
                  weight:       { slim, medium, chubby } optional
                  status:       { single, married }
                  hair_colour:  { fair, dark, brown }  optional

                  examples
                  0 yes slim   single  fair
                  0 yes slim   single  ?
                  0 yes slim   single  dark
                  0 no  medium married fair
                  1 no  slim   single  ?
                  1 no  chubby single  brown
                  1 no  ?      married dark


    Example       - gender, an integer range, where 0 indicates
    Declarations    that the individual is male, and 1 indicates
                    the individual is female.
                  - bachelor, a nominal attribute with two values,
                    either a person's bachelor attribute is 'yes',
                    or else it is 'no'; in short a person is either
                    a bachelor or is not.
                  - weight, an attribute which can assume any
                    one of the values slim, medium, or chubby.
                  - status, a nominal attribute with two values,
                    'single', or 'married'.
                  - hair_colour, an optional nominal attribute
                    that can assume either of the values 'fair',
                    'brown' or (because it is optional) unobtainable.


    The decision condition, may have either of the values 'yes'
    or 'no'.  This decision represents a simple bachelorhood
    classification (people are either bachelors or not).


    A semantic interpretation of the examples may be constructed in a
    straightforward way, as you can see for the following two
    examples:

    Example 1     The decision is yes (for bachelor), the gender is
                  male, the weight is slim, the status is single,
		  and the value of hair_colour is fair.

    Example 5     The decision is no (for not a bachelor), the gender is
                  female, the weight is slim, the status is single, and
		  the value of hair_colour is unobtainable.


    EXAMPLES ERRORS

    EXAMPLES errors are those that result from the mistaken
    formatting or entry of descriptions into the 'examples' data
    base. They include the following:

    "Too few values"

           When input data is expected but an end of line character
           is met instead.


    "Unobtainable values not allowed for attribute <attribute>"

           When '?' (the unobtainable character) is parsed as a
           value for an attribute that has not been declared
           "optional".

    "Invalid value, <value>, for attribute <attribute>"

           When the input is not '?' (the unobtainable character)
           and its data type is 'range' but its <value> is greater
           than the maximum allowed for this <attribute> or less
           than zero.

    "Encountered <input> when expecting a value for attribute <attribute>"

           When the input is not '?' (the unobtainable character)
           and Cover is expecting a list, but the data type of
           <input> is 'integer' or 'real'.

    "Encountered <input> when expecting a value for <attribute>"

           When <input> is neither '?' (the unobtainable character)
           nor a valid 'name'.

    "Value too large for attribute <attribute name>"

           When the input value is larger than the maximum
           specified for the range.

    "Too many values"

           When all declared attributes have been processed but we
           still have neither reached the end of a line of example
           input nor reached end of file.

    Examples        The 'Input Files - The Examples Section' has presented
    Summary         you with a detailed illustration of an example data
                    file, based on previously specified data
                    declarations.  You have seen how to specify
                    unobtainable values, how to apply qualifiers,
                    including the keyword 'decision'.  A
                    straightforward semantic interpretation of the
                    given examples has been developed, and a list of
                    error messages associated with the examples
                    section has been presented. This section
                    concludes the detailed discussion of what Cover
                    expects from its data input.


Rule Evaluation - The Training and Evaluation Sets

    Cover develops and revises rules by examining examples of
    correct decision making that you provide it.  Each example is
    described by a set of attribute values and the correct decision.

    -------------------------------------------------------------------
    Note:  By default, the classification rules produced by Cover are
    'unordered', in other words, each rule can be understood and
    considered in isolation from all others.
    -------------------------------------------------------------------

    The set of examples that Cover uses to develop a classification
    rule, or a group of classification rules, is called the
    'training set'.

    One of the most effective means of evaluating a classification rule
    is to measure how many examples it correctly handles in practice.
    Cover enables such evaluation through the use of the -evaluation-file
    command. This command causes Cover to load the examples in an
    examples file into the evaluation set. 

    After constructing classification rules, if any examples are in the
    evaluation set, the rules are applied to the evaluation set and
    the results output.

    Default     Most common decision accuracy.  This is the accuracy
    Output      obtained by a single rule that assigns to all examples
                the decision found most commonly in the training
                set.

                Cover.  This is the percentage of examples from the
                evaluation set to which a decision was assigned.

                Accuracy table.  This contains the following
                information, both for each decision, and a summary
                for all decisions -

                -   the number of examples of the decision to which
                    the rules assigned a decision.

                -   the number and percentage of those examples for which
                    the decision was correct.

                -   the number and percentage of those examples for which
                    the decision was incorrect.

                -   the number of examples to which the decision was
                    assigned.

                -   the number and percentage of those examples for which
                    the decision was correct.

                -   the number and percentage of those examples for which
                    the decision was incorrect.

		Number of nodes expanded.  This is the number of nodes
		that Cover expanded during the search.



Preference Functions

    A preference function is a function which provides a numeric
    evaluation of a description such that the higher the evaluation
    the higher the preference for the description.  Such a function
    will generally take account of the performance of the
    description when applied to the training set and may consider
    other factors such as the complexity of the description.  A
    range of such preference functions is supported by Cover.

    Laplace                         pos_cover(D) + 1
    (default)     value(D) =  ------------------------------
                              total_cover(D) + no_of_classes


                  Where D       = Decription currently being considered
                  pos_cover(D)  = number of examples covered by D that
                                  belong to the class with which D is
                                  associated
                  total_cover   = total number of examples covered by D
                  no_of_classes = number of classes in the domain


    Complete and  This preference function is governed by a simple
    Consistent    rule:
    
                       If    neg_cover(D) > 0
                       then  value(D) = - neg_cover(D)
                       else  value(D) = pos_cover(D)

                  Where,
                  neg_cover(D)  = number of examples covered by D that
                                  belong to the class(es) with which
                                  D is not associated



Using Cover - The Command Line Arguments

    Cover expects at least one filename and any number of
    other arguments, each of which starts with the '-' character.
    The filename is taken as the name of the primary input
    file.  The primary input file must contain the domain model
    definition (attributes section) and may also contain an examples
    section.  Additional training examples may be read from a
    subsequent input files and additional evaluation
    examples may be read from an evaluation file (flagged with
    -evaluation-file). If there is no input file specified,
    the primary file is read from standard input.

    Entering    Any argument not starting with '-' is treated as an
    Commands    unflagged file name.  Multiple word arguments have the
		words separated by '-' characters.  Each word may be
		abbreviated.  Some arguments have parameters.  These
		are linked to the argument by an '=' character.

    Example               $ cover people.all -best-rules-only

                This command will run Cover on the data file 'people.all'
		developing the best rule for each class only.


    <name>    the first name is taken as the name of a new project
              file.  If no name is specified, this defaults to
              standard input.  All subsequent names are treated as the
	      names of data files.

    -append-decision-list
	      develop a decision list using the append strategy.
	      (See Webb, 1994).

    -best-rules-only
	      develop one rule only for each class, the rule that
	      maximises the preference function.

    -consistent
	      use the maximum consistent preference function.

    -depth-first
	      use depth-first search.
	      (See Webb, 1995).

    -equality-tests
              use tests of the form <att> is <val>.

    -evaluation-file=<name>
	      load the evaluation set from the file with name <name>.

    -fixed-order
	      use fixed-order search in place of OPUS.
	      (See Webb, 1995).

    -no-further-pruning
	      disable further pruning during search.
	      (See Webb, 1995).

    -no-optimistic-reordering
	      disable optimistic reordering during search.
	      (See Webb, 1995).

    -no-optimistic-pruning
	      disable optimistic pruning during search.
	      (See Webb, 1995).

    -prepend-decision-list
	      use the prepend strategy to develop a decision list.
	      (See Webb, 1994).


    COMMAND LINE ERRORS

    "Ignored switch <flag>"

            If the command line <flag> is unrecognised then this
            message will be displayed, and processing will continue.

    "Illegal value for test percentage - <test_percent>"

            You have used the 's' flag to set the percentage
            probability that an example will be moved from the set
            of training examples to the set of evaluation examples,
            but either have not indicated <test_percent>, in which
            case it remains at the default 0%, or else you have
            tried to set a value greater than 99%.

    Summary     The various ways in which you may use Cover is
                determined by the various options Cover makes
                available to you on the command line.  This section
                has presented you with all the available commands, a
                short discussion on how to enter them, and lastly it
                has presented you with a list of command line
                errors.  The following section will illustrate the
                sort of output Cover can produce for you.


Output

    By default, Cover outputs a heading, then a list of the rules
    created followed by a summary line.  If there is an evaluation set,
    the output is concluded with a summary of the performance of the
    rules when applied to the evaluation set.


    Rule        A rule starts with the keyword IF.  This is followed by the
    Format      clauses, one to a line.  A clause for an ordinal attribute
                takes one of the following forms - name = value, name <=
                value, name >= value, or value <= name <= value.
                A clause for any other attribute takes the form name is
                value1 or value2 ...  or value<n>.  Following the
                clauses is a line taking the form THEN class
                attribute = class.


    The summary line states the number of CPU fiftieths of a second
    taken to develop the rules, the number of fiftieths of a second CPU
    time taken to input the examples, the number of rules
    developed and the number of examples in the training set.

    See above for a description of the summary of performance.


    Example     If you enter the command 'cover people_aux.all' on the
    Output      command line, the following output will be produced:

                COVER version 1.0
                Copyright (c) 1993 Geoff Webb, Deakin University, Geelong, Australia.

                IF      gender is 0
                        status is single
                THEN bachelor = yes [3/0:3.00]

                IF      gender is 1
                THEN bachelor = no [3/0:3.00]

                IF      status is married
                THEN bachelor = no [1/0:1.00]

                0 fiftieths of a second  (+ 0 input time) for 3 rules from 7 examples


    Summary     In this section you have been presented with an
                illustration of Cover's output, together with a
                description of the rule format which Cover employs.


References

   G. Webb (1993) "Systematic search for categorical attribute-value
   data-driven machine learning", In N. Foo & C. Rowles (Eds) AI'93. 
   World Scientific, Singapore.

   G. Webb (1995) "OPUS: An efficient admissible search algorithm for
   unordered search".  To be published.
