← Back to team overview

opencog-dev team mailing list archive

Re: PLN status?

 

If there are multiple versions of the same atom in the atomspace, then PLN expects that a separate Handle will be returned for each. The getHandleSet method should just return Handles, not pairs.

-A

Joel Pitt wrote:
Hi again Ari,

Can you remember the semantics of how PLN uses the getHandleSet methods?

Specifically, does it expect separate entries in the returned set for
each TruthValue associated with a given atom?

e.g. Handle h has a primary truth value and a versioned one with
version handle vh.

Should the AtomTableWrapper's getHandleSet return

pair<h,NULL_VERSION_HANDLE> and pair<h, vh> or simply return h?

I suspect the separate entries are necessary so I'm going to go
forward with that, but wanted to check and record my steps so that you
can jump in and stop me if I start doing something that sounds
obviously wrong.

J

On Wed, Aug 20, 2008 at 9:23 PM, Ari Heljakka
<ari.heljakka@xxxxxxxxxxxxxx> wrote:
PLN requires that if it creates an Atom with fresh=true and TV = TV1, then
the resulting Handle will have that exact TV and that exact structure, and
those 2 features can later be retrieved by using that Handle.

PLN requires that if it creates an Atom with fresh=false and TV = TV1, and
- if an atom with that structure exists with TV2.confidence = 0, then the
the TV of that atom will be set to TV1 and a Handle to that atom is
returned.
- if an atom with that structure exists with TV2.confidence > 0, then I'm
not sure what happens, but most likely the "acceptable" way is to return a
Handle to that atom without changing its original TV. The "correct" way is
to revise the TVs, but IIRC this was not implemented, and there's a (small)
chance that its implementation would change the dynamics of PLN
unpredictably.
- if an atom with that structure does not exist, then things happen exactly
as if fresh = true

And, Handles must be convertible to integers.

IIRC these are the only constraints as far as PLN is concerned. I have no
opinion about the internals, VH-usage etc.

-A

Joel Pitt wrote:
Hi Ari (and Novamente people),

So I've implemented a fresh add that uses dummy Contexts. I'm now
considering the best way to implement retrieval of version specific
TruthValues, since one can no longer can simply use the Handle, as the
VersionHandle is also needed to recall a specific TruthValue.

My idea was to use a pair<Handle,VersionHandle> in place of Handle
within the boost::variant Vertex. The tricky pointer/type distinction
can still go on with the Handle part of the pair. I want to check
first however before going ahead with it, since the Vertex variant is
used within AtomSpace for an addAtom method and within AtomSpace
utility files, so perhaps there are other things within Novamente that
would be impacted if they are being ported to OpenCog?

Cheers,
J

On Wed, Aug 20, 2008 at 5:54 AM, Ari Heljakka
<ari.heljakka@xxxxxxxxxxxxxx> wrote:
Joel,

once I finally got to the linking stage, MSVS finds 104 errors and then
crashes. It may be due to some of the very long template error messages.

I used to compile novamente code without serious problems in spring 2007.
Perhaps the OpenCog has added some special extra complication there...
I've
never seen anything like this with MSVS; I'm using the 2005 version.

Anyway, since I'm not going to be helpful with the code anytime soon,
I'll
prioritize giving you some of those screencasts regarding the most
important
PLN classes.

-A

Joel Pitt wrote:
Still working on compiling it? Sorry it's a pain :/

In the BZR branch I've recently added a function stub to add atoms in
dummy contexts and hopefully will get this done by the end of the
week. I'm somewhat confident about what I have to do to allow the
addition of atoms emulating fresh functionality, but a little hazy on
how to provide the recall of those atoms since instead of handle
they'll also need a version handle (or the index of the dummy context
used).

J

--
Ari Heljakka
CTO
Dream Broker Ltd

Tekniikantie 14                 ari.heljakka@xxxxxxxxxxxxxx
02150 Espoo                     +358 40 568 2420
Finland                         www.dreambroker.fi




--
Ari Heljakka
CTO
Dream Broker Ltd		

Tekniikantie 14			ari.heljakka@xxxxxxxxxxxxxx
02150 Espoo			+358 40 568 2420
Finland				www.dreambroker.fi



References