OpenNARS - End of July Status

I've spent the last 2 weeks giving more love to the wiki and polishing what was ported since the start of the project. It was done in conjunction with design and comprehension decisions.

Until now, the main entities are ported as the primitives inference functions that acts on 2 special NARS arithmetic entities (TruthValue and BudgetValue).

What's missing are the inference rules as the glue with the existing entities in particular Memory who is the central class that implements the reasoning process. It has also on its state all the storage entities (NARS Bag) and organize their contents interaction. NARS bags are not only usual collection. They have in this design the responsabilies of pickOut and putIn (driven by a probabilistic selection using BudgetValue).

So here is a summary ot what was done recently:

Wiki

reorganization around the following sections :

Code Section For all code aspect of the port

• Code Browser
  • ajax based - scriptaculous version extended
    • read-only
  • Squeak and Java Doc
    • gives package and class comment
    • shortcut to the last java version, and to the squeak one
  • Java structure and design discussion

NARS Section

• Introduction to the system
  • Architecture description
  • Overview pictures
  • External Links

Blog

A blog to ask questions, relates actuality of the port...

Timeline

Section in relation to the timeline and objectives of the GSoC Prject

Functional test applications

I haven't made a lot of unit tests yet mainly because my understanding of the system was not really clear (until now?). Instead I did two functional test applications (seaside). They allow testing most of the inference primitives methods on TruthValue and BudgetValue. I plan to continue this kind of functional test with the inference rules and if possible providing a seaside application that will do an inference cycle step by step (kind of WATask).

What's next ?

I also had a reflection on how to implement the rule dispatcher and the rule body. Given our objective (mainly syllogistic rules as we deal only with atomic terms), there are not too many classes and methods but they are quite long. The discussion we had with Klaus was whether to dispatch or not :).

The conclusion is to stick to the actual implementation for several reasons:

• Pei wants the code in one place as the NARS is not stabilized yet (AGI research project)
• Refactoring is quite uncertain now.
• Writing rules with Smalltalk ifTrue:'s isSometing's and:[]'s, the code will be quite shorter and so a bit more readable. For instane, see there (the java version is commented below).
  
• we keep our ideas for later. Dispatching would surely making look a bit nicer but it could be worthless if there is a major move (like using prolog - having rule in a declarative language).

So next steps are, finishing and fixing language statement class and subclasses. Then I'll have to port 3 inference classes. I think 3 weeks is reasonable to have the system starting to work as a whole (still far form doing all kind of inference and logic expression). At this time, we'll have to test, optimize the reasoning process and in the same time I'll do seaside interfaces. I also would like to do a screencast with the Java version to show how NARS behave and can be used. I plan to do this tutorial.

That's it for now.

Happy squeaking ;-)

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

OpenNARS port to Squeak using Seaside

Hi, I'm Cédrick Béler, a french PhD student and I've been selected for GSoC of squeak. The selected application consists in porting OpenNARS (Non-Axiomatic Reasoning Systems) to Squeak using Seaside for the GUI. My Mentors are Klaus D.Witzel and Pei Wang (creator/developer of NARS).

NARS is before all a reasoning system but a non-axiomatic one compared to usual semi-axiomatic ones we find in AI [1]. It attempts to uniformly explain and reproduce many cognitive facilities, including reasoning, learning, planning, etc, so as to provide a unified theory, model, and system for AI as a whole. The ultimate goal of NARS research is to build a thinking machine. What makes this system different from conventional reasoning systems is its ability to learn from its experience and to work with insufficient knowledge and resources. NARS theory exists. A book has been published recently (Rigid flexibility).

Since 2008, NARS is developed as open source software . A prototype exists in java for the core of the system but there is still a lot to do until the aim of having a thinking machine is reached. A port is underway in Python and we propose to start a squeak port because we think a dynamic and flexible environment and language as Smalltalk/Squeak could be very appropriate here.

Right now, I'm finishing writing my PhD dissertation so I will only spend moderate time on the project in June (delivery date is by the end of June). Once done, I'll be nearly full-time on the project. When coding, I'll be as much as possible on IRC (#squeak) on freenode under the nickname Cdrick. Feel free to contact me if you have any question in relation to this project. I will start the port with the stable core of the prototype (see here for more information)

Cédrick Béler (cdrick65 for my google account...)

[1] NARS (Non-Axiomatic Reasoning System) is a concrete example of non-axiomatic system. Here is a short definition of axiomatic, semi-axiomatic and non-axiomatic (quoted from Pei Wang publications)

1. pure-axiomatic system: In all aspects, the system has sufficient knowledge and resources with respect to the problems to be solved.
• Pure-axiomatic systems are studied in mathematics, and is not directly related to AI
2. semi-axiomatic system: In some, but not all, aspects, the system has sufficient knowledge and resources with respect to the problems to be solved.
• Most of the previous AI work in the inference framework belong to the category of semi-axiomatic system, which attempt to make partial extension or revision of mathematical logic, while keep the other parts.
3. non-axiomatic system: In all aspects, the system has insufficient knowledge and resources with respect to the problems to be solved.
• For AI, what is really needed are non-axiomatic systems, which do not assume the sufficiency of knowledge and resources in any aspect of the system.
  

Basically in NARS, solving the same problem several times has not to give the same solution... If you're intrigued by this theory, don't hesitate having a look at the available documentation :)