opencog-dev team mailing list archive

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

Hi Ari,

On Thu, Aug 21, 2008 at 8:54 PM, Ari Heljakka
<ari.heljakka@xxxxxxxxxxxxxx> wrote:
> Given the apparent complexity of the VH approach, I'd say that simply adding
> a new method for inserting atoms with fresh=true into the AtomSpace might be
> a more sensible approach than using VH's to simulate that effect.

In the short term that might be a sensible approach to get it working
and check that the port generally works (although I'm not sure if this
will mess up the AtomSpace's index system). Long term however, we'll
still want to ensure that the AtomSpace is consistent.

> PLN does typically keep track of the Atom it uses via the Handles, but if an
> atom is the root of a link tree hierarchy, then often PLN only keeps track
> of the root atom and assumes that it can fetch the outgoing tree from
> atomspace when needed.

If it assumes this, how does it ensure it gets the correct
node/link/TruthValue back? Since the getHandle method returns a single
atom, but there may be more than one atom that matches the getHandle
parameters (since fresh=true overrides the check to make sure atoms
are unique). Or if PLN uses getHandleSet instead and retrieves a
number matching handles (thus getting around only singular results
being returned), how does it work out which specific handle and thus
which TV to use?

... actually, I just realised that one can simply follow the outgoing
links of the root and trace along the tree. So I'm assuming this is
how the outgoing tree is fetched?

> So, we must be able to later unambiguously associate that root atom version
> into specific atom versions in its outgoing tree. Ie. it's not enough to
> store the version of the root atom, because the whole outgoing tree may have
> to be the "same version".

Right, since all adds under a given tree need to have the same version
I'll have to think some more about this, and then look at the code
more. Actually, since I'm essentially replacing Handles with
pair<Handle,VersionHandle> in Vertex (and thus vtree), it should be
possible to easily find the context of a tree before performing an
add. In fact, would it be possible to use the root atom of each tree
as the context?

Much thanks for the screencast code tutorial, I'll give it a watch
tomorrow morning before I jump on the plane.

J

> -A
>
> Joel Pitt wrote:
>>
>> On Thu, Aug 21, 2008 at 6:03 PM, Ben Goertzel <ben@xxxxxxxxxxxx> wrote:
>>>
>>> 1)
>>> What are the cases in which a link would have targets in different dummy
>>> contexts
>>
>> Well, I'm not entirely sure...  contexts are associated with atoms as
>> they are needed (i.e. whenever PLN attempts to add a new atom to the
>> atomspace and the atom already exists). Dummy contexts are just
>> incremental counters at the moment, such that the first versioned
>> TruthValue of any atom would be associated with context __PLN__1, the
>> second __PLN__2, etc. So depending on how PLN accesses and adds atoms,
>> these counters may increase asynchronously for each. The maximum
>> number of contexts is never more than the maximum number of versioned
>> truth values that any atom has.
>>
>> In other words, the dummyContexts are not created intelligently, but
>> in the AtomTableWrapper, outside of the operation of PLN.
>>
>> Perhaps this wasn't what was intended in the original discussion of
>> dummy contexts... (it can be changed though, most of the work is in
>> appropriately replacing Handles by pair<Handle, VersionHandle> within
>> PLN).
>>
>>> 2)
>>> I recall that, for other reasons (nested contexts), I proposed that
>>> VersionHandles be allowed to contain lists of context AtomHandles, as
>>> well
>>> as individual AtomHandles.  This was never implemented but is described
>>> on
>>> the NM wiki.  Maybe this mechanism could be used here.
>>
>> I saw this - and I think it'd be a the correct way of implementing PLN
>> in the long term, but of course would require the extra time
>> implementing ComplexVersionHandles (
>>
>> https://extranet.vettalabs.com:8443/bin/view/Novamente/ComplexAtomVersionHandles
>> )
>>
>> I guess my question is for Ari, and depends on whether PLN relies on
>> obtaining Handles from the AtomSpace, or if it keeps track of them
>> within the PLN structure, e.g. vtrees, BoundVTrees, etc. If the
>> latter, we should be safe, but if it's the former I'll have make
>> alternative changes.
>>
>> J
>>
>>> ben
>>>
>>> On Thu, Aug 21, 2008 at 9:00 AM, Joel Pitt <joel.pitt@xxxxxxxxx> wrote:
>>>>
>>>> On Thu, Aug 21, 2008 at 5:46 PM, Ben Goertzel <ben@xxxxxxxxxxxx> wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Perhaps I'm misunderstanding something ... why can't you just use the
>>>>> same
>>>>> dummy context as the one associated with the relevant-versioned TV in
>>>>> the
>>>>> node that the link is associated with?
>>>>
>>>> When a link has more than one node with a versioned TV in it's
>>>> outgoing set, which dummy context should it use?
>>>>
>>>> (I might be missing the big picture of how inference works from
>>>> staring at c++ templates too long)
>>>>
>>>> J
>>>
>>>
>>> --
>>> Ben Goertzel, PhD
>>> CEO, Novamente LLC and Biomind LLC
>>> Director of Research, SIAI
>>> ben@xxxxxxxxxxxx
>>>
>>> "Nothing will ever be attempted if all possible objections must be first
>>> overcome " - Dr Samuel Johnson
>>>
>>>
>>>
>>
>
>
> --
> Ari Heljakka
> CTO
> Dream Broker Ltd
>
> Tekniikantie 14                 ari.heljakka@xxxxxxxxxxxxxx
> 02150 Espoo                     +358 40 568 2420
> Finland                         www.dreambroker.fi
>