Thanks for the explanation. That helps quite a bit, and also resonate with some other pieces of information I've gathered.
On Saturday, October 29, 2016 at 2:23:55 PM UTC-4, Apil Tamang 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. > > > 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? > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/c8ba7df4-f90a-4f98-920d-8da1b2a869b2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
