opencog-dev team mailing list archive

[Ari Heljakka <ari.heljakka@xxxxxxxxxxxxxx>]

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.

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