Reason behind choosing c for implementation and limitations of OpenNARS

[ShirelJosef]

hello, I am new to AGI and hope we will finally create the next skynet. I truly want to understand this system and its capabilities. Basically, my questions are:

1. Why choosing c and not more "user friendly" language like python? I believe the goal is to attract researchers and python would be a more suitable way to achieve that.
2. I am currently watching the tutorials, but I want to understand what are the limitations of NARS? for example if modeled correctly, can it beat montezuma revenge? can it beat chess?

Thank you for your answers

[PtrMan]

2. A (NARS) system should be able to solve montezuma revenge and chess, maybe ONA can already solve a simple chess environment (say 3 pieces or so). "Problem" here is that chess is a "traditional" AI problem with full observability and without uncertainty, so it doesn't fit problems in which only NARS excels.

[PtrMan]

1. I developed serveral implementations in high level languages such as Python and Haxe, Part of the community didn't "like" it, so that's that. I can't and don't want to control what Patrick is doing :D . Tony has developed serveral NARS implementations in a high level language F# too, F# never catched up.

[PtrMan]

Reasons against using Python is it's fully dynamic type system for everything, this makes it hard to build complicated software. Another is the GIL.

[ShirelJosef]

1. is a "traditional" AI problem with full observability and without uncertainty, so it doesn't fit problems in which only NARS excels.

First of all, thank you for your replies, I appreciate it. Second, I do have a complex and stochastic problem I wish to solve. Should I try to use NARS or use ONA? What is the current difference between them (that cause the different outcomes in chess)? is it because of: "The focus on the design has been to implement the 'existing' theory [6, 7] as effectively as possible and make firm decisions rather than keep as many options open as possible. This has led to some small conceptual differences to OpenNARS [8] which was developed for research purposes."

[PtrMan]

"OpenNARS for research" (basically the old java OpenNARS codebase) can't handle complicated planning problems, it even struggles with simple ones. ONA should be a better fit.

"OpenNARS for research" implements all logic rules but it can't apply them for complicated problems. ONA implements less rules but it can apply the rules "better" to hopefully solve more complicated problems. That's the main difference when using these systems.

[patham9]

Hi!

"Why choosing c and not more "user friendly" language like python?' Why not Python: it wouldn't be a reasonable choice to implement NARS. Not because it's not possible to write it in Python, not because the code wouldn't be beautiful, but because the result would by far not be competitive with a properly done C, C++ or Rust implementation. It would not even be competitive with a Java, Go or C# implementation. I think those 6 are all reasonable choices, assuming the programmer knows how to use them properly, which for the first three is more rarely the case, unfortunately, as the efficiency benefit isn't negligible.

User friendliness is a separate topic, there is a Python interface for ONA which makes it easy to use. Such an approach is actually the norm in the scientific Python stack, having fast native code and a Python wrapper on top, that's how both speed and "user friendliness" can be achieved without making any suboptimal compromises.

"Should I try to use NARS or use ONA? What is the current difference between them" NARS is the research project, ONA is an implementation thereof. I guess you mean differences between "OpenNARS" and the "OpenNARS for Applications". Both implementations follow the NARS theory, the differences are in memory & control design. ONA is event-driven and more focused at current stimuli to find solutions to current goals, while OpenNARS utilizes concept selection and is more "creative" in its reasoning. For detailed differences, feel free to read the OpenNARS and ONA paper.

Best regards, Patrick

Am Sa., 5. Dez. 2020 um 00:13 Uhr schrieb PtrMan notifications@github.com:

"OpenNARS for research" (basically the old java OpenNARS codebase) can't handle complicated planning problems, it even struggles with simple ones. ONA should be a better fit.

"OpenNARS for research" implements all logic rules but it can't apply them for complicated problems. ONA implements less rules but it can apply the rules "better" to hopefully solve more complicated problems. That's the main difference when using these systems.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opennars/OpenNARS-for-Applications/issues/106#issuecomment-739086265, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7GUBKXRQOERJXLZMST23LSTF3MFANCNFSM4UNWRNNA .

[PtrMan]

It would not even be competitive with a Java, Go or C# implementation.

Ever considered Cython? The GIL can be bypassed https://cython.readthedocs.io/en/latest/src/userguide/external_C_code.html#releasing-the-gil Should be comparable to C# because C# is way slower than Java.

that's how both speed and "user friendliness" can be achieved without making any suboptimal compromises.

I disagree, polyglot projects (commonly C++ and Python) are hard to debug, hard to maintain, etc. compared to projects where a single language does most of the work. Plus there are always boundaries and VM boundaries, which punish tight coupling between high level code and low level code.

It just currently necessary because the technology is still to primitive to what developers need for "real" AGI systems with tightly coupled components, incomprehensible control and dataflow, etc.