OpenNARS - Development Progress - 2nd phase

The port of NARS is now getting in the more complex/interesting part ie. porting inference rules and make the whole thing work.

It hasn't been possible to focus on simple inference as there's not a clear distinction in the rules implementation. So I did choose to port the maximum I could understood. Most of the stable classes that are not evolving much are ported. Some are tested, some are not as I need other parts to make them work.

We had also a discussion with Klaus to agree on the objectives and ways to tackle some problems. I also had to read again documentation on the NARS approach as it's still difficult to me to explain to others. Also, java code is not always explaining by itself :).

I've extended an overview document with picture to explain relation between statement (logic expression), sentence, reasoningItems (tasks that encapsulates sentences, judgment, question goal...) and reasoning artefacts (memory...bags...). See here.

Where I'm right now is thinking about the implementation choice of Inference rules.
Indeed, Pei choose to implement inference rules, as some utility functions and the memory as static methods only in several distinct classes. I understand his choice as it's easier for him to find and modify them (java world), but this is another difficulty for me to understand the system. It's therefore kind of mixed because several methods should belong to others objects and so, hard to port as I ask myself whose object responsibility it is... I've started that for all Utility functions (that are really stable). All three classes don't exist anymore and are either extension method.

Also dispatching them in Smalltalk is less problematic as I can use Pragma or even flags to access them quickly... Besides the static'ness of these methods, I find they are too long... which makes them hard to have a global view. Over the 4 inferences classes (+ a kind of rule dispatcher - RulesTable), there around 10 reasonning method per class which is not much but they are quite long... So fisrt, I'll port skeletton, bypass the parts in relation to complex inference (temporal, structural...) and I'll try to see common parts so as to create convenience methods etc...

That's why I'm spending this week getting a better understanding of the system to propose an alternative design. I think for instance that the memory class is the reasoning controller. It has links to several bags (Nars bags), that are the real storage of the working memory (names can be very confusing sometimes). I find I need some more abstraction and one of them is a reasoning controller which will hold the reasoning process (an inference engine?). I'm also discussing that point with Pei on the Nars mailing list.

The other missing parts is the full implementation of NARS language (NARSESE) that allows to express logics expression (input belief, outputs). I'll focus on implementing first simple statements like "swan is black" "yoyo is a swan" etc... The inference engine would be already usable for more complex expression. Still the future seaside interface will only focus on simple statements, presenting inference and result(s).

To deal with language terms, I may use a visitor pattern, or at least a better dispatch but I'll focus on that later.

So, next objectives are:
-port CompoundTerms, Statements and relations subclasses (inheritance, equivalence, implication, instance...) to be able to express tasks - statement which is a logic statement with a truth value plus some meta information that allow to deal with priority, decay, life of the belief in the working memory ...
-then make NAMemory work, maybe split it into 2 classes. I need to implement inference rules (some not all)

See you all... Feel free to leave comments, give pointers on pattern or application that use rule and inference (SOUL ? NeOPUS ?)...

Cédrick