← Back to team overview

opencog-dev team mailing list archive

Re: PLN status?

 

Cassio,

to sum up my point:

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

If people are up to the task of doing #2, then by all means let's do so.

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.

-A

Cassio Pennachin wrote:
Hi,

Given the apparent complexity of the VH approach, I'd say that simply adding a new method for inserting atoms with fresh=true into the AtomSpace might be
a more sensible approach than using VH's to simulate that effect.

In the short term that might be a sensible approach to get it working
and check that the port generally works (although I'm not sure if this
will mess up the AtomSpace's index system). Long term however, we'll
still want to ensure that the AtomSpace is consistent.

I'm on a business trip and just skimming this thread, so pardon me if I sound idiotic. Doesn't using fresh=true instead of VH's result in multiple copies of the same Atom (Nodes with the same type + name or links with the same type + outgoing set) stored in the AtomSpace? If so, we shouldn't use this practice in OpenCog. We've been trying to make OpenCog code consistent with the conceptual design for OpenCog Prime. I think it's better to take the time to do things the right way than to introduce temporary hacks that explicitly violate the conceptual design (as opposed to hacks that are just quick coding solutions).

Cassio



--
Ari Heljakka
CTO
Dream Broker Ltd		

Tekniikantie 14			ari.heljakka@xxxxxxxxxxxxxx
02150 Espoo			+358 40 568 2420
Finland				www.dreambroker.fi



Follow ups

References