opencog-dev team mailing list archive

[Ari Heljakka <ari.heljakka@xxxxxxxxxxxxxx>]

Joel,

> The existing forward chainer was extremely simple, it used the
> Rule::validate on random argument lists. I've created a ForwardChainer
> class and a rule provider for it which should provide a better
> interface than the prototype fwd chainer (which was just a global
> function) and allow better control of forward chaining.
>
> My understanding was what you described with the backward chainer
> should also work with the forward chainer.

Depends on what exactly you refer to.

> Currently when I check to see if a rule argument is valid, I add each
> Handle directly before calling Rule::validate.
>
> See line 90 of:
>
> http://bazaar.launchpad.net/~opencog-dev/opencog/pln/annotate/1307?file_id=forwardchainer.cc-20081010072254-smr2139so8mly515-1
>
> That method randomly applies rules on a seed atom. The other rule
> arguments are (currently) randomly picked and validated until a valid
> combination is found (or it gives up). Is this a valid way of using
> the Rules to ensure L2,L1 is invalid? (If so, I'll just track down why
> it's saying they are valid at the moment)

Yeah, I believe so.

> You're BITNode screencast was extremely helpful to guide my
> understanding. Is there any chance of getting a screencast explaining
> a bit about the MPUnify* methods?

Well, perhaps I could give it a shot. They're a mess, though.

So what happened with the VersionHandle thing? Still in progress?

-A

> J
>
>
> On Sat, Oct 11, 2008 at 8:17 AM, Ari Heljakka
> <ari.heljakka@xxxxxxxxxxxxxx> wrote:
> > Hi Joel,
> >
> > since I am not the author of the forward chainer, I don't recall precisely
> > how it does the input validation, but it may well be that it simply uses the
> > type checking method for the input arguments as you say.
> >
> > For backward chainer, the argument selection mechanism is much more complex,
> > and includes variable binding system to ensure that <L2,L1> cannot happen.
> >
> > The deduction of <L2,L1> does _not_ give you B->B, however, though that is
> > inconsequential here. <L2,L1> is simply invalid unless C=A.
> >
> > Your question is a subquestion of the larger question of how to select
> > arguments for PLN forward chainer. The selection process must pay attention
> > to both the legitimacy and sensibility of the input arguments and the
> > general fitness for them to be selected for inference.
> >
> > Which piece of code have you been looking into in this regard?
> >
> > -A
> >
> > Joel Pitt wrote:
> > > Hi Ari,
> > >
> > > I'm trying to implement/modify the forward chainer in PLN.
> > >
> > > I'm wondering about specifically what argument validation does in the
> > > Rules. Initially I thought it would ensure both the structure and type
> > > of the arguments were correct, but it seems to only check type... at
> > > least for the DeductionRule.
> > >
> > > Say we have nodes:
> > > A B C
> > > and inheritance links:
> > > L1 = A->B
> > > L2 = B->C
> > >
> > > And we want to find L3 = A->C
> > >
> > > If we present the Rule with arguments in the order < L1, L2 > then
> > > deduction works as expected. But if we present with < L2, L1 > then it
> > > outputs L3 = B->B, which isn't all that useful and should probably not
> > > return true when validation of arguments is attempted.
> > >
> > > Now perhaps I broke something while changing things, but I wanted to
> > > check if the design ever checked that the arguments were connected in
> > > the right way (i.e. L1.getOutgoingAt(1) == L2.getOutgoingAt(0) ) or if
> > > that's meant to be left to the code constructing the argument list?
> > >
> > > Thanks!
> > > J
> > --
> > Ari Heljakka
> > CTO
> > Dream Broker Ltd
> >
> > Tekniikantie 14        ari.heljakka@xxxxxxxxxxxxxx
> > 02150 Espoo            +358 40 568 2420
> > Finland                www.dreambroker.fi


--
Ari Heljakka
CTO
Dream Broker Ltd		

Tekniikantie 14			ari.heljakka@xxxxxxxxxxxxxx
02150 Espoo			+358 40 568 2420
Finland				www.dreambroker.fi