Joel's work log 2008
Joel's archived work logs from 2008.
- 1 2008-12-27
- 2 2008-12-23
- 3 2008-12-22
- 4 2008-12-18
- 5 2008-12-17
- 6 2008-12-11
- 7 2008-12-10
- 8 2008-12-6 - 2008-12-9
- 9 2008-11-28
- 10 2008-11-20
- 11 2008-10-21
- 12 2008-10-20
- 13 2008-10-15
- 14 2008-10-14
- 15 2008-10-13
- 16 2008-10-10
- 17 2008-10-9
- 18 2008-10-8
- 19 2008-10-1
- 20 2008-09-30
- 21 2008-09-29
- 22 2008-09-26
- 23 2008-09-25
- 24 2008-09-20
- 25 2008-09-19
- 26 2008-09-20 and 2008-09-21
- 27 2008-09-18
- 28 2008-09-15
- 29 10 Sep 2008
- 30 2008-09-09
Finish implementing palimpsest training scheme.
Investigate PLNUTest taking too much memory... turns out using OpenCog XML loader bypasses some important CrispTheoremRule initialisation and normalisation. Sent email to Ari about proposed change - unsure why ImplicationLinks are replaced by FalseLinks.
Implement palimpsest training scheme in ECAN Hopfield demo. Modify other parts of Hopfield demo to be closer to Storkey's palimpsest experiments.
- Finally fixed PLN tests, tidy up.
- Reviewing Jared's code
- Step debugging through fetchdemo inference.
Recruiting house mate (Will) to work on AtomSpace visualisation. Various research of options for GUI and graphing libraries. In the end, http://ubietylab.net/ubigraph/ has the potential to do everything we need. The catch? The rendering server is free, but not open source (client side libraries are though).
Will is going to make a python script that pushes an scm dump to Ubigraph. Next would be a script to push OpenCog XML to Ubigraph. Then connecting the signals AtomSpace interface to a Ubigraph plugin that updates the ubigraph on AtomSpace changes.
Further information on visualising large social graphs mentioned at http://perlmonks.org/?node_id=675170 - points to several tools I haven't seen mentioned before.
OpenCL http://www.khronos.org/opencl/ could be useful for abstracting processing tasks and allowing OpenCL to deal with scheduling what tasks go to what processors.
Discovered Py++ http://www.language-binding.net/pyplusplus/pyplusplus.html - which will be of use for creating Python bindings to OpenCog.
- Solved one more PLN test failure.
- Back to the fetch demo tests.
- Discovered source of extra CrispUnificationRules (unnecessary freshened() call doubled those ForAllLinks that had And targets).
2008-12-6 - 2008-12-9
- Reading and editing ECAN and glocal papers.
- Assisting Jared.
- Setup 32 bit Ubuntu to run Novamente and compare PLN trace with OpenCog PLN trace.
- Tracing inference that fails when using bigdemo.xml, found that EquivalenceLinks were not being converted into dual ImplicationLinks when loaded through the NormalisedATW.
- Fixed AtomUTest.
For the last week -
- got several more PLN tests working. It's just the fetchdemo tests that run indefinitely without passing.
- added lots of in code documentation about how the AtomSpaceWrapper works (and put some on the wiki).
- spent some time helping Joshua Garner understand indefinite probabilities.
- provided guidance to Jared Wigmore's work on Agent configuration and reviewed/pushed his code.
- several fixes to hopfield demo to ensure it works properly with the new dynamic modules branch.
- rebased on staging and moved further PLN development to staging.
Been slack updating the work log, but briefly:
- got some of the PLN tests working.
- investigating making a video of tulip for Ben... turns out it's not immediately needed.
- made the TulipOutputWriter generic (converts generalised hypergraph to normal graph).
- copied some of my demo notes from the OpenCog workshop to QuickStartTutorial. Work in progress.
- documentation of the code, transferring knowledge from various articles Ari wrote into appropriate Doxygen code comments.
- temp doxygen file for checking documentation formatting.
More twiddling with Tulip and output parameters. Tulip is good at displaying stuff... assuming you edit the files by end. Trying to work out the optimal number
Optimised AtomTableWrapper to better cope with >15000 links (using bidirectional maps).
Method for creating graphs:
- Algorithm->Layout->Force Directed->GEM (Frick) - can cancel the second slow process after 20% or so. It's using self annealing so it just won't as near to optimal as possible. Render in 3d using distance as the metric.
- CTRL-R for rendering parameters. Turn on arrow heads.
- select root of subgraph hierarchy, then change to info editor. Edit the size for all links to "(0.05, 0.05, 0.5)". Edit the size of all nodes as "(2,2,2)".
- Dialogs->Layer Manager - select to display node labels.
- Select forward chaining results subgraph/cluster. Then change the viewColor of all entities to something like green.
Ben posted an article about the work on brainwave.
Converting scm to xml. adjusting node probabilities - checking the metrics are right.
testing scm file to xml, allowing xml to be loaded instead. SCM is a more convenient format, but currently the guile code Linas wrote to load files via a C++ API isn't merged with the staging branch.
More code wrangling. (6 hours)
Rebasing PLN to the dynmod/staging branch (6 hours)
Implement exporting to Tulip format.
Fix AtomTableWrapper bug (inadvertently calling Wrapper getHandle instead of AtomSpace getHandle)
Spent time fixing unit test with Gama.
Working with Tulip and getting display working correctly.
Rebased PLN (needed the new SCM code) plus it was long overdue. Disabled logically wrong unit tests... should be altered to check that getDiff value is correct (before it was always compared to zero).
Last time: got to the stage of transferring postgres pairs table to an scm file to load into OpenCog.
Trouble getting SCM file loaded into OpenCog... links are missing their outgoing sets. Rebase on main... new code doesn't have this issue.
Rebased attention branch and merged to lp:opencog. Fixed subsequent broken unit test.
Linas said, regarding the metric used:
"I do have a true "metric" or distance measure (that obeys the triangle inequality, so it really does measure distance). The triangle inequality says that the distance a->c is always less than the distance (a->b) + (b->c) for all b.
The metric is the (mutual entropy - mutual information)/(mutual entropy) and it is always positive, and always less than one. You can try it directly ... for mutual entropy, just take -log_2(prob) with prob taken from the pair table."
Edited script to calculate this metric instead of using mutual info directly.
Helping volunteers get established. Reading papers.
Plan for Summit demo:
- load all of Linas's word mutual information data into OpenCog.
- load through an hack on plnshell. commit current state and make a temporary branch for this demo.
- alter fw_beta function to more intelligently select nodes for Forward Chaining.
- output those new links with high confidence
Loaded word mutual information into local postgres database called lexat.
Decision to create Python script to transfer postgres pairs table into scm file and load that way.
Make opencog-to-tulip Python script that connects via telnet and exports the AtomSpace to tlp.
Fixed deduction and disappearing truthvalues for links. Answer obvious in hindsight.
Thus forward chaining works, started trying to get the rest of the PLN tests working before remembering that the forward chaining demo was to take priority.
Played with tulip, submitted bug report for loading data. Turned out to be erroneous '\' characters.
Tracked down error in Deduction rule for forward inference to do with incorrect rule arity. Now to fix it!
Installed Tulip from source.
Played with Tulip and files from Linas.
2008-09-20 and 2008-09-21
More fixing of the code. Solved some bugs for fake to real+VersionHandle translation.
Working on forward chaining, but the deduction rule doesn't seem to accept the inheritance links it is given as input.
Started page on the PLN Forward Chainer seeded from Vettalabs wiki.
Tracked down XML loading errors. Working on getting the Tester running properly.
Some logic errors in the conversion between real/AtomSpace and fake/PLN Handles.
Finish most of the AtomTableWrapper updates. Still unsure about specifics of dummy context behaviour, regarding:
- how NULL_VERSION_HANDLEs should behave
- what version of an atom getHandle should return
- in what cases will links be connecting nodes with different dummy contexts?
Chat to Ben about what the direction should be for the Singularity Summit. Discussed simple forward inference on Linas's work on mutual information of words in a body of text. Work out related words that are not immediately adjacent through inference.
- copy above stuff on fwd chaining to OpenCog wiki.
- install Tulip for visualisation.
- ask Ari about the above situations.
10 Sep 2008
Implemented isReal, getTimeServer, getArity, filter_type
Implemented a bunch of other AtomSpace functions.
Moved some global functions to appropriate reasoning namespace or to AtomTableWrapper.
Next day... use sed to replace AtomSpace references in Rule headers. Also place GET_ATW in front of those functions that are now in the AtomTableWrapper.
Yesterday involved trying to use boost::bimap to create a bidirectional map between fake and real Handles. This required upgrading to boost 1.36 as the ubuntu boost version is 1.34 in Hardy. However, things were not simple as this resulted in non standard code that uses the "long long" type. The compiler option -Wno-long-long got around this, but further troubles with the structured_pair.hpp boost header have convinced me to skip this temporarily. A simpler (but much slower) option is to just use a vector of std::pair<Handle, VersionHandle> with the index being the fake Handle. Going to a bidirectional map can be done once the code is functional.
Tasks that will need to be done are:
- getOutgoing - only return when the outgoing nodes have a context that matches the link (or the context of the link inherits from the context of the nodes). Perhaps provide a "strict" parameter to indicate if this should be the case or not.
- addAtom - addAtom should have it's context specified if fresh == true. For Nodes this has to be worked out based on how they'll be connected to a tree by other links (it should use the same context as the link that connects it to the rest of the tree). A link should use the context of the "up stream" (towards the root) node/link it connects from. If this context is already taken by a truth value, it adds a new context that inherits from the tree's most recent context.
Mentioned on the email list that it doesn't seem required for VersionHandled atoms to be explicitly connected to their contexts via context links. Cassio indicated that from recollection ContextLinks are now obsoleted for this reason.
- Replaced boost:bimap modifications.
- have to implement the following AtomTableWrapper methods: