opencog-dev team mailing list archive

["Ben Goertzel" <ben@xxxxxxxxxxxx>]

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
>



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