Squeak Port - 2nd round - Inference and language packages

[cdrick]

Hello,

I open this thread to discuss the next step of the port I'm starting.
So far, I 've ported the simplest core parts.

Entity package, Memory and NABag(s), symbols and parameters
-quite equivalent to the java version

For the Inference package, I've only ported so far Utilities, Truth
and Budget functions. I've started with similar class but finally, I
ended up distributing methods to relevant object.
-Utilities are dispatched with extension method in core squeak classes
like Array and Number.
-TruthFunctions are inplemented in TruthValue.
-Budget functions are dispatched in several classes (not always happy
of the choice I did). I wonder if some methods shouldn't be delegated
to a Reasoner class.

Now I need to adress the core inference rules class as the language
package (I only ported Term)

>> -Variable.java
>> -CompoundTerm.java and Sentence.java (probably not complete) and all
>> subclasses (empty, just stubs (interface + comments))
>
>Variable and CompoundTerm are two of the most complicated classes,
>conceptually speaking. You should make sure you understand the current
>design before trying to port them.

I've looked at them and I'll probably wait a bit before porting them.
I have two remarks though:
- Implementing a visitor is probably the way to go.
- I wonder if it would be a good idea to create 4 subclasses of
Variable for each type {INDEPENDENT, DEPENDENT, ANONYMOUS, QUERY}

I'm also thinking about the creation of a reasoner class as discussed
in another post.

>> Then some inference classes which seems the first to be implemented...
>
>You may want to start at MatchingRules.java and SyllogisticRules.java,
>bypassing RuleTables.java. CompositionalRules.java can wait to a later
>stage, and the most messy one is StructuralRules.java.

So I had a look at MatchingRules, SyllogisticRules and RulesTable.
The first two use only static methods. What do you think if
dispatching in entity classes ? One disadvantage is that we loose the
separation that probably is handy to changes rules. It's also the same
for RuleTable. Is it a rule dispatcher ?

How do you see a reasoner class ? will it replace or integrate actual
rule tables ? Do you have any ideas or objections ?

Thanks,

Cédrick

[Pei Wang]

On Mon, Jul 14, 2008 at 9:35 AM, cdrick <cdri...@gmail.com> wrote:

> For the Inference package, I've only ported so far Utilities, Truth
> and Budget functions. I've started with similar class but finally, I
> ended up distributing methods to relevant object.

The current file/class design is chosen, to a large extent, to make
conceptual design easy, rather than to make the implementation clean
or efficient. For example, certain function is only used in one class,
so it is more natural to define it there. In the current code, I put
all functions together, so it will be easier to compare them and to
get the whole picture for this aspect of the system. Since you have
different considerations, it is fine to move things around to make the
system structure more natural to you.

> Now I need to adress the core inference rules class as the language
> package (I only ported Term)
>
>>> -Variable.java
>>> -CompoundTerm.java and Sentence.java (probably not complete) and all
>>> subclasses (empty, just stubs (interface + comments))
>>
>>Variable and CompoundTerm are two of the most complicated classes,
>>conceptually speaking. You should make sure you understand the current
>>design before trying to port them.
>
> I've looked at them and I'll probably wait a bit before porting them.
> I have two remarks though:
> - Implementing a visitor is probably the way to go.

Not sure what you mean by a "visitor".

> - I wonder if it would be a good idea to create 4 subclasses of
> Variable for each type {INDEPENDENT, DEPENDENT, ANONYMOUS, QUERY}

That is what I did in a previous version, though I end up changed it.

Anyway, variable is a messy issue, and I'm not happy with the current
design, so feel free to try different ways. However, given your time
constraint, you may want to leave it to the end of the project, if
there is still time left.

> So I had a look at MatchingRules, SyllogisticRules and RulesTable.
> The first two use only static methods. What do you think if
> dispatching in entity classes ?

Again, that is what I did previously. I switch to the current design,
because I want to see all the rules listed together, as mentioned
above. It seems necessary for conceptual design, though not really a
good implementation. In the future, I'd prefer to handle the grammar
rules and inference rules in a more "declarative" manner, even at the
cost of lower efficiency. Of course, when they are finalized, then the
consideration may be very different, but the system is not there yet
--- I think it will take several more years.

> One disadvantage is that we loose the
> separation that probably is handy to changes rules. It's also the same
> for RuleTable. Is it a rule dispatcher ?

You are right.

> How do you see a reasoner class ? will it replace or integrate actual
> rule tables ? Do you have any ideas or objections ?

I think a "reasoner" class, as Joe used, is the top-level API/manager
of the system, so it should take over some functionalities currently
in NARS.java and Center.java, as well as some others. If you put the
rule table into it, then it will be a "reasoner" of a different sense,
as an inference engine without memory. Both make sense, but should not
be confused with each other.

Pei

[cdrick]

Hi Pei,

Late answer, but I needed to try to put things together (and read).
Whereas I thing I understand relations between different entities,
this is not always easy to figure out all the whole thing work... So I
had another look at chapter 3 of your book, and quickly 4 and 5 and
again the one on the control processing. I've started a document, a
kind of memo based on your overview, plus I added some comprehension
picture.

You'll find it here: http://www.squeakside.com/seaside/pier/OpenNARS/Big+Pictures+NARS
(especially the pics)
feel free to add comment.

Next step for the port is having Statement, and the main relations
Inheritance, implications and so on. I will of course need to port
CompoundTerm but this will be done by commenting all parts that are
relevant more compound used in higher inference rules.

Now with me fresher vision of the system :), I still need some
explanations on how rules are coded.
For instance let's take dedExe(...) the first method of the class
SyllogisticRules.

It's not clear to me how the comment is related to the method (this is
probably due to my non-logic background :) ). So I'll proceed step by
step to find how
{<S ==> M>, <M ==> P>} |- {<S ==> P>, <P ==> S>} is linked to
dedExe(Term term1, Term term2, Sentence sentence, Judgment belief)

premisses: {<S ==> M>, <M ==> P>}
conclusion: {<S ==> P>, <P ==> S>}

Both premisses are statements, and surely sentence (statem+ truth
+stamp). I guess they are taken out from two tasks (only?).

Then conclusion is infered by the given rules. Having picked a
concept, then a task on this concept... how the reasonner apply the
dedEx rule... what's created... In other word I need a little help
here or pointers in the book if you have because I think it's not
clear to me the relations between different tasks ...


/**
* {<S ==> M>, <M ==> P>} |- {<S ==> P>, <P ==> S>}
@param term1 Subject of the first new task
IS IT S ?
@param term2 Predicate of the first new task
IS IT M or P?
@param taskSentence The first premise
IS IT something like: <S ==> M> %0.9 ; 0.54% ?
@param belief The second
premise IS IT <M ==> P>, if yes
why call it belief instead of just sentence ?
*/
static void dedExe(Term term1, Term term2, Sentence sentence,
Judgment belief)
-> side effect, create two new tasks ? that are register in Memory...


One difficulty I have is to see clearly the difference between a
belief, a task, a judgment and I'm particularly often confused when
you employ the term belief... I also can't understand why you need
term1 and term2, to me taskSentence and belief should be enough. Is it
to have the conclusion ?

My understanding so far is belief = Judgment (majority of sentences).

Concept is like a container of all tasks in relation with a given
term, beliefs related to a certain term. But then I don't understand
why the have an associated budget value... TermLinks and TaskLinks are
not clear either actually for the same reason (why do they have budget
values ...).
So naive question, is it possible to have only budget value on tasks ?

> On Mon, Jul 14, 2008 at 9:35 AM, cdrick <cdric...@gmail.com> wrote:
> > For the Inference package, I've only ported so far Utilities, Truth
> > and Budget functions. I've started with similar class but finally, I
> > ended up distributing methods to relevant object.
>
> The current file/class design is chosen, to a large extent, to make
> conceptual design easy, rather than to make the implementation clean
> or efficient. For example, certain function is only used in one class,
> so it is more natural to define it there. In the current code, I put
> all functions together, so it will be easier to compare them and to
> get the whole picture for this aspect of the system. Since you have
> different considerations, it is fine to move things around to make the
> system structure more natural to you.

ok. I think this was particularly true for TruthFunctions.

>
> >>> -Variable.java
> >>> -CompoundTerm.java and Sentence.java (probably not complete) and all
> >>> subclasses (empty, just stubs (interface + comments))
>
> >>Variable and CompoundTerm are two of the most complicated classes,
> >>conceptually speaking. You should make sure you understand the current
> >>design before trying to port them.
>
> > I've looked at them and I'll probably wait a bit before porting them.
> > I have two remarks though:
> > - Implementing a visitor is probably the way to go.
>
> Not sure what you mean by a "visitor".

http://en.wikipedia.org/wiki/Visitor_pattern

Visitor allow to implement treatment independly of the structure. It's
often coupled with a tree structure, and a composite one (like for
compound).

One important thing I guess is at least to implement a better dispatch
mechanism to avoid succession of tests. It will also help extend/
modify... I tend to avoid all isInstanceOf: orIsKindOf:

>
> > - I wonder if it would be a good idea to create 4 subclasses of
> > Variable for each type {INDEPENDENT, DEPENDENT, ANONYMOUS, QUERY}
>
> That is what I did in a previous version, though I end up changed it.

ok. I think I'll create them, especially to ease dispatching but this
will come later...

>
> Anyway, variable is a messy issue, and I'm not happy with the current
> design, so feel free to try different ways. However, given your time
> constraint, you may want to leave it to the end of the project, if
> there is still time left.
>

I think, I'm gonna leave variables for now :)
Maybe if you have any thought concerning the direction variable
implementation should take, I'll be interested to know.

> > So I had a look at MatchingRules, SyllogisticRules and RulesTable.
> > The first two use only static methods. What do you think if
> > dispatching in entity classes ?
>
> Again, that is what I did previously. I switch to the current design,
> because I want to see all the rules listed together, as mentioned
> above. It seems necessary for conceptual design, though not really a
> good implementation. In the future, I'd prefer to handle the grammar
> rules and inference rules in a more "declarative" manner, even at the
> cost of lower efficiency.

I find something that could help would be to have a rule abstraction
that takes 1 or 2 premises as parameters and return the conclusion.

>Of course, when they are finalized, then the
> consideration may be very different, but the system is not there yet
> --- I think it will take several more years.

:)

>
> > One disadvantage is that we loose the
> > separation that probably is handy to changes rules. It's also the same
> > for RuleTable. Is it a rule dispatcher ?
>
> You are right.
>
> > How do you see a reasoner class ? will it replace or integrate actual
> > rule tables ? Do you have any ideas or objections ?
>
> I think a "reasoner" class, as Joe used, is the top-level API/manager
> of the system, so it should take over some functionalities currently
> in NARS.java and Center.java, as well as some others. If you put the
> rule table into it, then it will be a "reasoner" of a different sense,
> as an inference engine without memory. Both make sense, but should not
> be confused with each other.

Ok, I understand better.

What I'd like is an abstraction for rules and a mechanism to fire
rules.
I may stick close to your implementation for now though. But I will
think and discuss to see if it's easily possible to use non static
method most of the time. If someone has a right abstraction idea ;)

Some thoughts on that:
I've looked a bit a Jena, but it seems to be a different objective.
Plugging different kind of reasoner.
In NARS, I find there is a full set of possible inference rules that
are competing. This competition act upons budget values and there's a
kind of reasonning controller that manage the selection of tasks,
questions answering etc... by adjusting budget values of each item
(that encapsulaters, term logic and relative importance).

Memory seems to play that role (controller) and contains also all the
different bags that is to me the state of the working memory.
I wonder if it would be useful to use a proper reasoningcontroller
(separate actual Memory classes in two classes ?)

I hope this is not too... fuzzy.

See you later,

Cédrick


>
> Pei

[Pei Wang]

On Fri, Jul 18, 2008 at 8:49 PM, cdrick <cdri...@gmail.com> wrote:
>
> Hi Pei,
>
> Late answer, but I needed to try to put things together (and read).
> Whereas I thing I understand relations between different entities,
> this is not always easy to figure out all the whole thing work... So I
> had another look at chapter 3 of your book, and quickly 4 and 5 and
> again the one on the control processing. I've started a document, a
> kind of memo based on your overview, plus I added some comprehension
> picture.
>
> You'll find it here: http://www.squeakside.com/seaside/pier/OpenNARS/Big+Pictures+NARS
> (especially the pics)
> feel free to add comment.

Looks good. I'm sorry for the insufficient documentation of NARS,
which is partly caused by the lack of time, and partly by the
immaturity of the code. I'll do my best to improve the situation
gradually.

> Next step for the port is having Statement, and the main relations
> Inheritance, implications and so on. I will of course need to port
> CompoundTerm but this will be done by commenting all parts that are
> relevant more compound used in higher inference rules.

One possible shortcut is to skip CompoundTerm, and only implement Term
ans Statement. You can even merge the two into one. Most of the
complexity of CompoundTerm comes from the various types of internal
structures of compound term. Since you don't have the time, it is
better to start on the functions that is absolutely necessary ---
basic syllogistic rules.

> Now with me fresher vision of the system :), I still need some
> explanations on how rules are coded.
> For instance let's take dedExe(...) the first method of the class
> SyllogisticRules.
>
> It's not clear to me how the comment is related to the method (this is
> probably due to my non-logic background :) ). So I'll proceed step by
> step to find how
> {<S ==> M>, <M ==> P>} |- {<S ==> P>, <P ==> S>} is linked to
> dedExe(Term term1, Term term2, Sentence sentence, Judgment belief)

Fine. Just remember: each basic syllogistic rule takes two premises
(one on S-M, another on M-P), and derives one or more (up to 3, if you
only do basic syllogistic rules) conclusion between S and P. Then, for
each conclusion, there is a truth value function that corresponding to
an inference type (ded, abd, ind, exe, ana, com, res).

> premisses: {<S ==> M>, <M ==> P>}
> conclusion: {<S ==> P>, <P ==> S>}
>
> Both premisses are statements, and surely sentence (statem+ truth
> +stamp). I guess they are taken out from two tasks (only?).

One is a "task" (active knowledge) and the other is a "belief"
(passive knowledge) --- see section 6.1.1 of the book.

> Then conclusion is infered by the given rules. Having picked a
> concept, then a task on this concept... how the reasonner apply the
> dedEx rule... what's created... In other word I need a little help
> here or pointers in the book if you have because I think it's not
> clear to me the relations between different tasks ...

The work cycle of the system is specified in Section 6.3.1 of the book.

> /**
> * {<S ==> M>, <M ==> P>} |- {<S ==> P>, <P ==> S>}
> @param term1 Subject of the first new task
> IS IT S ?
> @param term2 Predicate of the first new task
> IS IT M or P?
> @param taskSentence The first premise
> IS IT something like: <S ==> M> %0.9 ; 0.54% ?
> @param belief The second
> premise IS IT <M ==> P>, if yes
> why call it belief instead of just sentence ?
> */
> static void dedExe(Term term1, Term term2, Sentence sentence,
> Judgment belief)
> -> side effect, create two new tasks ? that are register in Memory...

In the current code there is no class for "belief". A belief is just a
judgment (sentence with truth-value) stored to be used for various
purpose. On the other hand, a "task" is a sentence (judgment,
question, or goal) that the system is actively processing.

> One difficulty I have is to see clearly the difference between a
> belief, a task, a judgment and I'm particularly often confused when
> you employ the term belief... I also can't understand why you need
> term1 and term2, to me taskSentence and belief should be enough. Is it
> to have the conclusion ?

It is the urgly part of the current design. :-(

Though each (syllogistic) rule has exactly two premises, it often
takes four (or more) input, because of the different role they play.
Take your previous example,

{<S ==> M>, <M ==> P>} |- {<S ==> P>, <P ==> S>}

This rule can be used for several different task-belief combination:
*. <S ==> M> is new belief, and <M ==> P> is previous belief;
*. <S ==> M> is a question, and <M ==> P> is previous belief;
*. <S ==> M> is previous belief, and <M ==> P> is goal;
... ...

One solution is to provide a rule for each case, but what I decided is
to let them to share the same rule. Consequently, just to give the
rule <S ==> M> and <M ==> P> (with truth value) is not enough --- it
is also necessary to distinguish the task from the belief, which
cannot be decided from the content of the premises.

> My understanding so far is belief = Judgment (majority of sentences).

Yes, all beliefs are judgments, but judgments can also be the content
of tasks (see the book section I mentioned).

> Concept is like a container of all tasks in relation with a given
> term, beliefs related to a certain term.

Yes. In an imaged "knowledge network", concepts are the nodes.

> But then I don't understand
> why the have an associated budget value...

Read Section 6.1.2 of the book.

> TermLinks and TaskLinks are
> not clear either actually for the same reason (why do they have budget
> values ...).
> So naive question, is it possible to have only budget value on tasks ?

No. also see the above section. Roughly speaking, whereever
traditional AI systems make a choice (among paths, rules, ...), NARS
makes a resource allocation, so that all possibilities are processed
in parallel, but at very different speeds.

>> The current file/class design is chosen, to a large extent, to make
>> conceptual design easy, rather than to make the implementation clean
>> or efficient. For example, certain function is only used in one class,
>> so it is more natural to define it there. In the current code, I put
>> all functions together, so it will be easier to compare them and to
>> get the whole picture for this aspect of the system. Since you have
>> different considerations, it is fine to move things around to make the
>> system structure more natural to you.
>
> ok. I think this was particularly true for TruthFunctions.

It can be.

>> >>> -Variable.java
>> >>> -CompoundTerm.java and Sentence.java (probably not complete) and all
>> >>> subclasses (empty, just stubs (interface + comments))
>>
>> >>Variable and CompoundTerm are two of the most complicated classes,
>> >>conceptually speaking. You should make sure you understand the current
>> >>design before trying to port them.
>>
>> > I've looked at them and I'll probably wait a bit before porting them.
>> > I have two remarks though:
>> > - Implementing a visitor is probably the way to go.
>>
>> Not sure what you mean by a "visitor".
>
> http://en.wikipedia.org/wiki/Visitor_pattern
>
> Visitor allow to implement treatment independly of the structure. It's
> often coupled with a tree structure, and a composite one (like for
> compound).

Yes, it makes sense.

> One important thing I guess is at least to implement a better dispatch
> mechanism to avoid succession of tests. It will also help extend/
> modify... I tend to avoid all isInstanceOf: orIsKindOf:

Agree. The current dispatch mechanism is too messy.

>> Anyway, variable is a messy issue, and I'm not happy with the current
>> design, so feel free to try different ways. However, given your time
>> constraint, you may want to leave it to the end of the project, if
>> there is still time left.
>
> I think, I'm gonna leave variables for now :)

Good idea!

> Maybe if you have any thought concerning the direction variable
> implementation should take, I'll be interested to know.

One possibility is to simply call a module coded in a Prolog-like language.

> I find something that could help would be to have a rule abstraction
> that takes 1 or 2 premises as parameters and return the conclusion.

But if these cases need to be processed in very different ways, what
will that abstraction provide?

> What I'd like is an abstraction for rules and a mechanism to fire
> rules.

Then it will be like the current "RuleTables.reason" method, right?

> I may stick close to your implementation for now though. But I will
> think and discuss to see if it's easily possible to use non static
> method most of the time. If someone has a right abstraction idea ;)

I'm sure there are better solutions, if enough time is spent on it.
The problem is we all have insufficient time. ;-)

> Some thoughts on that:
> I've looked a bit a Jena, but it seems to be a different objective.
> Plugging different kind of reasoner.
> In NARS, I find there is a full set of possible inference rules that
> are competing. This competition act upons budget values and there's a
> kind of reasonning controller that manage the selection of tasks,
> questions answering etc... by adjusting budget values of each item
> (that encapsulaters, term logic and relative importance).
>
> Memory seems to play that role (controller) and contains also all the
> different bags that is to me the state of the working memory.
> I wonder if it would be useful to use a proper reasoningcontroller
> (separate actual Memory classes in two classes ?)
>
> I hope this is not too... fuzzy.

Interesting. I'd need to hear and think more to make meaningful comments here.

Pei