opencog-dev team mailing list archive

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

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
>