OpenNARs for Applications vs Java OpenNARs

[Daniel Jue]

Hi, I've been digging into NARs since the AGI-20 talks, starting with Pei Wang's AGI-13 classroom videos on the topic.

Can someone tell me the difference in reasoning capabilities between the OpenNARs for Applications and the older Java OpenNARs?  Do they both support the same NAL level?  (is NAL-8 the current state of the art?)

I'm spending time going through the source code of both the C and Java versions, and thought it would be nice to know if one of the projects was a strict subset of the other, or if there are compromises made in the (simpler-looking) C++ version.    I'm not concerned with things like the GUI project of Java NARs, just any difference in core reasoning capabilities between the two.

Regards,

Daniel Jue

Cognami

[Alexander Douglas]

Hey Daniel, I'm also new to OpenNARS for Applications, but I actually just finished reading through the ONA developers recent paper and found it quite helpful in understanding the most relevant differences.  In case you don't have access to that paper, I can just include the most relevant bits.

"

The proposed architecture, OpenNARS for Applications (ONA), has been developed to resolve OpenNARS’s limitations by combining the best results from our research projects. The logic and conceptual ideas of OpenNARS, the sensorimotor capabilities of ANSNA and the control model from ALANN are combined in a general purpose reasoner ready to be applied. 

The decision to take a pragmatic approach to the architecture has proven to be a worthwhile investment. The change to an event driven control model has removed much of the complexity of the prior control system. The separation of semantic and sensorimotor inference has highlighted the key issues of both aspects whilst avoiding the complexity of a unified handling. The reduction in complexity has led to many benefits including: simplified parameter tuning, separation of concerns, and clear attentional focus boundaries. The use of the meta rule DSL to represent the logic rules allows the reasoner to be configured for specific domains. Enabling subsets of inference rules for specific use cases avoids the processing of unnecessary inference rules and the resulting increase in non-relevant results. From a software engineering perspective, the OpenNARS codebase was well overdue a rewrite as the continuous incremental change had led to it being difficult to maintain and modify. The choice of C, utilizing the POSIX API, means the reasoner can be compiled on a broad range of platforms including embedded, mobile and all major OSs. In summary, the new architecture and control has led to significant improvements in both efficiency and quality of results, especially in respect to procedure.  

In the toothbrush example knowledge about different objects, their properties and what they can be used for is provided. The goal is to unscrew a screw with a toothbrush by melting and reshaping it into a form usable to unscrew the screw. ONA finds the solution consistently, within 30 inference steps, while OpenNARS often needs 100K or more.  

Previously, a 24 h reliability test of OpenNARS v3.0.2 was carried out with the Pong test case. The system ran reliably for the 24 h period with a hit/miss ratio of 2.5 with a learning time of two minutes and some minor fluctuation in capability in the first 3 h. In comparison, OpenNARS for Applications v0.8.1 ran reliably for the 24 h period with a hit/miss ratio of 156.6 with a learning time of <10 s and no negative fluctuation. The test for ONA was more difficult with 3 operations (compared to left/right operations only for OpenNARS Pong, it didn’t include stop) and approximately 2x faster ball speed, demanding quicker reaction times.

"

Hopefully, that was helpful for you.  The sense I got from the paper is basically, if you want to make use of NARS in any sort of real world scenario,  ONA is very likely going to be the better option.  But yeah, I'm sure more knowledgeable individuals can chip in if you need more specific information, like I said, I'm new here myself :).  

[Patrick Hammer]

Hi everyone!

Some addition to what Alexander pointed out:

Logic-wise both support NAL 1-8, Java impl also supports some NAL 9 (self-control, though this was not effective so far), and NAL-5 is only present in ONA in a limited form (limited conjunction except for sequences, implication, negation) From a memory and control perspective they are quite different beasts, though both respect AIKR strictly, though for the Java version it's not clear what it's max. memory consumption actually is for a given configuration. In ONA it's even easy to configure the system to take only a max. predefined amount of RAM, ONA reserves it at startup (via static initialization) and it won't need any additional byte at runtime. The POSIX API is only used for the UDP interface, ONA can even run without any OS. (I tried a version with 10 concepts on an Atmega 128 a few months ago :) )

ONA's control mechanism is simpler and designed for reliable long-term operation, guaranteed not to get into "attentional traps" (remaining responsive).  It achieves this "attentional stability" via strong monotonic decay of priority plus derived event priority being bounded by the parent's.

Best regards,

Patrick

--
You received this message because you are subscribed to the Google Groups "open-nars" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-nars+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-nars/8e9c7b37-5159-43a2-8d3e-c0be95608951o%40googlegroups.com.