Re: Implementing a PLN ForwardInferenceStep using the pattern matcher

[Ben Goertzel]

Continuing...

I suggested something like

> P ==> Q
>
> where
>
> P = Atom $A is in the AttentionalFocus
>
> Q = Execute ForwardInferenceStep( $A)
>
> In Scheme this might look like
>
> ****
> (define pln-forward-step
> (BindLink
> ;; The variable to be bound
> (VariableNode "$var")
> (ImplicationLink
> ;; The pattern to be searched for
> (EvaluationLink
> (GroundedPredicateNode inAttentionalFocus)
> (Atom $var)
> )
>
> ;; The value to be returned.
> (ExecutionLink ForwardInferenceStep "$var")
> )
> )
> )
>
> ;; Run the above pattern
> (cog-bind pln-forward-step)
>
> ****

where ForwardInferenceStep wraps up

***
2-- choosing a PLN Rule R to use (perhaps using weights derived via
experience, etc.)

3-- if the Rule R is unary (like inversion), applying it to A, and
putting the result into the Atomspace

4-- if the Rule R is binary (like deduction) finding another Atom B
that is suitable, and applying R to A and B to get a result... and
putting the result in the Atomspace
***

Of course, one could also break ForwardInferenceStep, as defined
above, into smaller pieces, and then write the process like:

***
(define pln-forward-step
(BindLink
;; The variable to be bound
(VariableNode "$var")
(ImplicationLink
;; The pattern to be searched for
(EvaluationLink
(GroundedPredicateNode inAttentionalFocus)
(Atom "$var")
)

;; The value to be returned.
(BindLInk
;; The variables to be bound
VariableNode "$R"
VariableNode "$var1"

(SequentialAndLink
(ExecutionLink ChooseInferenceRule "$var" "$R")
(ExecutionLink ChooseInferenceArgument ("$var", "$R") "$var1" )
(ExecutionLink "$R" ("$var" "$var1") )
)
)
)
)
)

***


In this version the work of ForwardInferenceStep is done by the snippet

(SequentialAndLink
(ExecutionLink ChooseInferenceRule "$var" "$R")
(ExecutionLink ChooseInferenceArgument ("$var", "$R") "$var1" )
(ExecutionLink "$R" ("$var" "$var1") )
)

which works as follows...

I write

ExecutionLInk S X Y

to indicate that SchemaNode S takes input X and produces output Y

Then,

(ExecutionLink ChooseInferenceRule "$var" "$R")

causes the GroundedSchemaNode ChooseInferenceRule to act on the Atom
$var chosen within the first part of the implication "Implication P Q"
fed to the pattern matcher, and chooses a PLN inference rule $R

The PLN inference rule (e.g. DeductionRule) is itself a
GroundedSchemaNode, chosen to instantiate the variable $R (quantified
by the BindLink above)

Then,

(ExecutionLink ChooseInferenceArgument ("$var", "$R") "$var1" )

causes the GroundedSchemaNode ChooseInferenceArgument to act on the
input ($var, $R) = (Atom, PLN inference rule), producing an output
consisting of another Atom, which is put into $var1 .... The other
Atom is chosen to match the constraints imposed by $R.
ChooseInferenceArgument may well want to invoke the pattern matcher
internally to do its business, but we can set that aside for the
moment...

Then,

(ExecutionLink "$R" ("$var" "$var1") )

applies the inference rule bound to $R, to the two argument Atoms
bound to $var and $var1 .... The GroundedSchemaNode embodying the
inference rule puts its ouput into the AtomSpace...

...

This approach breaks down the ForwardInferenceAgent into a series of
GroundedSchemaNodes, which is kind of nice, but doesn't actually
produce a different result from if the same series of steps were
packed into a single ForwardInferenceStep GroundedSchemaNode...

And of course, this doesn;t resolve the problem of how the initial
Atom $var is chosen in the first place (i.e. how to get it to be
chosen randomly from the AttentionalFocus, given the assumption that
it's being chosen by the pattern matcher)...

-- Ben

[Ben Goertzel]

Linas etc.,

In this e-mail I will explore the possibility of implementing a simple
PLN ForwardInferenceStep using Linas's pattern matcher,

The ForwardInferenceStep, as I have defined it, involves

****
1-- grabbing an Atom A from the AttentionalFocus

2-- choosing a PLN Rule R to use (perhaps using weights derived via
experience, etc.)

3-- if the Rule R is unary (like inversion), applying it to A, and
putting the result into the Atomspace

4-- if the Rule R is binary (like deduction) finding another Atom B
that is suitable, and applying R to A and B to get a result... and
putting the result in the Atomspace

****

One approach here would be to create a GroundedSchemaNode of the form

-- GroundedSchemaNode ForwardInferenceStep(Atom A)

which wraps up steps 2-4 ...

... and then use the pattern matcher to do something like

P ==> Q

where

P = Atom $A is in the AttentionalFocus

Q = Execute ForwardInferenceStep( $A)

In Scheme this might look like

****
(define pln-forward-step
(BindLink
;; The variable to be bound
(VariableNode "$var")
(ImplicationLink
;; The pattern to be searched for
(EvaluationLink
(GroundedPredicateNode inAttentionalFocus)
(Atom $var)
)

;; The value to be returned.
(ExecutionLink ForwardInferenceStep "$var")
)
)
)

;; Run the above pattern
(cog-bind pln-forward-step)

****

Here I am defining inAttentionalFocus as a GroundedPredicateNode, that
returns True if its argument is in the AttentionalFocus...

However, I am wondering if the above pln-forward step would give the
desired behavior...

What I would like is: for a single PLN forward step to choose a
*random* Atom from
within the AttentionalFocus (where the AttentionalFocus is defined as
those Atoms for
which the STI is greater than the AttentionalFocusBoundary.... I am
not sure if the
pattern matcher is controllable in this way (i.e. so that it can be
instructed to choose
a single instantiation of $var randomly) ...

Also, I would like to explore options like: having a single PLN
forward step choose
an Atom from within the AttentionalFocus, with the probability of chosing Atom A
being proportional to the STI of Atom A.... I would suppose that the
pattern matcher
is not currently controllable in this way

So it seems to me that, in order to use the pattern matcher to implement a PLN
forward inference step in the above manner, it would be necessary to
significantly
customize or modify the pattern matcher.

What you suggested is

> One way is to create a GroundedSchemaNode that examines the STI. If STI is too small, do nothing.

But that doesn't seem to implement the desired behavior.... In this
case, as I understand it,
the pattern matcher will find an Atom (by whatever means it's
programmed to) and then it will be thrown
out if it's not in the AttentionalFocus.... But this is not
necessarily going to give a random sampling
of the Atoms in the AttentionalFocus; it's going to give a biased
sampling, where the bias is determined
by the particular algorithm inside the pattern matcher...

I like the idea of getting OpenCog AI processing done via small chunks
of intelligent processing packed
into GroundedSchemaNodes.... However, I need to be able to control
the way this processing is done,
e.g. to control the way Atoms are selected for a given process...

thx
Ben


--
Ben Goertzel, PhD
http://goertzel.org

"My humanity is a constant self-overcoming" -- Friedrich Nietzsche


--
Ben Goertzel, PhD
http://goertzel.org

"My humanity is a constant self-overcoming" -- Friedrich Nietzsche

[Linas Vepstas]

Per other email in this thread, I don't think the below is appropriate for BindLink; that's not what its designed to do. Also, what's described below seems like a really complicated way of doing something that is relatively simple.   I think it would be easier to just write some custom C++ (or python or scheme..) code to handle this, instead of trying to converting it all into hypergraphs (and then descending into C++ anyway to handle the GroundedWhatever's)

-- Linas

[Ben Goertzel]

On Tue, Apr 30, 2013 at 12:04 AM, Linas Vepstas <linasv...@gmail.com> wrote:
> Per other email in this thread, I don't think the below is appropriate for
> BindLink; that's not what its designed to do. Also, what's described below
> seems like a really complicated way of doing something that is relatively
> simple. I think it would be easier to just write some custom C++ (or
> python or scheme..) code to handle this, instead of trying to converting it
> all into hypergraphs (and then descending into C++ anyway to handle the
> GroundedWhatever's)

Well, we'll see...

My original plan for the new PLN design was to put the individual PLN
inference rules inside GroundedSchemaNodes, but put the
ForwardInferenceStep and BackwardInferenceStep inside custom python
code...

And then the BackwardInferenceStep will invoke the pattern matcher
when it needs to do pattern matching...

After all this discussion, I still think that is probably the best
plan. However, this conversation has still been worthwhile, as I have
learned a lot about the pattern matcher ;-)

-- Ben