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 <[EMAIL PROTECTED]>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 [EMAIL PROTECTED] > 02150 Espoo +358 40 568 2420 > Finland www.dreambroker.fi > -- Ben Goertzel, PhD CEO, Novamente LLC and Biomind LLC Director of Research, SIAI [EMAIL PROTECTED] "Nothing will ever be attempted if all possible objections must be first overcome " - Dr Samuel Johnson
_______________________________________________ Mailing list: https://launchpad.net/~opencog-dev Post to : opencog-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~opencog-dev More help : https://help.launchpad.net/ListHelp
