Re: PLN Library
Joel Pitt
I've attempted to answer your questions in this mail. Though PLN is
complex I don't think it's necessary to rebuild PLN "piece by piece"
and feel that I've almost got it linking/compiling correctly. There
were minor classes/bits of code from within Novamente (that were
outside of the PLN directory) that were needed... hopefully this will
be fixed by the end of this week.
In the interests of having more community visibility, I've CCed this
reply to the OpenCog summer of code list and also to Ari the original
author of the PLN code.
> ************ Global comments
> 1) I keep wondering what is NM mapped to in opencog?
I've been using the static CogServer::getAtomSpace()
> 1.1) I thought that NM (novamente? novamente mind?) would represent
> an AtomSpace singleton in opencog terms. But then, this should be a
> global variable, something like extern AtomSpace * nm =
> CogServer.getAtomSpace(); in every file. Or maybe, extern is even not
> necessary, if you see the server implementation will notice that
> server() creates the Singleton and as long as it is in the same
> namespace, it can access CogServer.getAtomSpace anywhere and it is the
> same Space. But again, CogServer has more stuff than necessary ...
> what to do? What is the difference of AtomSpace and AtomTable?
Possibly PLN should have a way to have the AtomSpace set separately so
that it doesn't require the Server as well... but we can worry about
that once PLN is integrated.
The best way would probably be to let the AtomTableWrapper (which
should be renamed to AtomSpaceWrapper) work out how to get the
AtomSpace, or how to set it.
The AtomSpace is the interface, the AtomTable is the underlying
implementation that handles efficiently retrieving Atoms by
maintaining indexes.
> 1.2) What does this do: "#define getTypeFun
> std::bind1st(std::mem_fun(&NMCore::getType), nm)"
This binds the getType member function to an instance of the AtomSpace
so that it can be used and passed as a function pointer/reference (I
think...)
> 1.3) why vtree is not exposed in atomspace/utils2.h? the typedef is
> inside utils2.cc !!!
I know, there is some messed up stuff in utils.cc and utils2.cc - they
should really be unified... and some of the defined functions don't
actually have implementations. I've fixed them enough so that PLN will
compile, but it's something to put on the TODO list.
> ************ Atom Manipulation Section
> 2) The AtomTableWrapper is enormous. Couldn't we just use AtomTable
> implementation itself? And put some other functions in PLNUtils.cc,
> for example LoadAxioms could be implemented just like loadXML in
> CommandRequestProcessor.cc (server) and DumpXX, GetRandomHandle,
> Freshened so on.
I'd like to keep the AtomTableWrapper for now... it may be useful if
we try to make PLN a self contained library that can be used outside
of OpenCog.
> 2.1) In addition, AND2ORLink, Equi2ImpLink, Exist2ForAllLink could
> be in a separate file "EquivalenceAmongLinks.cc".
Ok... will keep that in mind for when I'm refactoring and tidying
things up. Still in the getting-it-to-work mode.
> 2.2) There are some differences between AtomTableWrapper and
> AtomTable, for example "getHandleSet" returns a SET in the PLN
> library, while in opencog the AtomTable seems to return a VECTOR. What
> to do? Create a little converter between these types?
Another reason to keep the AtomTableWrapper for now ;)
> 2.3) Do we need two interfaces? The iAtomTableWrapper.h exposes
> addAtom, addLink, addNode, while AtomLookupProvider.h exposes
> getHandleSet, getHandle. It seems because of the size of the
> AtomTableWrapper the interfaces expose only the parts necessary but
> using AtomTable itself this is not necessary and we can drop them.
I suspect this is historical, and to do with something called the
Pseudocore used by Novamente in the past. Basically Pseudocore was a
extremely light weight version of the AtomSpace (if my memory serves)
Unless people suggest otherwise, I think iAtomTableWrapper and
AtomLookupProvider should be merged together to keep things simple.
> 2.4) LocalATW, DirectATW, NormalizingATW, FIMATW all implement
> different addLink and addNode ... this seem very implementation
> specific of the Novamente and I couldn't make sense of their
> difference. So, my idea is again drop them all and rely on the opencog
> AtomTable itself.
The last two boolean parameters in the add methods can just be
dropped. They specified whether the atom was fresh (i.e. guaranteed to
not already exist in the AtomSpace) and whether it was managed...
unfortunately the fresh parameter is misused in PLN, so once PLN is
running I'll have to fix this "fresh" bug it...
To Novamente people: what does the "managed" parameter do? Looking in
the NM source code the doxygen comments don't cover the fresh and
managed parameters..
> 2.5) There are several functions in AtomTableWrapper.cc that are
> used by other parts of the code, for example, isSubType, child,
> make_vtree, inheritsType are used in Rules.h/.cc. In addition, there
> are some functions not used at all HandleEntry2HandleSeq,
> symmetricLink, is_empty_link, hasFalsum, containsNegation and
> singular. To make the code managable, move and delete these functions
> would be a good idea.
Yup, there are quite a few functions that we should really put in an
appropriate class, as well as a lot of left over and now unused code.
Again I'm tempted to leave them there for now though, since they are
not doing harm and in the process of reworking and improve PLN, some
of them might become of use again.
> ************ Backward Inference Section
> ************ BackInferenceTree.h/.cc and BackInferenceTreeNode.h/.cc
> 3) The classes BackInferenceTree and BITNode are nearly
> identical. If you do a DIFF between the .cc files, you will see
> various pieces of the same code in both places. So, they were copied
> in the past and added some extra functionality, but then I wondered
> which one is mainly used. Basically, PLNShell.cc uses BITNode from
> BackInferenceTreeNode and Tester.cc uses BackInferenceTree. It is like
> having two separate programs using nearly equal libraries in different
> contexts in the same directory. I think, both "BackInferenceTree.h/.cc
> and BackInferenceTreeNode.h/.cc" should be merged in one, or
> BackInferenceTree.h/.cc should be dropped, less files with repetitive
> work ... easier to understand and to work.
BackInferenceTree is an old version of BackInferenceTreeNode. I only
realised after checking the Makefile in the Novamente reasoning
directory (I'd erroneously assumed that all the files in the directory
would be used!)
Thus we can delete BackInferenceTree, and adapt Tester.cc to use the
BackInferenceTreeNode class.
> ************ PLN Formulas Section
> ************ Formulas.h, PTLFormulas.h, PTLFormulaeKit .cc
> 4) I keep wondering, why this name PTL comes up? Shouldn't be
> PLN? I think, these files should be re-organized as follows:
> Formulas.h should be merged with PTLFormulas.h since they have
> essentially the same content PLNFormulas. Then PTLFormulaeKit .cc
> should be renamed PLNFormulas.cc, this way ... only two files will
> remain ... PLNFormulas.h and PLNFormulas.cc ... more intuitive.
> 4.1) keeping the same philosophy, IndefinitePLNFormulas.h/.cc
> should be renamed PLNIndefiniteFormulas.h/.cc to keep the name format.
PTL stands for Probabilistic Term Logic... It's what PLN used be
called (although I'm unaware of the reason it was renamed... perhaps
because of the aesthetic reason that the acronym is a mirror of NLP?)
The renaming makes sense...
> ************ PLN Rules Section
> ************ Ptlatom.h/.cc, Rule.h, RuleApp.h/.cc. RuleProvider.h/.cc,
> Rules.h/.cc
> 5) I have a hard time understanding Ptlatom.h/.cc ... was it
> substituted by some opencog elements? Perhaps Atom.h?
It's a separate structure which I think holds items important for PLN.
> 5.1) Rule.h is just the declaration of a single rule, in order
> to maintain the file space clearer, i think it could be merged with
> Rules.h.
I'd like to keep them separate, and perhaps even have a subdirectory
for rules with each rule in a separate file. I prefer having a
header/cc per class.
> 5.2) RuleProvider.h/.cc could be renamed RuleContainer.h/.cc
> since this is a class that inherits from vector<Rules*> a container of
> Rules.
fair enough
> 5.3) Finally, RuleApp.h/.cc ... what is this class about?
> Inherits from Rule and VtreeProvider, where VtreeProvider just has a
> vtree inside and a getvtree method, so not manipulating vtree
> directly? I thought RuleApp.h/.cc could be just dropped, since
> Tester.cc is the one that heavily used it, and I'm more interested in
> getting PLNShell.cc to run, but then I found that ...
>
> BackInferenceTreeNode.cc:1320: RuleApp*
> ruleApp = (RuleApp*)NULL;
> BackInferenceTreeNode.cc:1335: ruleApp = new
> RuleApp(rule);
> BackInferenceTreeNode.cc:1337: next_result =
> ruleApp->compute(rule_args.begin(), rule_args.end());
> //rule->compute(rule_args);
>
> Function stack ...
> BITNode::EvaluateWith(...)
> BITNode::NotifyParentOfResult
> BITNode::addDirectResult
> BITNode::CheckForDirectResults
> BITNode::expandNextLevel
> BITNode::expandFittest
> BITNodeRoot::infer
>
> So, it seems quite important, but I could find a reason why not
> use Rule directly? Is it because one wants a vtree rule?
I think I should let Ari answer this, I'm not entirely sure, but I
think RuleApp is an application of a series of rules, so is associated
with concrete atoms, whereas the Rules are used for matching and doing
the calculation behind the Rule.
> ************ PLN Utils Sections
> ************ PLNUtils.h and PLNUtils.cc
> 6) These files have an enormous number of functions. So, instead
> of put them in a separate directory /util, move then to the main
> directory.
I'd prefer to keep PLN specific utilities out of the rest of OpenCog.
If there are some that are generally useful, then I'm happy for those
to be moved.
There was a separate util directory in the Novamente PLN, but I
flattened it to aid my understanding and integration (since I knew I'd
have to spend some time refactoring and tidying up later.
> ************ All the remaining Sections
> 7) BOASimulatorAgent.cc and BOASimulatorAgent.h ==== these seem
> a different application of PLN, maybe move then to TESTS.
This can probably be removed for now... since it relies on MOSES which
isn't in OpenCog yet.
> 8) ContextInfo.cc, ContextInfo.h, Context.cc, Context.h,
> PerceptActionloop.cc, PerceptionActionLoop.h, ResourceManager.cc,
> ResourceManager.h ==== aren't these the context/attention framework
> that you have been working on? They are sort of disconnected to the
> PLN (Formulas, Rules and Backward Inference) as it is my
> understanding.
No, these are part of PLN...
Context's are integral to the calculation of probabilities in PLN
(even if the context=the universe).
The perception files are potentially not necessary and related to
controlling an agent in a simulated world. Not sure about the
ResourceManager does yet.
> 9) pshpack1.h, ptlformulas_old.h, temptest.cc,
> reasoning.doxygen, StdAfx.cc, Grim.cc
> tree_gen/, LinkPair.h, GenericEvaluator.h, PTLOperations.h,
> PTLEvaluator.h ==== I couldn't find any use for these.
the doxygen file is just generates documentation using the Doxygen tool.
Not sure about the others, although I've removed StdAfx.[h/cc] and
replaced it with PLN.h in my repository.
> 10) BackInferenceTree4.h, InferenceException.h and
> BackwardInferenceTask.h, BackwardInferenceTask.cc ==== looks as a
> higher abstraction of the Backward Inference engine, but except from
> Tester.cc (if I remember correctly) these are not used by PLNShell.cc
> 11) ExplicitlyEvaluatedBITNode.cc and CrispUnificationRule.cc
> ==== two specializations of "Backward Inference Nodes" and "Rules"
> that deserved a separate file. Perhaps, we could create a separate
> directory and populate them with all Rules and specializations. Since,
> it is usually good to have small implementation files, and not 2000
> lines ones.
> 12) Spacetime.cc, TemporalMining.cc ==== unless in the figure,
> novamente releases the Time Server, there are not meaningful.
They handle temporal inference. The OpenCog AtomSpace has a TimeServer.
> 13) PTLAgent1.h/cc and Tester.cc – these seem TESTS
> implementations of the PLN to be moved to TESTS directory, but as I
> commented above, they use very specific redundant files.
We'll have to try and update them once the library compiles.
Cheers,
Joel
Linas Vepstas
>> But then, this should be a
>> global variable, something like extern AtomSpace * nm =
>> CogServer.getAtomSpace(); in every file.
Please avoid global variables; these will interfere with multi-threading.
If absolutely needed, then please wrap them with a function call,
e.g get_my_global(), so that the guts of this subroutine can later
be replaced by pthread_getspecific() or whatever, as needed.
--linas
Cesar Marcondes
Thanks for your answers,
On Tue, Jul 22, 2008 at 4:52 AM, Ari Heljakka
<ari.he...@dreambroker.fi> wrote:
>>> 1.2) What does this do: "#define getTypeFun
>>> std::bind1st(std::mem_fun(&NMCore::getType), nm)"
>>
>> This binds the getType member function to an instance of the AtomSpace
>> so that it can be used and passed as a function pointer/reference (I
>> think...)
>
> Frankly, it's very difficult to debug problems in PLN code (or moses for
> that matter) without understanding STL templates and the functor system
> (incl. binding).
I think my problem understanding that was that NMCore and nm full
implementations were not available. Besides, I'm not an expert on
functors. But, thanks for the tip.
>>> 1.3) why vtree is not exposed in atomspace/utils2.h? the typedef is
>>> inside utils2.cc !!!
>>
>> I know, there is some messed up stuff in utils.cc and utils2.cc - they
>> should really be unified... and some of the defined functions don't
>> actually have implementations. I've fixed them enough so that PLN will
>> compile, but it's something to put on the TODO list.
>
> IIRC, it is not the case that both utils.h, utils2.h, utils.cc and utils2.cc
> are necessary.
Your memory is right, utils2.cc/h is the one mostly used in PLN.
However, some functions that should be in utils2.cc are in utils.cc.
For example, exists and i2str are declared in utils2.h, are used by
PLN, but are implemented in utils.cc.
>>> ************ Atom Manipulation Section
>>> 2) The AtomTableWrapper is enormous. Couldn't we just use AtomTable
>>> implementation itself? And put some other functions in PLNUtils.cc,
>>> for example LoadAxioms could be implemented just like loadXML in
>>> CommandRequestProcessor.cc (server) and DumpXX, GetRandomHandle,
>>> Freshened so on.
>>
>> I'd like to keep the AtomTableWrapper for now... it may be useful if
>> we try to make PLN a self contained library that can be used outside
>> of OpenCog.
>
> Unfortunately you can't just start dropping elements from PLN. Otherwise,
> the inference tests will most certainly fail.
> ATW contains expression normalization code.
Could you elaborate more on the ATW classes? What is the difference
between LocalATW? DirectATW? NormalizingATW? and DirectATW? How about
mindShadow and MindDBProxy? Using only the opencog atomspace library
available would you consider have them all available?
> Seriously, I think people should actually read the comments in header files
> before posing questions, but just for this once, I'll copy-paste from the
> header file here:
Sorry about that. My bad, I probably skipped reading the RuleApp description.
"RuleApp class implements a comprehensive inference tree
representation, where you can know exactly which sequence of Rules and
intermediate results did produce a certain final result."
It looks from the description as a debugging feature. I guess, that's
why I didn't understand it is use only looking at the code.
>>> 13) PTLAgent1.h/cc and Tester.cc – these seem TESTS
>>> implementations of the PLN to be moved to TESTS directory, but as I
>>> commented above, they use very specific redundant files.
>>
>> We'll have to try and update them once the library compiles.
>
> Tester.cc is essential. If you can't run it correctly, then there is no hope
> in getting PLN port ever to work. However, if it does run correctly, then
> you are 99% home free.
I thought PLNShell was the one that would do extensive tests.
> --
> Ari Heljakka
> CTO
> Dream Broker Ltd
>
> Tekniikantie 14 ari.he...@dreambroker.fi
> 02150 Espoo +358 40 568 2420
> Finland www.dreambroker.fi
>
Thanks again,
Cesar
Cesar Marcondes
On Tue, Jul 22, 2008 at 9:10 AM, Ari Heljakka
<ari.he...@dreambroker.fi> wrote:
> It has manual tests that you can run step by step on the Shell. Do you have
> access to the PLNShell screencasts?
No. Do you happen to have these screencasts? Is this a video of the
PLNShell/Tester executing?
Thanks,
Cesar
Joel Pitt
there... did you remove them Ben?
I thought I had copies, but can't track them down.
J
Joel Pitt
<ari.he...@dreambroker.fi> wrote:
>> I think my problem understanding that was that NMCore and nm full
>> implementations were not available. Besides, I'm not an expert on
>> functors. But, thanks for the tip.
>
> OpenCog... Is there a document about this somewhere?
It seems to be slightly simpler than Novamente... unfortunately there
no real documents except for the code. There's the AtomSpace which is
the interface to the AtomTable where all the Atom indexes are stored.
There is also TLB class for converting Handles to Atoms.
I'll admit having the Novamente code available to me makes it a lot
easier to carry out the conversion to OpenCog. Cesar would have to
sign the obligatory non-disclosure document before I could pass it to
him..
>> Could you elaborate more on the ATW classes? What is the difference
>> between LocalATW? DirectATW? NormalizingATW? and DirectATW? How about
>> mindShadow and MindDBProxy? Using only the opencog atomspace library
>> available would you consider have them all available?
>
> DirectATW is the direct route to AtomTable.
> NormalizingATW normalizes the atoms before they are inserted to AT.
> Mindshadow is IIRC obsolete.
> MindDBProxy is a NM construct, refer to NM core code docs.
> LocalATW is IIRC for debugging, and obsolete.
Thanks Ari - these small snippets of class descriptions (including
those in the earlier of the PLN documents) are useful for getting an
overview. The code documentation, where it exists, is useful, but it's
difficult to jump around trying to surmise what each does.
> Is not. It's for mining inference trajectories, mainly. And other fun stuff.
> Nobody ever got the point of actually mining them - which would be
> interesting! I had to quit PLN programming by the time I just had finished
> the actual RuleApp system for _recording_ the trajectories.
Can't wait to explore the trajectories!
J