opencog-dev team mailing list archive

["Joel Pitt" <joel.pitt@xxxxxxxxx>]

another email....

I was thinking about how the dummy contexts mechanism works.

Originally, with fresh == true you'd be able to work out exactly which
TV of a node a link is associated with:

A_1.tv 0.5; A_2.tv 0.7; A_3.tv 0.8;
B

Then you could have separate links to connect each...

AB_1: A_1 -> B
AB_2: A_2 -> B
AB_3: A_3 -> B

so you'd know exactly what TruthValue you were referring to with a link.

With version handles we now have:

A.tv (primary 0.5, versioned 0.7, 0.8)
B

AB.tv (primary x, y, z)  (what these values are don't matter for this argument)

But we no longer know which versioned TV in AB was connected with each
versioned TV in A. I don't think this matters theoretically... but I
was concerned this could have practical impacts on whether dummy
contexts will work with the current PLN implementation, thus I wanted
to bring up whether this might be an issue now...

One could create new unique dummy contexts based on the dummy context
of the relevant versioned TVs for atoms in the outgoing set. This
would allow retrieval of the correct versioned destination atom TV
when necessary. But that'd make things even more complicated and I'm
really hoping that this isn't necessary....

J

P.S. I'm departing for the US tomorrow afternoon, and will be out of
touch from the net until 1st Sep while I run around in the Nevada
desert.


On Thu, Aug 21, 2008 at 12:22 PM, Joel Pitt <joel.pitt@xxxxxxxxx> 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
>>
>