opencog-dev team mailing list archive

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

On Fri, Aug 1, 2008 at 2:37 AM, Ben Goertzel <ben@xxxxxxxxxxxx> wrote:
> On Thu, Jul 31, 2008 at 10:29 AM, Ari Heljakka <ari.heljakka@xxxxxxxxxxxxxx>
> wrote:
>>
>> Ben,
>>
>> in fact I don't recall all the details either - it's a fairly complex
>> issue.
>>
>> I don't think there's any advantage with freshness over VHs as such, but
>> the point is that you need to treat them a bit differently code-wise, and
>> the risk of getting strange problems with TVs etc. is high, if you try to
>> "blindly" port a system (PLN) which makes heavy use of freshness to using
>> VHs.
>>
>> But, as I suggested, you maybe be able to implement support for freshness
>> _in terms of VHs_ in a relatively simple way to cheaply finish the PLN port.
>
> OK, I understand...
>
> I think I understand VH's pretty well, but I'm not sure I understand
> freshness.
>
> Was the idea simply that when an Atom is newly inserted in the core, then it
> has fresh=true ... but then after some process tries to merge it with other
> Atoms that may have the same structure, then it has fresh=false?  Or am I
> totally off-base?

the fresh=true is a parameter to the Core function for adding Atoms to
the AtomTable. It essentially tells the core that it doesn't need to
check that the atom is unique (assumedly because the caller of the
function already has obtained some advance knowledge about the
AtomTable composition).

when fresh=false, the add functions does check for uniqueness.

PLN exploits this parameter to store multiple atoms that are equal but
that have different TVs. Then after selecting which inference to use,
the TVs of the multiple but equivalent atoms are merged into a single
atom.

Fresh=false is the implicit way that OpenCog works (as far as I
understand it). I'm guessing this was to avoid misunderstanding in
future.

> In this case, is your suggested workaround to do something like: create a
> Context called "fresh", and then instead of creating Atoms with fresh=true,
> create Atoms with TV versions corresponding to the context "fresh"?

They'd still be the issue that there are multiple non unique atoms
being added to this "fresh" Context.

-
I think Ari's suggestion of dealing with the fresh stuff in the
AtomTableWrapper is a good intermediary solution (perhaps when my PLN
foo is up to his I can completely go with VersionHandles though).

I guess the question to do this is: what makes atoms unique? From the
OpenCog code, for Nodes this seems to be the name and type, for Links
it's ONLY the outgoingset (I find it strange that Type isn't
included... is this correct?).

So for hypothetical Nodes, I could represent them by using some naming
scheme such as prefixing the name of all PLN nodes by "__PLN__" or
something.

For hypothetical links, it'd be more difficult, since they don't have
names, only the outgoing set... perhaps the creation of additional
nodes for each hypothetical link (again, with a "__PLN__#" prefix)
that are then connected to those hypothetical links, thus making each
of them have a unique outgoing set.

... But perhaps this is all just as complicated and extraneous work
that could be spent directly on utilising VersionHandles?

J