some more analysis of some fundamental concepts

[Apil Tamang]

This page begins with the following statements:

Using C++ for opencog is possible, but not generally recommended. This is because the whole point of OpenCog is to represent knowledge in terms of hypergraphs in the atomspace, and to manipulate and grow that knowledge using deduction, PLN, learning and various evolutionary algorithms. Of course, writing new evolutionary algorithms can mean writing in C++; and certainly fixing existing low-level, core code requires working with C++. However, newcomers to OpenCog are strongly encouraged to think in terms of hypergraphs, and representing their ideas in terms of hypergraphs, and in terms of the first-order logic that the PLN and pattern-matching engines can process.

Although most new code should really be "new hypergraphs", and new patterns (such as the SatisfactionLink and the BindLink), sometimes its just plain hard to avoid writing new algorithms. For this, scheme is recommended. In other cases, one might need to implement a new control process, aka a new "MindAgent" that controls inferencing, or possibly interfaces to external systems and sensors. For this, using python is recommended.

In the following tutorials, .....

My analysis:

Do the authors actually mean that most new code should really be those that "creates" a new knowledge-representation base using a hypergraph, or do they really mean "code that is a new hypergraph"? My perspective of a hypergraph is the equivalent of a database. It makes sense to write new code that adds content to that database (or hypergraph). But new code being the hypergraph (or database) itself... now that's something that could use clarity.

Also the text above states to use 'Scheme' to create hypergraph(s) and use 'Python' to write a mind-agent. How does this compare with an earlier post suggesting (and recommending) using the 'Scheme' shell to do most interactions with opencog. A scenario I can imagine where this applies is when opencog is used as a library inside python. Is that the case?

[Linas Vepstas]

On Sat, Oct 29, 2016 at 1:23 PM, Apil Tamang <apil.tama...@gmail.com> wrote:

This page begins with the following statements:

Using C++ for opencog is possible, but not generally recommended. This is because the whole point of OpenCog is to represent knowledge in terms of hypergraphs in the atomspace, and to manipulate and grow that knowledge using deduction, PLN, learning and various evolutionary algorithms. Of course, writing new evolutionary algorithms can mean writing in C++; and certainly fixing existing low-level, core code requires working with C++. However, newcomers to OpenCog are strongly encouraged to think in terms of hypergraphs, and representing their ideas in terms of hypergraphs, and in terms of the first-order logic that the PLN and pattern-matching engines can process.

Although most new code should really be "new hypergraphs", and new patterns (such as the SatisfactionLink and the BindLink), sometimes its just plain hard to avoid writing new algorithms. For this, scheme is recommended. In other cases, one might need to implement a new control process, aka a new "MindAgent" that controls inferencing, or possibly interfaces to external systems and sensors. For this, using python is recommended.

In the following tutorials, .....

My analysis:

Do the authors actually mean that most new code should really be those that "creates" a new knowledge-representation base using a hypergraph, or do they really mean "code that is a new hypergraph"? My perspective of a hypergraph is the equivalent of a database. It makes sense to write new code that adds content to that database (or hypergraph). But new code being the hypergraph (or database) itself... now that's something that could use clarity.

A hypergraph is more like a single record in a database.  A collection of hypergraphs make up the database.  The atomspace is that thing that holds the  hypergraphs.

I guess we need to be careful defining what a hypergraph is. If you include the incoming links, then yes, it could happen that all atoms are connected, and thus the atomsspace contains just a single hypergraph. 

Since hypergraphs encode logic, a single atom can correspond to a line of code in prolog, and you can program with atoms much like you can program with prolog -- that is, prolog is more than just a database.   

Also the text above states to use 'Scheme' to create hypergraph(s) and use 'Python' to write a mind-agent. How does this compare with an earlier post suggesting (and recommending) using the 'Scheme' shell to do most interactions with opencog. A scenario I can imagine where this applies is when opencog is used as a library inside python. Is that the case?

Python is the visual-basic of the 21st century, and attracts the same kind of people, and the same kind of mindset and abilities.   Basically, python is easy to use, and that makes it popular.  Should you use it? That depends.

The current scheme API is very nice for specifying atoms, but scheme code is not very readable, and most programmers don't know scheme. I don't recommend writing big complex projects in scheme. But then, I don't recommend writing big complex projects in python, either...  It depends on what you want to do, and how you want to structure things, and think about solving the problem. 

scheme is functional, and that makes it excellent for many tasks, questionable for others. python is imperative, and that makes it excellent for many tasks, questionable for others. 

They're just ... different.  (well, that, and python is single threaded, and has a terrible i/o subsystem, which is why python is currently broken in opencog).

--linas

 

--
You received this message because you are subscribed to the Google Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/421f7340-4b78-47ed-9dd5-5b1a4b3f05a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Apil Tamang]

Thanks for the explanation. That helps quite a bit, and also resonate with some other pieces of information I've gathered.