opencog-dev team mailing list archive

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

Hi all,

Here are my current thoughts on PLN and dummy contexts (mostly to
solidify the task in my mind, but also for comments):

AtomTableWrapper maps between fake PLN handles and "real" Handle,
VersionHandle pairs.

The VersionHandles of PLN associated atoms have their substantive
component as the dummy context of root of tree/sub-tree they are part
of.

This means that I'll have to go through the code and ensure that:

- all add atom operations with fresh=true need to have dummy context
of the root provided (directly or worked out through the parents of
the new atom).
- all get atom operations also provide the dummy context of the root.

.. as well as adding the appropriate transformations for all the
AtomTableWrapper methods that interact with the AtomSpace.

Thinking ahead... to save space, it doesn't seem like it's required
that each atom be connected to it's context via a ContextLink. The
versionHandle still contains the context node, so the context link is
implicit, this might not be good in general situations where other
processes may need to reason on the ContextLinks, but for this PLN
hack I don't think we need this.

J


On Thu, Aug 21, 2008 at 1:16 PM, Ben Goertzel <ben@xxxxxxxxxxxx> wrote:
>
> Yes, I agree w/ Cassio's comments
>
> If Joel does go w/the temporary-hack approach, then shortly thereafter, it
> seems like ComplexVersionHandles should be implemented (actually maybe this
> could be done in parallel with the hack approach to PLN) and the fresh=true
> issue fixed for real...
>
> ben
>
> On Thu, Aug 21, 2008 at 6:07 PM, Cassio Pennachin <cassio@xxxxxxxxxxxxx>
> wrote:
>>>
>>> the question is whether to 1. temporarily support this hack which PLN is
>>> deeply dependent on, or whether to 2. refactor PLN to use VHs _before_
>>> completing the port (the completion of the port = situation where PLN tests
>>> run successfully).
>>
>> The problem is the lifetime of "temporary" hacks.  The vast majority of
>> this population has proven to live a lot longer than we'd wish for.
>>  Although we haven't eliminated ALL such hacks while moving code from
>> Novamente to OpenCog, we've tried to get rid of the worst ones. Your wording
>> exemplifies everyone's attitude about it: the port would be considered
>> complete while still including the hack, and after that the motivation to
>> remove it is likely to vanish.
>>
>>> But my best guess is that choosing #2 will take much more time than the
>>> whole process of doing #1 + verifying that PLN tests run + refactoring PLN
>>> to using VersionHandles _gradually_ + eventually removing the hack from the
>>> atomspace.
>>>
>>
>> You may be right.  I'm willing to consider with this route as long as the
>> gradual aspect is removed, and we only consider the port as done once the
>> hack is removed.  This would satisfy my main goal, which is to keep this
>> hack away from the main code line.
>>
>> Cassio
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~opencog-dev
>> Post to     : opencog-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~opencog-dev
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> 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
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~opencog-dev
> Post to     : opencog-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~opencog-dev
> More help   : https://help.launchpad.net/ListHelp
>
>