view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        This could be pretty similar to initial_facts, with the difference
        that the initial facts are used more with the causes of the rules
        and this one with the goals (usually one in a well defined knowledge
        database).

        The same rule of initial_facts apply here, you can provide the sign
        of the facts and you can provide the id or the name of them.

        From our example of symptoms and diseases lets imagine we have the
        hypothesis that a patient has flu, we don't know the symptoms it
        has, we want the expert system to keep asking us for them to make
        sure that our hypothesis is correct (or incorrect in case there's
        not enough information).

    goals_to_check_dict
        Very similar to goals_to_check (and indeed of initial_facts_dict).
        We want to make the job easier.

        It will be a dictionary made of the data of goals_to_check.

    inference_facts
        Inference facts are basically the core of an expert system. These
        are facts that are found and copied when a set of facts (initial,
        inference or asked) match with the causes of a goal.

        inference_facts is a AI::ExpertSystem::Advanced::Dictionary, it will
        store the name of the fact, the rule that caused these facts to be
        copied to this dictionary, the sign and the algorithm that triggered
        it.

    knowledge_db
        The object reference of the knowledge database
        AI::ExpertSystem::Advanced is using.

    asked_facts
        During the backward() algorithm there will be cases when there's no
        clarity if a fact exists. In these cases the backward() will be
        asking the user (via automation or real questions) if a fact exists.

        Going back to the initial_facts example of symptoms and diseases.
        Imagine the algorithm is checking a rule, some of the facts of the
        rule make a match with the ones of initial_facts or inference_facts
        but some wont, for these *unsure* facts the backward() will ask the
        user if a symptom (a fact) exists. All these asked facts will be
        stored here.

    visited_rules
        Keeps a record of all the rules the algorithms have visited and also
        the number of causes each rule has.

    verbose
            my $ai = AI::ExpertSystem::Advanced->new(
                    viewer_class => 'terminal',
                    knowledge_db => $yaml_kdb,
                    initial_facts => ['I'],
                    verbose => 1);

        By default this is turned off. If you want to know what happens
        behind the scenes turn this on.

        Everything that needs to be debugged will be passed to the debug()
        method of your viewer.

    viewer
        Is the object AI::ExpertSystem::Advanced will be using for printing
        what is happening and for interacting with the user (such as asking
        the asked_facts).

        This is practical if you want to use a viewer object that is not
        provided by AI::ExpertSystem::Advanced::Viewer::Factory.

    viewer_class
        Is the the class name of the viewer.

        You can decide to use the viewers
        AI::ExpertSystem::Advanced::Viewer::Factory offers, in this case you
        can pass the object or only the name of your favorite viewer.

    found_factor
        In your knowledge database you can give different *weights* to the
        facts of each rule (eg to define what facts have more *priority*).
        During the mixed() algorithm it will be checking what causes are
        found in the inference_facts and in the asked_facts dictionaries,
        then the total number of matches (or total number of certainity
        factors of each rule) will be compared versus the value of this
        factor, if it's higher or equal then the rule will be triggered.

        You can read the documentation of the mixed() algorithm to know the
        two ways this factor can be used.

    shot_rules
        All the rules that are shot are stored here. This is a hash, the key
        of each item is the rule id while its value is the precision time
        when the rule was shot.

        The precision time is useful for knowing when a rule was shot and
        based on that you can know what steps it followed so you can compare
        (or reproduce) them.

Constants
    * FACT_SIGN_NEGATIVE
        Used when a fact is negative, aka, a fact doesn't happen.

    * FACT_SIGN_POSITIVE
        Used for those facts that happen.

    * FACT_SIGN_UNSURE
        Used when there's no straight answer of a fact, eg, we don't know if
        an answer will change the result.

Methods
  shoot($rule, $algorithm)
    Shoots the given rule. It will do the following verifications:

    *   Each of the facts (causes) will be compared against the
        initial_facts_dict, inference_facts and asked_facts (in this order).

    *   If any initial, inference or asked fact matches with a cause but
        it's negative then all of its goals (usually only one by rule) will
        be copied to the inference_facts with a negative sign, otherwise a
        positive sign will be used.