Question about atomspace proof of concept

[xylik]

Hi Linas,

today i forked atomspace repository and asked github copilot(LLM optimized for agentic work on github repositories ) to create a simple proof of concept(POC) representation of atomspace in java. If you'll have time just to skim through the generated POC would be great. the POC is small just 14 java classes and one test class.

https://github.com/xylik/atomspace/tree/copilot/fix-fc8e7cc4-3836-48fb-902e-171dd54b713a/java-poc

Here is the main() function with examples of calls:
https://github.com/xylik/atomspace/blob/copilot/fix-fc8e7cc4-3836-48fb-902e-171dd54b713a/java-poc/src/main/java/org/atomspace/examples/Demo.java

Here is the pull request created by LLM which also contains high level break down what was implemented in POC:
xylik#1

Am curious if LLM managed to get the core ideas(API's, some internal mechanics) of atomspace correctly and would you recommend something like this as introduction into atomspace. I choose java for POC because am most comfortable with it but I could have easily asked LLM to generate it in any other language.

Sidenote, I've been watching opencog for years - if it's still alive and read here and there some of your pdf's.

Bye,
Igor

[linas]

I'll make multiple comments, as I poke around. So these are in historical order, not importance order.

One quick comment: you seem to have checked in some binary files, the class files, into github. This is useless; wastes space and adds complexity. From what I can tell, the entire branch target consists of junk.

[linas]

Next: Atom.java.

• Please get rid of custom support for TruthValue -- This are deprecated and need to be trashed.
• Do Not do this.id = nextId.getAndIncrement(); That is a disaster waiting to happen. Terrible idea. Why? Atoms are globally unique: no matter what computer they are on, no matter where, they are the same, if they have the same name/outgoing set. It is impossible to assign a globally unique ID to an atom.
• Node.java get rid of 'unnamed' There can only be one unamed node ever; its a waste of time to test for it.
• Node.java: get rid of appendContent This is a fundamental misunderstanding: the name of a node cannot ever be changed. It is permanent and immutable. Why? Same reason as the ID: Atoms are globally unique: no mattter what CPU's athey are on, they are the same Atom; if you changed the name, it would not be the same atom.
• node.java: factory methods These need to be generic for all types not just some "favorite" ones.
• link.java: indexOf -- impossible; since an atom can appear multiple times, the index is not unique.
• appendContent -- again: Links are immutable and must never change. Otherwise, it turns into total chaos.

[linas]

Next: execution

• private Atom executeLink(Link link) { switch (link.getType()) { This needs to be a virtual function; not a case statement. Mostly because other libraries will define other types, and you will never be able to have a master case statement to handle them all.
• executeTimes -- In general the arguments are vectors and tensors, in the form of Values, and not Atoms.
• Likewise for executeAnd -- in general it will be a bitstring, and it will probably be running on a GPU.
• extractNumericValue -- again, usually a vector or tensor not a number.

[linas]

Pattern Matcher -- throw it away. The implementation is a toy; it will fail in almost all cases, and it will run extremely slowly on the few cases it can handle. Database companies have spent billions of dollars over 50 years trying to optimize this problem, spawning many hundreds of PhD theses.

If you are truly lazy, then write a wrapper around Neo4J or GraphQL or something like that, and at least you'll get something that sort of works-ish but sloww. But we had a student try to do this like maybe a decade ago, and failed, Neo4J was painfully slow back then. I've been told that it still is.

I've been pointed at a Rust implementation that I'm told is hundreds of times faster, but its apparently 50Kloc or more in size. Took a team of maybe 6 people about two years to build it. I have not looked at it myself, just yet.

[linas]

AtomType.java -- the whole point is that types are run-time extensible. They can be added at any time. Thus, some kind of module loading system is needed here.

[linas]

StreamValue.java ... I am currently doing research into streaming, and I do not yet know how to do it correctly. My experimental platform for this is the "sensorimotor" infrastructure, and I am rewriting it from scratch this week. I've deployed this in a few agents, but am not yet happy with the results.

[linas]

I cannot find any actual AtomSpace anywhere. The AtomSpace is a graph database. Where's the database itself? Where are the Atoms stored? It looks to me that as soon as some reference to an Atom goes out of scope, the Java garbage collector will destroy it, The point is that you want to have it stick around for later, when you go to look for it.

[linas]

The meta question is "Well what do you want to do with this when you are done"?

Kind of the point of having Atomese is that you program in Atomese, and not in Java. Atomese graphs are used to describe pipeline flows, and so what you want to ask an LLM to do is to build the pipeline to create that flow. Think TensorFlow or Keras here: the point is to be able to create automated processing systems (described in Atomese) and not to "program in Java". It's a different level of abstraction.

At any rate, I think there's a bunch of cool things that can be done, but you first have to answer the question for yourself: "so what? What am I going to do with this when I'm done?"

Here's one toy project I've been working on. I have like a dozen or more computers and cell phones and USB sticks and backup hard drives and cloud stuff and archive files, and some of these have duplicate copies of files, and some of these have corrupted files. So I started writing a toy demo agent that can crawl all of these devices, try to figure out what files are where, index them, figure out which copies are corrupted, which are good. And just keep track of these. And do the needed repairs, if need be.

Now, I guess I could ask an LLM to write this agent for me (in Java or whatever) but instead, I want to write it in Atomese: just have this little living crawler that pokes around and looks, and makes decisions, and does general maintenance. And so the need to make this work is what is motivating me to do further research into sensori-motor interfaces. Sensory, because it has to "sense" file sizes, timestamps, types, contents. "Motor", because it has to move around while it looks, explores. Where it moves depends on what it saw, and what it remembers. What it "remembers" is it's "world model", and is stored in the AtomSpace. So that's kind of one toy project.

Well, the above is not really what the AtomSpace is supposed to be used for; but, for the things I want to "actually do", I need to have some I/O subsystem, and the sensorimotor stuff is the I/O subsystem.

[linas]

There are several other interesting projects I want to tell you about.

First, if you really really like Java, then creating a Java Abstract Syntax Tree would be interesting/fun. Thus, every Java variable, function, call, code block, if-statement, loop becomes an Atomese Link (variables would be Nodes) Then given any Java, you can compile it into an abstract syntax tree, and store that in the AtomSpace. Similarly, given any Atomese abstract syntax tree, you can then compile it into java bytcode, and run it on the JVM. This would allow Atomese to run on a JVM.

If you are interested in abstract syntax tree in general, but not in love with Java, then it makes sense to rewrite the AtomSpace in pure scheme. This is because Atomese already looks like the declarative subset of lisp; and so you could work it in "reverse" have a scheme/lisp abstract syntax tree that gets stored in the AtomSpace. Again, compiling to bytecode could be interesting.

If you are excited by logical reasoning, then writing a converter to/from prolog would be even more useful. Again, you would work at the absract syntax tree level: Any prolog expression can be converted to Atomese, and vice-versa certain types of "valid Atomese" can be converted to prolog, and then executed there. This would allow you to to run prolog from generated Atomese. There is at least one prolog system that is open source and is very very good. This is a project I've been planning to do myself, for a long time, just haven't gotten around to it.

A variant of that is to use an ASP solver, this is because ASP and prolog use the same syntax. This would allow for fast, crisp reasoning applied to constraint problems. If you do statistical sampling, you could then obtain probabilistic inferencing. That is, if you were thinking of using Atomese for inferencing, this would be one good path to achieve that.