opencog-dev team mailing list archive

["Ben Goertzel" <ben@xxxxxxxxxxxx>]

OK, then part #1 of my solution would seem to (conceptually) resolve the
problem ... so let's adopt it as a working approach unless exploring the
code details proves it unworkable...

ben

On Fri, Aug 1, 2008 at 8:32 AM, Ari Heljakka <ari.heljakka@xxxxxxxxxxxxxx>wrote:

> 1)
>> When PLN wants to set fresh=true, then the AtomTableWrapper
>> creates a new version for Atom A.
>>
>> PLN will have N different "dummy contexts" associated with it:
>> C1, C2,..., C_N
>>
>> The first version of A created by PLN will have a VH associated with
>> context C1... the second version of A created by PLN will have a VH
>> associated with context C2 ... etc.
>>
>
> This is fine, as long as PLN gets a separate valid Handle to each version
> of A, such that it can use that Handle as if it pointed directly to the
> actual A. So if you have a unique node for each context, that should work.
> Then, ATW just translates between the contextual form and the simpler form
> which PLN sees.
>
>  2)
>> Then, when appropriate, PLN can merge all the versions of A associated
>> with the different PLN dummy contexts into a single version (which in most
>> cases will just be the default version for the Atom A ... except in odd
>> cases
>> where the TV estimated for A by PLN is radically different from the one
>> estimated
>> by another method like direct evaluation, in which case we might still
>> want
>> to keep
>> around one PLN-based version of A, along with other versions...).  After
>> this merger
>> the dummy-context versions are all removed.
>>
>
> Well, the current PLN will never actually want to merge/delete those wrong
> versions. The AtomSpace "garbage collection" was never implemented due to
> being low priority at the time. (The "managed" parameter involved some
> attempt at it, but I don't remember the details.)
>
> Essentially, PLN treats the "fresh=true" atoms as VALUES, not as
> OBJECTS. So, it doesn't really care if multiple atoms with the same
> structure exist or not. It has its own data structures which track those
> different atom versions (with distinct TVs) and then merges them by creating
> a yet another atom version.
>
> So there's no need to implement your #2.
>
> IIRC, the GC happens currently by simply resetting the whole AtomSpace, and
> then re-initializing it with the premise set.
>
> ...How then it was possible to create a dynamic continously running system
> like the Fetch Loop without memory overflow? I probably did some ingenious
> engineering there, but it'll take me some code-reviewing to bring it back to
> mind...
>
>  I guess this would all be done in the AtomTableWrapper ...
>>
>
> Probably.
>
> --
> Ari Heljakka
> CTO
> Dream Broker Ltd
>
> Tekniikantie 14                 ari.heljakka@xxxxxxxxxxxxxx
> 02150 Espoo                     +358 40 568 2420
> Finland                         www.dreambroker.fi
>



-- 
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