[GRASS-SVN] r57193 - grass-addons/grass6/general/g.infer
svn_grass at osgeo.org
svn_grass at osgeo.org
Wed Jul 17 07:28:03 PDT 2013
Author: gisix
Date: 2013-07-17 07:28:02 -0700 (Wed, 17 Jul 2013)
New Revision: 57193
Modified:
grass-addons/grass6/general/g.infer/description.html
Log:
g.infer: description.html reformatting
Modified: grass-addons/grass6/general/g.infer/description.html
===================================================================
--- grass-addons/grass6/general/g.infer/description.html 2013-07-17 13:33:10 UTC (rev 57192)
+++ grass-addons/grass6/general/g.infer/description.html 2013-07-17 14:28:02 UTC (rev 57193)
@@ -273,10 +273,10 @@
Template based, non ordered facts allow to structure the content of
a fact by assessing data fields by name (and type). The
-<b>deftemplate</b> construct is used to create a named template (which
-can then be used to access fields by name). This approach is used to
-import GRASS layers in <em>g.infer</em> to create the respective
-facts.
+<b>deftemplate</b> construct is used to create a named template
+(which can then be used to access fields by name). This approach
+is used to import GRASS layers in <em>g.infer</em> to create the
+respective facts.
<p>
The deftemplate construct allows the name of a template to be
@@ -289,87 +289,110 @@
<p>
-Deftemplate facts are easily distinguished from ordered facts by their first field.
-If the symbol serving as the first field corresponds to the name of a deftemplate,
-then the fact is a deftemplate fact. Like ordered facts, deftemplate facts are enclosed
-by an opening parenthesis on the left and a closing parenthesis on the right.
+Deftemplate facts are easily distinguished from ordered facts by
+their first field. If the symbol serving as the first field
+corresponds to the name of a deftemplate, then the fact is a
+deftemplate fact. Like ordered facts, deftemplate facts are enclosed
+by an opening parenthesis on the left and a closing parenthesis
+on the right.
<p>
-In addition to being asserted and retracted, deftemplate facts can also be modified and duplicated
-(using the <b>modify</b> and <b>duplicate</b> commands).
-Modifying a fact changes a set of specified slots within that fact.
-Duplicating a fact creates a new fact identical to the original fact and then
-changes a set of specified slots within the new fact.
-The benefit of using the modify and duplicate commands is that slots which do not change,
+In addition to being asserted and retracted, deftemplate facts
+can also be modified and duplicated (using the <b>modify</b> and
+ <b>duplicate</b> commands). Modifying a fact changes a set of
+ specified slots within that fact. Duplicating a fact creates a
+ new fact identical to the original fact and then changes a set
+ of specified slots within the new fact. The benefit of using the
+ modify and duplicate commands is that slots which do not change,
can be left out in the statement.
<p>
-Examples are provided in the built-in rule bases via the library-option and in the CLIPS User's Guide and Basic Programming Guide.
+Examples are provided in the built-in rule bases via the
+library-option and in the CLIPS User's Guide.
<p>
<b>Template based Facts for GRASS Layers</b>
<p>
-Whenever a GRASS layer is imported by g.infer,
-a template is created according to its data structure and facts are asserted for the layers content.
-While the template for vector layers will differ depending on the attribute layers,
-raster data templates adhere to the following structure:
+Whenever a GRASS layer is imported by g.infer, a template is
+created according to its data structure and facts are asserted
+for the layers content.While the template for vector layers will
+differ depending on the attribute layers, raster data templates
+adhere to the following structure:
<p>
-Raster: <pre>(geo_test "a comment" (x 599000.0) (y 4921800.0) (value 5) (attribute "something"))</pre>
+Raster: <pre>(geo_test "a comment" (x 599000.0) (y 4921800.0)
+(value 5) (attribute "something"))</pre>
Vector: <pre>SOIL EXAMPLE (field as point layer)</pre>
-Rast3d: <pre>(random_slice_00009 (x 599000.0) (y 4921800.0) (z 9.0) (value 1.0))</pre>
+Rast3d: <pre>(random_slice_00009 (x 599000.0) (y 4921800.0) (z 9.0)
+(value 1.0))</pre>
<p>
-<pre>"_slice_000009" has been added by <em>g.infer</em> for internal reference.</pre>
+<pre>"_slice_000009" has been added by <em>g.infer</em> for
+internal reference.</pre>
<h4>Rules</h4>
<p>
-The primary method of representing and modifing knowledge in <em>g.infer</em> are rules.
-Any <em>g.infer</em> rulebase comprises of a set of rules which collectively
- solve a classification task, establish a workflow or do similar. Rules are used to represent heuristics, or "rules of thumb",
-which specify a set of actions to be performed for a given situation.
-Rules can cause actions such as the creation, modification or deletion of facts or the call-up of GRASS modules and scripts.
+The primary method of representing and modifing knowledge in
+<em>g.infer</em> are rules. Any <em>g.infer</em> rulebase comprises
+of a set of rules which collectively solve a classification task,
+establish a workflow or do similar. Rules are used to represent heuristics,
+or "rules of thumb", which specify a set of actions to be performed
+for a given situation. Rules can cause actions such as the creation,
+modification or deletion of facts or the call-up of GRASS modules and scripts.
A rule is composed of an <b>antecedent</b> and a <b>consequent</b>.
-The antecedent of a rule is also referred to as the <b>if portion</b> or the <b>left hand side (LHS)</b> of the rule.
-The consequent of a rule is also referred to as the <b>then portion</b> or the <b>right hand side (RHS)</b> of the rule.
+The antecedent of a rule is also referred to as the <b>if portion</b>
+or the <b>left hand side (LHS)</b> of the rule.
+The consequent of a rule is also referred to as the <b>then portion</b>
+ or the <b>right hand side (RHS)</b> of the rule.
<p>
-The <b>antecedent of a rule</b> (LHS) is a set of conditions (or conditional elements) which must be satisfied for the rule to be applicable.
-The conditions of a rule are satisfied based on the existence or non existence of specified facts in the fact list
+The <b>antecedent of a rule</b> (LHS) is a set of conditions
+(or conditional elements) which must be satisfied for the rule
+to be applicable. The conditions of a rule are satisfied based on
+the existence or non existence of specified facts in the fact list
or specified instances of user defined classes in the instance list.
One type of condition which can be specified is a<b> pattern</b>.
-Patterns consist of a set of restrictions which are used to determine which facts or objects satisfy the condition specified by the pattern.
+Patterns consist of a set of restrictions which are used to determine
+which facts or objects satisfy the condition specified by the pattern.
<p>
-The process of matching facts and objects to patterns is called <b>pattern matching</b>. A mechanism, called the <b>inference engine</b>,
-matches patterns against the current state of the fact list and instance list and determines which rules are applicable during the inference run.
+The process of matching facts and objects to patterns is called
+<b>pattern matching</b>. A mechanism, called the <b>inference engine</b>,
+matches patterns against the current state of the fact list and
+instance list and determines which rules are applicable during the
+inference run.
<p>
-The <b>consequent of a rule</b> (RHS) is the set of actions to be executed when the rule is applicable.
-This is colloquially refefred to as "the rule fires".
-The actions of applicable rules are executed when the inference engine is instructed to begin execution of applicable rules.
-If more than one rule is applicable,
-the inference engine uses a <b>conflict resolution strategy</b> to determine which rule should fire first.
-The actions of the selected rule are executed (which can change the overall list of applicable rules).
-Afterwards the inference engine selects another rule and executes its actions.
+The <b>consequent of a rule</b> (RHS) is the set of actions to be
+executed when the rule is applicable. This is colloquially refefred
+to as "the rule fires". The actions of applicable rules are executed
+when the inference engine is instructed to begin execution of applicable rules.
+If more than one rule is applicable, the inference engine uses a
+<b>conflict resolution strategy</b> to determine which rule should
+fire first. The actions of the selected rule are executed (which can
+change the overall list of applicable rules). Afterwards the inference
+engine selects another rule and executes its actions.
This process continues until no applicable rules remain.
<p>
-In many ways, rules can be thought of as IF - THEN statements found in procedural programming languages.
-However, the conditions of an IF - THEN statement in a procedural language are only evaluated when the
-program flow of control is directly at the IF - THEN statement.
+In many ways, rules can be thought of as IF - THEN statements found
+in procedural programming languages. However, the conditions of an
+IF - THEN statement in a procedural language are only evaluated when
+the program flow of control is directly at the IF - THEN statement.
In contrast, rules act like WHENEVER - THEN statements.
-The inference engine always keeps track of rules which have their conditions satisfied and thus rules
-can immediately be executed when they are applicable.
-In this sense, rules are similar to exception handlers found in other programming languages.
+The inference engine always keeps track of rules which have their
+conditions satisfied and thus rules can immediately be executed when
+they are applicable.In this sense, rules are similar to exception
+handlers found in other programming languages.
<p>
<h4>Comments</h4>
-Rulebase content and other CLIPS code can be commented by starting lines with a semicolon.
+Rulebase content and other CLIPS code can be commented by starting
+lines with a semicolon.
<p>
@@ -377,96 +400,120 @@
<h4>Variables</h4>
Variables in CLIPS are weakly typed.
They are not restricted to a predefined data type.
-So when creating a variable, it is not required to provide typing information.
+So when creating a variable, it is not required to provide typing
+information.
-The <b>defglobal</b> construct allows variables to be defined which are global in scope throughout the CLIPS environment.
-Such a global variable can be accessed anywhere in the CLIPS environment and
-retains its value independent of other constructs.
-In contrast, some constructs (such as defrule and deffunction) allow local variables to be defined
-within the definition of the construct.
-These local variables can be referred to within the construct, but have no meaning outside the construct.
+The <b>defglobal</b> construct allows variables to be defined which
+are global in scope throughout the CLIPS environment.
+Such a global variable can be accessed anywhere in the CLIPS environment
+and retains its value independent of other constructs.
+In contrast, some constructs (such as defrule and deffunction) allow local
+variables to be defined within the definition of the construct.
+These local variables can be referred to within the construct, but have
+no meaning outside the construct.
<h4>Functions</h4>
-A function in CLIPS is a piece of executable code identified by a specific name
-which returns a useful value or performs a side effect (such as printing a message).
+A function in CLIPS is a piece of executable code identified by a
+specific name which returns a useful value or performs a side effect
+(such as printing a message).
<p>
The <b>defun</b> command is used to define new functions.
-The body of a deffunction is a series of expressions similar to the RHS of a rule
-that are executed in order by the CLIPS inference engine when the deffunction is called.
-The return value of a deffunction is the value of the last expression evaluated within the deffunction.
+The body of a deffunction is a series of expressions similar to
+the RHS of a rule that are executed in order by the CLIPS inference
+engine when the deffunction is called. The return value of a deffunction
+is the value of the last expression evaluated within the deffunction.
Calling a deffunction is identical to calling any other function in CLIPS.
<p>
-Function Definition Example: <pre>(defun fahrenheit_celsius (celsius_value) (+ (* celsius_value 1.8) 32))</pre>
-<p>Examples are provided in the built-in rule bases (library option) and in the CLIPS User's Guide and Basic Programming Guide.
+Function Definition Example:
+<pre>(defun fahrenheit_celsius (celsius_value) (+ (* celsius_value 1.8) 32))</pre>
+<p>Examples are provided in the built-in rule bases (library option) and
+in the CLIPS User's Guide and Basic Programming Guide.
<h4>Conditionals</h4>
Examples for conditions, comparing facts and variables with each other,
-are provided in the built-in rule bases (library option) and in the CLIPS User's Guide and Basic Programming Guide.
+are provided in the built-in rule bases (library option) and in the
+CLIPS User's Guide and Basic Programming Guide.
<h3>Rulebase Development, Operation and Debugging:</h3>
-<em>g.infer</em> is a tool to set up and operate rule-based workflows for information classification and data processing.
-The workflow will be loaded via a 'rulebase'-file or a built in rulebase, consisting of a set of rules, called a knowledge base. <p>
-Rule activiation is controlled by the <em>g.infer</em> rule engine, based on spatial data from the GIS layers.
+<em>g.infer</em> is a tool to set up and operate rule-based workflows
+for information classification and data processing. The workflow will be
+loaded via a 'rulebase'-file or a built in rulebase, consisting of a set
+of rules, called a knowledge base. <p>
+Rule activiation is controlled by the <em>g.infer</em> rule engine,
+based on spatial data from the GIS layers.
-When a rule is activated for the first time, it is placed on the <b>agenda</b>, based (in order) on the following factors:
+When a rule is activated for the first time, it is placed on the <b>agenda</b>,
+based (in order) on the following factors:
<p>
-a) Newly activated rules are placed above all rules of lower salience and below all rules of higher salience.
+a) Newly activated rules are placed above all rules of lower salience
+and below all rules of higher salience.
<p>
-b) Among rules of equal salience, the current conflict resolution strategy is used to determine the placement among the other rules of equal salience.
+b) Among rules of equal salience, the current conflict resolution strategy
+is used to determine the placement among the other rules of equal salience.
<p>
-c) If a rule is activated (along with several other rules) by the same assertion or retraction of a fact,
-and steps a and b are unable to specify an ordering, then the rule is arbitrarily (not randomly)
-ordered in relation to the other rules with which it was activated.
-In this respect, the order in which rules are defined has an arbitrary effect on conflict resolution
+c) If a rule is activated (along with several other rules) by the same
+assertion or retraction of a fact, and steps a and b are unable to specify
+an ordering, then the rule is arbitrarily (not randomly) ordered in relation
+to the other rules with which it was activated. In this respect, the order
+in which rules are defined has an arbitrary effect on conflict resolution
(which is also dependent upon the current underlying implementation of rules).
-This arbitrary ordering for the proper execution of rules should not be depended on for knowledge modelling.
+This arbitrary ordering for the proper execution of rules should not be
+depended on for knowledge modelling.
<p>
Once a knowledge base (in the form of rules) has been loaded into <em>g.infer</em>
-and the fact and instance lists are available, the inference engine is ready to execute rules:
+and the fact and instance lists are available, the inference engine
+is ready to execute rules:
<p>
<ul>
-<li><b>a)</b>The right hand side (RHS) actions of the selected rule are executed.
-The use of the return function on the RHS of a rule may remove the current focus from the focus stack.
-The number of rules fired is incremented for use with the rule firing limit.
+<li><b>a)</b>The right hand side (RHS) actions of the selected rule
+are executed. The use of the return function on the RHS of a rule may
+remove the current focus from the focus stack. The number of rules fired
+is incremented for use with the rule firing limit.
<li><b>b)</b> As a result of step b, rules may be activated or deactivated.
Activated rules, whose conditions are currently satisfied,
are placed on the agenda of the module in which they are defined.
-The placement on the agenda is determined by the salience of the rule and the current conflict resolution strategy.
-Deactivated rules are removed from the agenda.
+The placement on the agenda is determined by the salience of the rule and
+the current conflict resolution strategy. Deactivated rules are removed
+from the agenda.
<li><b>c)</b> If dynamic salience is being used,
the salience values for all rules on the agenda are reevaluated.
Repeat the cycle beginning with step a.
-<li><b>d)</b>If a previously defined rule firing limit has been reached or there is no current focus,
-then execution is halted. The top rule on the agenda of the module which is the current focus is selected for execution.
-If there are no rules on that agenda, then the current focus is removed from the focus stack
-and the current focus becomes the next module on the focus stack.
-If the focus stack is empty, then execution is halted, otherwise step a is executed again.
+<li><b>d)</b>If a previously defined rule firing limit has been reached
+or there is no current focus, then execution is halted. The top rule on
+the agenda of the module which is the current focus is selected for execution.
+If there are no rules on that agenda, then the current focus is removed
+from the focus stack and the current focus becomes the next module on
+the focus stack. If the focus stack is empty, then execution is halted,
+otherwise step a is executed again.
</ul>
<p>
-Whenever a rule modifies a specific fact, the particular fact is retracted, that is,
-removed from the fact stack and a new (altered)
+Whenever a rule modifies a specific fact, the particular fact is retracted,
+that is, removed from the fact stack and a new (altered)
fact is instantiated and added on the fact stack. <p>
-A rule base can be designed to act similar to the r.mapcalc module. This requires a close coupled multistage design of the rule base.
+A rule base can be designed to act similar to the r.mapcalc module.
+This requires a close coupled multistage design of the rule base.
<p>
-It is easily possible to construct a rule set which acts like an infinity-loop,
-which never terminates. This is in the most part undesired, but may be an asset for monitoring activities.
+It is easily possible to construct rule sets which act like an infinity-loop,
+which never terminates. This is in the most part undesired,
+but may be an asset for monitoring activities.
<p>
-<pre>Examples are provided in the built-in rule bases (library option) and in the CLIPS User's Guide and Basic Programming Guide.</pre>
+<pre>Examples are provided in the built-in rule bases (library option)
+ and in the CLIPS User's Guide and Basic Programming Guide.</pre>
<p>
@@ -474,88 +521,103 @@
<h4>Conflict Resolution</h4>
-When more than one rule are eglible to fire, a priorization among the candidate rules is needed.
-Rules can be explicitly assigned a rank/priority called <b>salience</b>.
+When more than one rule are eglible to fire, a priorization among the
+candidate rules is needed. Rules can be explicitly assigned a rank/priority
+called <b>salience</b>.
<p>
-The <b>conflict resolution strategy</b> is an implicit mechanism for specifying the order in which rules of equal salience should be executed.
+The <b>conflict resolution strategy</b> is an implicit mechanism for specifying
+the order in which rules of equal salience should be executed.
<p>
-<em>g.infer</em> provides seven conflict resolution strategies. The default strategy is depth.
-The current strategy can be set by using the set strategy command (which will reorder the agenda based upon the new strategy):
+<em>g.infer</em> provides seven conflict resolution strategies.
+The default strategy is depth. The current strategy can be set by using the set
+strategy command (which will reorder the agenda based upon the new strategy):
<p>
<ul>
-<li><b>Breadth Strategy (breadth)</b>: Newly activated rules are placed below all rules of the same salience.
+<li><b>Breadth Strategy (breadth)</b>: Newly activated rules are placed below
+all rules of the same salience.
<li><b>Complexity Strategy (complexity)</b>:
-Among rules of the same salience, newly activated rules are placed above all activations of rules with equal or lower specificity.
+Among rules of the same salience, newly activated rules are placed above all
+activations of rules with equal or lower specificity.
<li><b>Depth (depth: default)</b>:
Newly activated rules are placed above all rules of the same salience.
<li><b>LEX Strategy (lex)</b>:
-Among rules of the same salience, newly activated rules are placed using the OPS5 strategy of the same name.
-First the recency of the pattern entities that activated the rule is used to determine where to place the activation.
+Among rules of the same salience, newly activated rules are placed using
+the OPS5 strategy of the same name. First the recency of the pattern entities
+that activated the rule is used to determine where to place the activation.
Every fact and instance is marked internally with a "time tag" to indicate its
relative recency with respect to every other fact and instance in the system.
-The pattern entities associated with each rule activation are sorted in descending order for determining placement.
-An activation with a more recent pattern entities is placed before activations with less recent pattern entities.
+The pattern entities associated with each rule activation are sorted in descending
+order for determining placement. An activation with a more recent pattern
+entities is placed before activations with less recent pattern entities.
<li><b>MEA Strategy (mea)</b>: Among rules of the same salience,
newly activated rules are placed using the OPS5 strategy of the same name.
-First the time tag of the pattern entity associated with the first pattern is used to determine where to place the activation.
+First the time tag of the pattern entity associated with the first pattern
+is used to determine where to place the activation.
An activation thats first pattern's time tag is greater than another activations
first pattern's time tag is placed before the other activation on the agenda.
If both activations have the same time tag associated with the first pattern,
then the LEX strategy is used to determine placement of the activation.
As with the CLIPS LEX strategy, negated patterns have pseudo time tags.
<li><b>Simplicity Strategy (simplicity)</b>:
-Among rules of the same salience,
-newly activated rules are placed above all activations of rules with equal or higher specificity.
+Among rules of the same salience, newly activated rules are placed above all
+activations of rules with equal or higher specificity.
<li><b>Random Strategy (random)</b>:
-Each activation is assigned a random number which is used to determine its placement among activations of equal salience.
+Each activation is assigned a random number which is used to determine its
+placement among activations of equal salience.
</ul>
<p>
<h5>Salience</h5>
-The preferred mechanisms in <em>g.infer</em> for ordering the execution of rules are explicitly assigned salience values
-and knowledge base grouping using modules.
-Salience allows one to explicitly specify that one rule should be executed before another rule.
+The preferred mechanisms in <em>g.infer</em> for ordering the execution of rules
+are explicitly assigned salience values and knowledge base grouping using
+modules. Salience allows one to explicitly specify that one rule should be
+executed before another rule.
<p>
Options to apply salience values:
<ul>
-<li><b>when-defined (default)</b>: salience evaluation at the time of rule definition
-<li><b>when-activated</b>: salience evaluation at the time of rule definition and upon being activated
-<li><b>every-cycle</b>: salience values will be calculated dynamically at run-time between rule firings
+<li><b>when-defined (default)</b>: salience evaluation at the time of rule
+definition
+<li><b>when-activated</b>: salience evaluation at the time of rule definition
+and upon being activated
+<li><b>every-cycle</b>: salience values will be calculated dynamically at
+run-time between rule firings
</ul>
<h5>Defmodules</h5>
- Modules allow one to explicitly specify that all of the rules in a particular group (module)
- should be executed before all of the rules in a different group.
+ Modules allow one to explicitly specify that all of the rules in a particular
+ group (module) should be executed before all of the rules in a different group.
<p>
-Defmodules allow a knowledge base to be partitioned. Every construct defined must be placed in a module.
-The programmer can explicitly control which constructs in a module are visible to other modules
-and which constructs from other modules are visible to a module.
-The visibility of facts and instances between modules can be controlled in a similar manner.
+Defmodules allow a knowledge base to be partitioned. Every construct defined
+must be placed in a module. The programmer can explicitly control which
+constructs in a module are visible to other modules and which constructs
+from other modules are visible to a module. The visibility of facts and
+instances between modules can be controlled in a similar manner.
Modules can also be used to control the flow of execution of rules.
-<pre>Examples are provided in the CLIPS User's Guide and Basic Programming Guide.</pre>
+<pre>Examples are provided in the CLIPS User's Guide and Basic Programming
+Guide.</pre>
<h4>Agenda</h4>
-The <b>agenda</b> is the list of all rules which have their conditions satisfied (and have not yet been executed).
-If the knowledge base is partitioned into multiple modules, each module has its own agenda.
-The agenda acts similar to a stack (the top rule on the agenda is the first one to be executed).
+The <b>agenda</b> is the list of all rules which have their conditions
+satisfied (and have not yet been executed). If the knowledge base is
+partitioned into multiple modules, each module has its own agenda.
+The agenda acts similar to a stack (the top rule on the agenda is
+the first one to be executed).
-
-
-
<b>Focus</b>
<p>
-The current focus determines which agenda the run command uses during execution.
-The reset and clear commands automatically set the current focus to the MAIN module.
+The current focus determines which agenda the run command uses during
+execution. The reset and clear commands automatically set the current
+focus to the MAIN module.
<p>
@@ -563,21 +625,28 @@
<h4>Logging and Debugging</h4>
<p>
-Several features of <em>g.infer</em> support the development and debugging of rule-bases:
+Several features of <em>g.infer</em> support the development and debugging
+of rule-bases:
<p>
<h4>Debugging: <em>g.infer</em> Flags for Logging, Interaction and Abort:</h4>
<ul>
<li><b>x-Flag</b>: Stop-option:
-The stop-option terminates <em>g.infer</em> following an optional invocation of a interactive CLIPS shell and before the automated inference run.
+The stop-option terminates <em>g.infer</em> following an optional invocation
+of a interactive CLIPS shell and before the automated inference run.
<li><b>i-Flag</b>: Interactive CLIPS shell:
The launching of an CLIPS shell before the automated inference run allows to
-query interactively all aspects of the current CLIPS session. <b>Ctrl-D</b> exits from the interactive Shell.
+query interactively all aspects of the current CLIPS session. <b>Ctrl-D</b>
+exits from the interactive Shell.
<li><b>e-Flag</b>: Traceback-Mode: CLIPS error messages are forwarded to g.infer.
-<li><b>d-Flag</b>: Dribble-Mode: All CLIPS entities which are listed via the FOO-option are written down to file for follow-up analysis.
-<li><b>save-instances</b>: Allows to save COOL constructs, facts, instances to an ASCII file
-<li><b>bsave-instances</b>: Allows to save COOL constructs, facts, instances to a binary file.
+<li><b>d-Flag</b>: Dribble-Mode: All CLIPS entities which are listed via the
+Trace-option are written down to file for follow-up analysis.
+<li><b>save-instances</b>: Allows to save COOL constructs, facts, instances
+to an ASCII file
+<li><b>bsave-instances</b>: Allows to save COOL constructs, facts, instances
+to a binary file.
-<li><b>watch-Option</b>: Prints watch messages for CLIPS constructs. These are stored to file if the dribble-flag has been set.
+<li><b>watch-Option</b>: Prints watch messages for CLIPS constructs.
+These are stored to file if the dribble-flag has been set.
</ul>
@@ -587,37 +656,52 @@
<ul>
<li><b>activations</b>: All rule activations and deactivations will be displayed.
-<li><b>compilations</b>: If compilations are watched, the progress of construct definitions will be displayed.
+<li><b>compilations</b>: If compilations are watched, the progress of
+construct definitions will be displayed.
<li><b>deffunctions</b>: The start and finish of deffunctions will be displayed.
<li><b>facts</b>: All fact assertions and retractions will be displayed.
<li><b>focus</b>: Changes to the current focus will be displayed.
-<li><b>genericfunctions</b>: The start and finish of generic functions will be displayed.
+<li><b>genericfunctions</b>: The start and finish of generic functions will
+be displayed.
<li><b>globals</b>: Variable assignments to globals variables will be displayed.
<li><b>instances</b>: Creation and deletion of instances will be displayed.
-<li><b>methods</b>: The start and finish of individual methods within a generic function will be displayed.
+<li><b>methods</b>: The start and finish of individual methods within a
+generic function will be displayed.
<li><b>messagehandlers</b>: FOO
<li><b>messages</b>: The start and finish of messages will be displayed.
<li><b>rules</b>: All rule firings will be displayed.
<li><b>slots</b>: Changes to any instance slot values will be displayed.
-<li><b>statistics</b>: Timing information along with other information (average number of facts, average number of activations, etc.)
-will be displayed after a run. Note that the number of rules fired and timing information is not printed unless this item is being watch.
-<li><b>all</b>: If all is watched, then all other watch items will be watched. By default, only compilations are watched.
+<li><b>statistics</b>: Timing information along with other information
+(average number of facts, average number of activations, etc.)
+will be displayed after a run. Note that the number of rules fired and
+timing information is not printed unless this item is being watch.
+<li><b>all</b>: If all is watched, then all other watch items will be watched.
+By default, only compilations are watched.
</ul>
<h4>Config-Option</h4>
<DT><b>config</b></DT>
<DD>Configuration options for CLIPS engine: auto-float-dividend,
-dynamic-constraint-checking,fact-duplication,incremental-reset,reset-globals,sequence-operator-recognition,static-constraint-checking.
+dynamic-constraint-checking,fact-duplication,incremental-reset,
+reset-globals,sequence-operator-recognition,static-constraint-checking.
<ul>
-<li><b>auto-float-dividend</b>: the dividend of the division function is automatically converted to a floating point number
-<li><b>dynamic-constraint-checking</b>: Slot values are checked for constraint violations (FALSE by default).
-<li><b>fact-duplication</b>: A duplicate fact is asserted with a new fact?index (FALSE by default).
-<li><b>incremental-reset</b>: Newly defined rules are updated based upon the current state of the fact-list (TRUE by default).
-<li><b>reset-globals</b>: Global variables are reset to their original values when the reset command is performed(TRUE by default).
-<li><b>sequence-operator-recognition</b>: Multifield variables are expanded and passed as separate arguments in the function call (FALSE by default).
-<li><b>static-constraint-checking</b>: Constraint violations are checked when function calls and constructs are parsed (TRUE by default).
+<li><b>auto-float-dividend</b>: the dividend of the division function
+is automatically converted to a floating point number
+<li><b>dynamic-constraint-checking</b>: Slot values are checked for
+constraint violations (FALSE by default).
+<li><b>fact-duplication</b>: A duplicate fact is asserted with a new
+fact-index (FALSE by default).
+<li><b>incremental-reset</b>: Newly defined rules are updated based upon
+the current state of the fact-list (TRUE by default).
+<li><b>reset-globals</b>: Global variables are reset to their original
+values when the reset command is performed(TRUE by default).
+<li><b>sequence-operator-recognition</b>: Multifield variables are
+expanded and passed as separate arguments in the function call
+(FALSE by default).
+<li><b>static-constraint-checking</b>: Constraint violations are checked
+when function calls and constructs are parsed (TRUE by default).
</ul>
</DD>
@@ -626,25 +710,31 @@
<DD>Class default of CLIPS engine: convenience(default),conservation
<ul>
-<li><b>convenience</b>: (default) In convenience mode, for the purposes of role inheritance,
-system defined class behave as concrete classes; for the purpose of pattern-match inheritance,
-system defined classes behave as reactive classes unless the inheriting class is abstract;
-and the default setting for the create-accessor facet of the class slots is read-write.
-<li><b>conservation</b>: The role and reactivity of system-defined classes is unchanged for the purposes of role
-and pattern-match inheritance and the default setting for the create-accessor facet of the class slots is ?NONE.
+<li><b>convenience</b>: (default) In convenience mode, for the purposes
+of role inheritance, system defined class behave as concrete classes;
+for the purpose of pattern-match inheritance, system defined classes behave
+as reactive classes unless the inheriting class is abstract; and the default
+setting for the create-accessor facet of the class slots is read-write.
+<li><b>conservation</b>: The role and reactivity of system-defined classes
+is unchanged for the purposes of role and pattern-match inheritance and
+the default setting for the create-accessor facet of the class slots is ?NONE.
</ul></DD>
</DL>
<h4>Rulebase Libraries</h4>
<em>g.infer</em> provides several pre-configured rulebases.
-The rulebases from the library can be used alone or in combination by user-defined rulebases.
-They provide a basic interactive user interface to launch specific demo applications and can also be started from the CLIPS prompt (using the <b>(run)</b> command).
-All demo rulebases contain extensive comments to document their functionaility for the interested user.
+The rulebases from the library can be used alone or in combination by
+user-defined rulebases. They provide a basic interactive user interface
+to launch specific demo applications and can also be started from the
+CLIPS prompt (using the <b>(run)</b> command). All demo rulebases contain
+extensive comments to document their functionaility for the interested user.
<ul>
-<li><b>reference</b>: Multiple examples CLIPS-language related programming including facts, rules, templates, etc..
-<li><b>spearfish</b>: Examples on the use of GRASS modules in rule based programming. This library requries the Spearfish ("spearfish60") location.
+<li><b>reference</b>: Multiple examples CLIPS-language related programming
+including facts, rules, templates, etc..
+<li><b>spearfish</b>: Examples on the use of GRASS modules in rule based
+programming. This library requries the Spearfish ("spearfish60") location.
</ul>
@@ -653,38 +743,49 @@
-<em>g.infer</em> extends the pyCLIPS- amd CLIPS environments with several commands to communicate and interact the GRASS GIS:
+<em>g.infer</em> extends the pyCLIPS- amd CLIPS environments with several
+commands to communicate and interact the GRASS GIS:
<ul>
-<li><b>ginfer_printout</b>: Extends the CLIPS printout command for use in g.infer:
-(defrule duck_print1 (animal-is duck) => (ginfer_printout t "Demo: ginfer_printout T CRLF" crlf)
+<li><b>ginfer_printout</b>: Extends the CLIPS printout command for
+use in g.infer:
+(defrule duck_print1 (animal-is duck) =>
+(ginfer_printout t "Demo: ginfer_printout T CRLF" crlf)
(ginfer_printout stdout "Demo: ginfer_printout STDOUT CRLF" crlf))
<li><b>ginfer_readline</b>: Extends the CLIPS readline command for g.infer:
-(defrule duck_ask1 (animal-is duck) => (ginfer_printout t "Demo: ginfer_read: Feedback, please:" crlf)
+(defrule duck_ask1 (animal-is duck) =>
+(ginfer_printout t "Demo: ginfer_read: Feedback, please:" crlf)
(assert (ducky1 (ginfer_read t)))(ginfer_printout t " " crlf))
<li><b>grass_message</b>: Uses the g.message module to print messages:
(defrule verbose_python_call0 (verbose on) =>
(assert (examine sections))(python-call grass_message "GRASS_MESSAGEd: works!"))
<li><b>grass_run_command</b>: Invokes a GRASS module from within the CLIPS shell:
-(defrule grassrun_glist (verbose on) => (python-call grass_run_command "g.list" "f" "type=rast,vect"))
+(defrule grassrun_glist (verbose on) =>
+(python-call grass_run_command "g.list" "f" "type=rast,vect"))
</ul>
<p>
-Examples of the invocation of GRAS modules as part of the RHS ofrules are provided in the built in demo rule bases.
+Examples of the invocation of GRASS modules as part of the RHS of rules
+are provided in the built in demo rule bases.
<p>
<h3>CLIPS Object Oriented Language</h3>
-The CLIPS Object Oriented Language (<b>COOL</b>) includes elements of data abstraction and knowledge representation.
-It supports abstraction, encapsulation, inheritance, polymorphism and dynamic binding.
-An overview of COOL as a whole, incorporating the elements of both concepts is given in
-the CLIPS Basic Programming Guide.
+The CLIPS Object Oriented Language (<b>COOL</b>) includes elements of
+data abstraction and knowledge representation. It supports abstraction,
+encapsulation, inheritance, polymorphism and dynamic binding.
+An overview of COOL as a whole, incorporating the elements of both
+concepts is given in the CLIPS Basic Programming Guide.
-The primary difference between objects and templates (or non ordered) facts is the notion of inheritance.
-Inheritance allows the properties and behavior of a class to be described in terms of other classes.
-COOL supports multiple inheritance: a class may directly inherit slots and message?handlers from more than one class.
-Since inheritance is only useful for slots and message - handlers, it is often not meaningful to inherit from one of the primitive type classes,
-such as MULTIFIELD or NUMBER. This is because these classes cannot have slots and usually do not have message - handlers.
+The primary difference between objects and templates (or non ordered)
+facts is the notion of inheritance. Inheritance allows the properties
+and behavior of a class to be described in terms of other classes.
+COOL supports multiple inheritance: a class may directly inherit slots
+and message-handlers from more than one class.
+Since inheritance is only useful for slots and message - handlers,
+it is often not meaningful to inherit from one of the primitive type classes,
+such as MULTIFIELD or NUMBER. This is because these classes cannot
+have slots and usually do not have message - handlers.
<h2>EXAMPLES</h2>
@@ -698,35 +799,48 @@
Browne P. (2009) JBOSS Drools Business Rules. Packt Publishing. ISBN 1-847-19606-3
<p>
-Forgy C., (1982) Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem", Artificial Intelligence, 19, pp 17–37
+Forgy C., (1982) Rete: A Fast Algorithm for the Many Pattern/
+Many Object Pattern Match Problem", Artificial Intelligence, 19, pp 17–37
<p>
Friedman-Hill E. (2003). Jess in Action. Manning Publications. ISBN 1-930-11089-8<p>
-Garosi F. (2008). PyCLIPS Manual Release 1.0. URL http://sourceforge.net/projects/pyclips/files/pyclips/pyclips-1.0/pyclips-1.0.7.348.pdf/download
+Garosi F. (2008). PyCLIPS Manual Release 1.0.
+URL http://sourceforge.net/projects/pyclips/files/pyclips/pyclips-1.0/pyclips-1.0.7.348.pdf/download
<p>
-Giarratano J., Gary R. (2004). Expert Systems: Principles and Programming. Course Technology. ISBN 0-534-38447-1<p>
+Giarratano J., Gary R. (2004). Expert Systems: Principles
+and Programming. Course Technology. ISBN 0-534-38447-1<p>
-Giarratano, J.C. (2007). CLIPS User's Guide. URL http://clipsrules.sourceforge.net/documentation/v630/ug.pdf<p>
+Giarratano, J.C. (2007). CLIPS User's Guide.
+URL http://clipsrules.sourceforge.net/documentation/v630/ug.pdf<p>
-Giarratano, J.C. (2007). CLIPS Reference Manual: Basic Programming Guide. URL http://clipsrules.sourceforge.net/documentation/v630/bpg.pdf<p>
+Giarratano, J.C. (2007). CLIPS Reference Manual: Basic Programming Guide.
+URL http://clipsrules.sourceforge.net/documentation/v630/bpg.pdf<p>
-Giarratano, J.C. (2008). CLIPS Reference Manual: Advanced Programming Guide. URL http://clipsrules.sourceforge.net/documentation/v630/apg.pdf<p>
+Giarratano, J.C. (2008). CLIPS Reference Manual: Advanced Programming Guide.
+URL http://clipsrules.sourceforge.net/documentation/v630/apg.pdf<p>
Graham P. (1995). ANSI Common Lisp. Prentice Hall, ISBN 0-133-79875-6 <p>
-Löwe P. (2004). Technical Note - A Spatial Decision Support System for Radar-Metereology in South Africa. Transactions in GIS. 8(2):235-244. Blackwell Publishing Ltd. Oxford.<p>
+Löwe P. (2004). Technical Note - A Spatial Decision Support System for
+Radar-Metereology in South Africa. Transactions in GIS. 8(2):235-244.
+Blackwell Publishing Ltd. Oxford.<p>
-Löwe P. (2004). Methoden der Künstlichen Intelligenz in Radarmeteorologie und Bodenerosionsforschung (Dissertation). URL http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/759/ <p>
+Löwe P. (2004). Methoden der Künstlichen Intelligenz in Radarmeteorologie
+und Bodenerosionsforschung (Dissertation). URL http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/759/ <p>
-Jackson P. (1998). Introduction to Expert Systems. Addison Wesley. ISBN 0-201-87686-8 <p>
+Jackson P. (1998). Introduction to Expert Systems. Addison Wesley.
+ISBN 0-201-87686-8 <p>
-Puppe F. (1993) Systematic Introduction to Expert Systems. Springer. ISBN 3-540-56255-9<p>
+Puppe F. (1993) Systematic Introduction to Expert Systems. Springer.
+ISBN 3-540-56255-9<p>
-Riley G., (2008). The History of CLIPS. URL http://clipsrules.sourceforge.net/WhatIsCLIPS.html#History<p>
+Riley G., (2008). The History of CLIPS.
+URL http://clipsrules.sourceforge.net/WhatIsCLIPS.html#History<p>
-Rudolph G. (2008). Some Guidelines For Deciding Whether To Use a Rule Engine. URL http://www.jessrules.com/jess/guidelines.shtml<p>
+Rudolph G. (2008). Some Guidelines For Deciding Whether To Use a Rule Engine.
+URL http://www.jessrules.com/jess/guidelines.shtml<p>
More information about the grass-commit
mailing list