Strict Standards: Non-static method DB::connect() should not be called statically, assuming $this from incompatible context in /group/project/aicat/web/lib/database.php on line 32

Strict Standards: Non-static method DB::parseDSN() should not be called statically, assuming $this from incompatible context in /usr/share/pear/DB.php on line 520

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in /usr/share/pear/DB.php on line 557

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in /group/project/aicat/web/lib/database.php on line 34

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in /group/project/aicat/web/lib/database.php on line 92

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in /usr/share/pear/DB/common.php on line 1009

Strict Standards: Non-static method DB::isManip() should not be called statically, assuming $this from incompatible context in /usr/share/pear/DB/common.php on line 2200

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in /group/project/aicat/web/lib/database.php on line 97

Strict Standards: Non-static method DB::connect() should not be called statically, assuming $this from incompatible context in /group/project/aicat/web/lib/database.php on line 32

Strict Standards: Non-static method DB::parseDSN() should not be called statically, assuming $this from incompatible context in /usr/share/pear/DB.php on line 520

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in /usr/share/pear/DB.php on line 557

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in /group/project/aicat/web/lib/database.php on line 34Catalogue of Artificial Intelligence Techniques

Typed Preconditions

In early problem solving systems (e.g., STRIPS )
and planning languages (e.g., PLANNER) the operators
were given a single set of preconditions which
were always interpreted as `test if true, or subgoal to make them
true'. The need to distinguish between the case in which the planner
should only check if something was already true or should be allowed
to add further actions into a plan to make the condition true was
recognised as an important search control mechanism in
POPLER. This led to two different types of
precondition. Additions were also made to various pattern directed
invocation systems which clustered alternative methods together and
made a choice from them on the basis of some pre-occurring fact.
The utility of typed preconditions and their different properties
for both hierarchic domain description and planner Search
Space control was investigated in the
NONLIN planner which recognised four precondition
types: SUPERVISED, UNSUPERVISED, USEWHEN and ACHIEVE.