opencog-dev team mailing list archive

["Joel Pitt" <joel.pitt@xxxxxxxxx>]

Thanks Ari.

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.

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)

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?

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
>