singnet / asmoses

Port of MOSES (https://github.com/opencog/moses) for the AtomSpace (https://github.com/opencog/atomspace)
Other
6 stars 5 forks source link

Atomese Deme Representation Building Step #105

Open behailu04 opened 4 years ago

behailu04 commented 4 years ago

Deme Representation Building Step in Combo

Overview

The deme representation building step in combo a two-way process. First is creating a program subspace surrounding that exemplar. This part is the Representation building of deme representation building. The second process is converting instance into programs which are getting candidate programs from the built representation.

    1. Representation Building.
    2. Converting Instance into programs.

1. Representation Building

The step will do the representation building and creates a fieldset for a given exemplar. The representation building step of deme representation building step is:

=> Building Knobs

In this step, the exemplar is canonized and knobs are added to the exemplar.

For example:- for boolean cases make the top node either a logical_and or a logical_or.

Knob turning is done by applying rules on the exemplar these rules include inserting null_vertex, appending not, given node flattening the subtree, erasing subtree. Finally, if there exists a setting for a given node a knob is created and the specific location of the knob will be stored. If there are no settings the created knobs in the first step it will be deleted.

After compeleting the recursive knob probing step the knob mapper will map the specifications of the knob which are knob settings and the knob in the created representation.

=> Converting the knobs into fieldset:-

a reverse-lookup table is built for the knobs according to the exemplar. That is given an iterator pointing into the exemplar, fetch the corresponding knob if there exists any.

2. Converting Instance into a program

Converting instance into the program creates a combo tree that corresponds to the instance. In this step, knobs are searched in a recursive manner and their values are appended then-new candidate program is generated.

Deme Representation Building Step Example

Exemplar = and($1 $2)

Step one: Representation building. Building knobs:

The canonization will result in: Exemplar = or(and($1 $2))

build knobs: There are two iterators pointing to exemplar one is used for pointing to the beginning of the exemplar and the other will be used to iterate over the exemplar and make the changes.

                pre_it subtree = or(and($1 $2))
                pre_it it = or(and($1 $2))

After recursive operation after cleaning up exemplar:-

Exemplar = or(and(or($1) $2) and(null_vertex(or($1 $2)))) The location of discrete knobs are :- [and(or($1) $2), $1, $2, null_vertex(or($1 $2))] Created prototype:- or([and nil !and](or([$1 nil !$1]) [$2 nil !$2]) and([nil or]($1 $2)))

Step Two: Converting Instance into a program

Converting Instances into exemplar:
        Instance inst = 0
        combo_tree candidate = and($1 $2)
        Instance inst = 1
        combo_tree candidate = true
        Instance inst = 2
        combo_tree candidate = or(!$1 !$2)

Deme Representation building step in Atomese

The difference between atomese and combo representation is basically on the way of exploring through the exemplar and changing it. Operation on combo tree are mutable that is changing the subtree of the exemplar will change the whole exemplar and vice versa. In the case of Atomese since Atomese programs are immutable and changing sub hypergraph forms an new exemplar. Changes must made on both the exemplar and the sub hypergraph. The other aspect here is in combo tree representation building the location of the knobs is stored are changes will be made to the exemplar at specific location, for atomese case I suggest also storing the incoming atom of the specific location. like, for example, if

Exemplar = (OR_LINK(
                AND_LINK(
                    PredicateNode $1
                    PredicateNode $2)<=
                PredicateNode $2))       

_Knob_loc = (PredicateNode $2)   The location is of the knob is the one with the arrow.
_knob = (PredicateNode $2)/(NotLink(PredicateNode $2))

    Let's the the selected instance uses the knob :- _knob = (NotLink(PredicateNode $2))
The candidate program created should be:

    Handle candidate = (OR_LINK(
                         AND_LINK(
                            (PredicateNode $1)
                            (NotLink(PredicateNode $2))
                        PredicateNode $2))

When searching is made and change is made this is what is generated:
    Handle candidate = (OR_LINK(
                         AND_LINK(
                            (PredicateNode $1)
                            (PredicateNode $2))
                         NotLink(PredicateNode $2))))

=> I believe this problem can be resolved by also storing the incoming set of the location because changing the knobs inside a hypergraph with the same incoming set have a similar impact on the overall result of the hypergraph.