opencog-dev team mailing list archive

["Ben Goertzel" <ben@xxxxxxxxxxxx>]

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?

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

I don't know if any of the above makes sense ... but it does seem to me it
would be very worthwhile if you could take a few hours to fully refresh your
memory on these issues to as to give Joel some more detailed guidance.  I'm
sure he can work through these issues on his own, but some more careful
guidance from you could potentially save him days or even weeks of
misdirected effort.

thx
ben


>
>
> OTOH, it's possible that the code-level similarity of freshness to VHs was
> much higher than I can recall, and that the jump to VHs is more trivial than
> I assume. But in matters like this the conservative approach is almost
> always the correct one.
>
> I never used VHs which is why I can't give higher confidence answer.
>
> But as a rule of thumb, when porting stuff to a new system, it's of course
> typically a fatal mistake to many non-trivial changes to the code being
> ported, because the inevitable bugs will then be very difficult to locate.
>
> -A
>
>
> Ben Goertzel wrote:
>
>> Ari,
>>
>> Sorry, I think I must have understood this in the past at some point, but
>> senility encroaches ;-p
>>
>> Can you remind me why we need freshness in the OpenCog core, if we have
>> VersionHandles there?
>>
>> What does freshness handle that VH's do not; or, what does freshness
>> handle
>> much more simply or efficiently than VH's?
>>
>> thx
>> ben
>>
>> On Thu, Jul 31, 2008 at 9:24 AM, Ari Heljakka
>> <ari.heljakka@xxxxxxxxxxxxxx>wrote:
>>
>>  Hi Joel,
>>>
>>> unfortunately there is absolutely no way in which you can, in a
>>> reasonable
>>> time, complete the porting by changing all PLN code to use the
>>> VersionHandle
>>> system.
>>>
>>> With luck, I might be able to do it myself with 3-4 days of work. For
>>> someone not experienced with various subtleties of PLN, even for a pro
>>> like
>>> you, less than 3 weeks would sounds optimistic.
>>>
>>> I suggest that, instead, the fresh-parameter is introduced to OpenCog
>>> core
>>> (with default = false), and it is implemented so that its functionality
>>> mimics the functionality of the fresh parameter in NM core. That should
>>> not
>>> prove to be much work, and it may have uses beyond PLN. (It wasn't
>>> created
>>> for PLN in the 1st place.)
>>>
>>> The "fresh" parameter is a feature that is fundamentally required by PLN.
>>>
>>> The point of freshness is that you can have multiple instances of an atom
>>> with identical structure. And, when you add a new atom to atom space, PLN
>>> wants to have the option to either force it to be independent of previous
>>> such atoms, or to allow its integration to existing such atoms.
>>>
>>> If you don't want to or can't change the OpenCog atom space interface to
>>> support that, then you may be able to simulate it in the
>>> AtomTableWrapper.
>>>
>>> In principle VHs can mimic the "freshness" conceptually, but in practise
>>> it'll be hell of a job to convert between these 2 representations of the
>>> same thing.
>>>
>>> Regarding the template debugging, I've always found Linux C++ dev tools
>>> to
>>> be a time-drain for serious stuff (which is why I use Visual Studio which
>>> handles template debugging etc. in a nice way), but there _is_ a
>>> semi-useful
>>> tool for tackling the template naming debug issue for Linux, but it is
>>> suitable only for parsing the output of the compiler/linker I think, not
>>> IIRC real-time debugging. I can ask if anyone remembers the name of it if
>>> you wish.
>>>
>>> -A
>>>
>>>
>>> Joel Pitt wrote:
>>>
>>>  Hi Ari and Ben,
>>>>
>>>> I've got to stage where PLN compiles, the shell runs and Tester gets
>>>> to a certain point before an assertion fails regarding a Handle not
>>>> being "real" (which from my understanding means it has a Handle less
>>>> than the number of atom types). I don't have enough holistic
>>>> understanding of PLN to debug this immediately... although I could
>>>> step through from the beginning, it'd be slow.
>>>>
>>>> The only thing that I *expect* to be breaking things is adding atoms
>>>> to the AtomSpace. In OpenCog there is no fresh or managed parameter,
>>>> thus I had to remove those from the addAtom calls to get it to
>>>> compile. Removing the fresh=true bug was also one of the next tasks
>>>> for me to tackle... thus my inclination is to try to fix that bug
>>>> first before trying to trace the exact cause of the un"real" Handles
>>>> in places they shouldn't be.
>>>>
>>>>  From memory, I think the plan was to use VersionHandles? Is this
>>>> correct?
>>>> I've been trying to trawl through my gmail archives to glean insights
>>>> about the problem, and while I'm slowly getting there, any advice or a
>>>> point in the right direction would be appreciated. Also... if there
>>>> are particularly important conversations or wiki pages that I should
>>>> read, feel free to point me at those.
>>>>
>>>> Oh, and lastly, does anyone have any suggestions of tools for parsing
>>>> and understanding template while debugging? With each Vertex being a
>>>> somewhat long boost::variant it can get tedious to comprehend the
>>>> output... Currently I'm just using Vim and gdb along with a .gdbinit
>>>> hack that allows one to print all the stlcontainers more nicely.
>>>>
>>>> Thanks,
>>>>
>>>> J
>>>>
>>>>
>>>>  --
>>> Ari Heljakka
>>> CTO
>>> Dream Broker Ltd
>>>
>>> Tekniikantie 14                 ari.heljakka@xxxxxxxxxxxxxx
>>> 02150 Espoo                     +358 40 568 2420
>>> Finland                         www.dreambroker.fi
>>>
>>>
>>
>>
>>
>
> --
> 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