|
|
open-nars |
Hi Pei,
Late answer, but I needed to try to put things together (and read).
You'll find it here: http://www.squeakside.com/seaside/pier/OpenNARS/Big+Pictures+NARS
Next step for the port is having Statement, and the main relations
Now with me fresher vision of the system :), I still need some
It's not clear to me how the comment is related to the method (this is
premisses: {<S ==> M>, <M ==> P>}
Both premisses are statements, and surely sentence (statem+ truth
Then conclusion is infered by the given rules. Having picked a
/**
One difficulty I have is to see clearly the difference between a
My understanding so far is belief = Judgment (majority of sentences).
Concept is like a container of all tasks in relation with a given
> The current file/class design is chosen, to a large extent, to make
> >>> -Variable.java
> >>Variable and CompoundTerm are two of the most complicated classes,
> > I've looked at them and I'll probably wait a bit before porting them.
> Not sure what you mean by a "visitor".
Visitor allow to implement treatment independly of the structure. It's
One important thing I guess is at least to implement a better dispatch
> > - I wonder if it would be a good idea to create 4 subclasses of
> 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
> Again, that is what I did previously. I switch to the current design,
> > One disadvantage is that we loose the
> You are right.
> > How do you see a reasoner class ? will it replace or integrate actual
> I think a "reasoner" class, as Joe used, is the top-level API/manager
What I'd like is an abstraction for rules and a mechanism to fire
Some thoughts on that:
Memory seems to play that role (controller) and contains also all the
I hope this is not too... fuzzy.
See you later,
Cédrick
> Pei
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.
(especially the pics)
feel free to add comment.
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.
explanations on how rules are coded.
For instance let's take dedExe(...) the first method of the class
SyllogisticRules.
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)
conclusion: {<S ==> P>, <P ==> S>}
+stamp). I guess they are taken out from two tasks (only?).
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...
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 ?
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:
ok. I think this was particularly true for TruthFunctions.
> > 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.
> 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.
http://en.wikipedia.org/wiki/Visitor_pattern
> >>> -CompoundTerm.java and Sentence.java (probably not complete) and all
> >>> subclasses (empty, just stubs (interface + comments))
> >>conceptually speaking. You should make sure you understand the current
> >>design before trying to port them.
> > I have two remarks though:
> > - Implementing a visitor is probably the way to go.
often coupled with a tree structure, and a composite one (like for
compound).
mechanism to avoid succession of tests. It will also help extend/
modify... I tend to avoid all isInstanceOf: orIsKindOf:
ok. I think I'll create them, especially to ease dispatching but this
> > Variable for each type {INDEPENDENT, DEPENDENT, ANONYMOUS, QUERY}
will come later...
I think, I'm gonna leave variables for now :)
> 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.
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.
I find something that could help would be to have a rule abstraction
> > The first two use only static methods. What do you think if
> > dispatching in entity classes ?
> 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.
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.
Ok, I understand better.
> > separation that probably is handy to changes rules. It's also the same
> > for RuleTable. Is it a rule dispatcher ?
> > rule tables ? Do you have any ideas or objections ?
> 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.
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 ;)
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).
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 ?)