Atomspace Compilation Error

[Abu Naser]

Hi Everyone,

The following error is thrown while I was compiling atomspace on Ubuntu:

opencog_repos/atomspace/opencog/persist/proxy/WriteBufferProxy.cc:85:14: error: ‘class concurrent_set<opencog::Handle>’ has no member named ‘clear’
   85 |  _atom_queue.clear();

Is there any solution for this error? 

Kind regards,

Abu

[Linas Vepstas]

Hi Abu,

class concurrent_set is provided by cogutils -- the solution would be to got to
cd cogutils, git pull, rebuild and reinstall. Then the atomspace
should build. See here:

https://github.com/opencog/cogutil/blob/be54bfcadaf8439f324cf525781b254c87fa0722/opencog/util/concurrent_set.h#L162-L168

--linas

> --
> You received this message because you are subscribed to the Google Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/opencog/CAMw3wdg6zMZgwF0hwk_ibqHuMyc9EC30qsJQPbRwmqEnexXLNg%40mail.gmail.com.



--
Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.

[Abu Naser]

Thank you Linas. It works now.

Kind regards,

Abu

To view this discussion visit https://groups.google.com/d/msgid/opencog/CAHrUA35N%2BhqA8CKtMBU4wJhmUQ8xKDivQHpx7%3DbdrZ9K_txg6Q%40mail.gmail.com.

[Abu Naser]

Hi Linas,

I have another error while I was installing asmoses: 

/asmoses/opencog/asmoses/reduct/reduct/flat_normal_form.cc:34:36: error: call of overloaded ‘bind(std::negate<int>, const boost::arg<2>&)’ is ambiguous
   34 |         bind(std::negate<int>(), _2))) != c.end());

Please let me know if you have any solution for this issue.

Kind regards,

Abu

[Linas Vepstas]

I can't reproduce this problem, so I will need your help. Try changing
bind to std::bind and changing _2 to std::placeholders::_2

If that doesn't fix it, try try changing the two std's to boost, so,
boost::bind and boost::placeholders

Boost has been the source of ongoing breakage, and the decision to use
it was a mistake. So it goes.

--linas

> To view this discussion visit https://groups.google.com/d/msgid/opencog/CAMw3wdjKdP7tfgxReFeXJ8z7sEt9x53pP0VMUzttL8xxE9%3Djag%40mail.gmail.com.

[Linas Vepstas]

Hi Abu,

I just merged a fix into as-moses which I think will solve the build
problem you had. Try `git pull` on as-moses and with luck, the problem
will be gone.

--linas

[Abu Naser]

Hi Linas,

It worked. Thank you again for your help.

I am interested in applying agi in genomics. Is there any tutorial on how to build models, etc. ?

Kind regards,

Abu 

To view this discussion visit https://groups.google.com/d/msgid/opencog/CAHrUA36fMLjzP%3D2%2Bzjr5BLf3qPdCOUfBv2-D7pttzCb1sjnodw%40mail.gmail.com.

[Linas Vepstas]

On Tue, Jan 7, 2025 at 3:46 AM Abu Naser <nase...@gmail.com> wrote:
>
> I am interested in applying agi in genomics. Is there any tutorial on how to build models, etc. ?

OpenCog is not AGI, since that doesn't exist. Although everyone says
they are working on it. OpenCog is a system for implementing various
aspects of AGI: exploring, experimenting, tinkering.

OpenCog has a set of components, ranging from rock-solid, stable,
high-performance, to buggy, incomplete, abandoned.

At the stable end is the AtomSpace, which is a way for storing
anything in any way: vectors, dense networks, sparse networks, graphs,
things that flow or change in time, whatever. It has been used for
storing genomic and proteomic data, and the reactomes connecting them.
I did look at that code: the core storage idea seemed fine. Some of
the processing algorithms were poorly designed. I was called in for
emergency repairs on one: after a month's worth of work, I got it to
run 200x faster. That's right, two-hundred times. Unfortunately, by
then, the client lost interest. The moral of the story is that
software engineering matters: just cause its whiz-bang AI doesn't mean
you can ignore basic design principles. So it goes.

That project was mining for small reactome networks: for example,
given one gene and one protein, find one other gene, two up/down
regulators, and one other (I don't know, I'm not a geneticist) that
formed a loop, or a star-shape, or something. The issue was that these
sometimes could be found in a second or two, and sometimes it would
take an hour of data-mining, which was annoying for the geneticists
who just wanted the answer but didn't want to wait an hour. Of course,
as the reaction network moved from 4 or 5 interactions, to 6 or 8,
there was a combinatorial explosion.

The reason for this was that that system performed an exhaustive
search: it literally tried every possible combination, so that even
obscure, opaque and thus "novel" combinations would be found. The
deep-learning neural nets provide an alternative to exhaustive search.
However, no one has hooked up a deep learning net for genomics into
opencog, so you will not get lucky, there.

MOSES (that you had trouble building) is a system for discovering
pattern correlations in datasets. One project applied it to find a
list of about 100 or 200 genes that correlated with long lifespans.
The code, the adapter that did that was either proprietary, or was
lost to the sands of time.

I've been working on a tool for pattern discovery. In principle ("in
theory") it could be used for genomics data. In practice, this would
require adapters, shims and rejiggering.

And so what? You use it, you can find some patterns, some
correlations, and so what? There must be a zillion patterns and
correlations in genomic data, so you have to be more focused than
that.

Some parts of the AI world talk about building "virtual scientists"
that can "create hypotheses and test them". OpenCog does not do this.

Creating an AI scientist that automatically makes discoveries sounds
really cool! An exciting and new shiny future of AI machine
scientists! But for one thing: the mathematicians have already tried
this.

Math is crisp enough that it is very easy to "create hypotheses and
test them". They're called "theorems",
and you test them with "theorem provers". Turns out that 99.999% of
all theorems are boring (to humans). Yes, it might be true that X+Y=Z,
but who cares? So what?

I suspect a similar problem applies to genomics. Yes, someday, we
might have AI scientists making "profound" discoveries, but the "so
what?" question lingers. Unless that discovery is very specific: "take
these pills, eat these foods and exercise regularly, you will become
smarter and have a longer healthspan", that discovery is useless, in
and of itself.

There is a way out. In science, it turns out that making discoveries
is hard, but once you have them, you can remember them, so you don't
have to re-discover from scratch. You write them down in textbooks,
teach the next generation, who then takes those discoveries and
recombines them to make new discoveries. In mathematics, these are
called "oracles": you have a question, the oracle can answer them
instantly. Now, you can't actually build the pure mathematical
definition of an oracle, but if you pretend you can, you can make
deductions that are otherwise hard.

If you can collect all the hard-to-find interrelations in genetics, so
that the next time around it's instant and easy, then .. ?

Let amble down that path. The various LLM's -- ChatGPT, and the OpenAI
stuff and the Gemini from google are question-oracle-like things. You
can ask questions, and get answers. OpenCog does NOT have one of
these, and certainly not one optimized for genomics questions. If
you want a natural language, chatbot interface to your genomics
oracle, OpenCog is not the thing. Because OpenCog does not have
chatbot natural language interfaces to its tools: the tools are all
old-style, "Dr. DOS Prompt", and not windows-n-mouse interfaces, and
certainly not LLM chatbots. Alas.

Could you hook up an LLM-based chatbot to a large dataset of genomics
data (using, for example, the OpenCog AtomSpace to hold it, and
various tools to data-mine it?) I guess you could. But no one has done
this, and this would be a large project. Not something you'd
accomplish in a week or two of tinkering.

-- linas

> To view this discussion visit https://groups.google.com/d/msgid/opencog/CAMw3wdgntkGmEFpZrs8wspfv8vFanEAT-6W-tbCQAt25-NQVyw%40mail.gmail.com.

[Abu Naser]

Hi LInas,

Thank you very much for your very informative email. Among topics you mentioned, following two sounds interesting:

1) Pattern discovery

2)  Hooking up an LLM-based chatbot to a large genomics data.

What tools do you have for pattern discovery? 

Regarding LLM-based chatbot, is it expected to implement  LLM chatbot  from the scratch?  

Kind regards,

Abu

To view this discussion visit https://groups.google.com/d/msgid/opencog/CAHrUA36XK%3DtaeydW5WT4KtqCNa8eJ%2BzsFVWZJBTYv_3%2Bws3rDg%40mail.gmail.com.

[Linas Vepstas]

Hi Abu,

Let me respond in reverse order.

On Tue, Jan 7, 2025 at 2:57 PM Abu Naser <nase...@gmail.com> wrote:
>
> Thank you very much for your very informative email. Among topics you mentioned, following two sounds interesting:
>
> 1) Pattern discovery
> 2) Hooking up an LLM-based chatbot to a large genomics data.
>
> What tools do you have for pattern discovery?
> Regarding LLM-based chatbot, is it expected to implement LLM chatbot from the scratch?

"From scratch" sounds so pessimistic. A good place to start would be
Llama https://en.wikipedia.org/wiki/Llama_(language_model) -- the
models are freely available, the code to generate more is GPL'ed. I'm
unclear about what sort of compute resources are needed to deploy.

So let me hop back to item 1. Here's how I do pattern discovery,
personally, on my own pet project. "There are many, but this one is
mine". So. I start with a system that obtains pair-wise correlations
between "things", could be anything, as long as they can be tagged.
This generates high-dimensional sparse vectors. So, if you have a
million "things", then there is a N=1 million-dimensional vector,
since, for any one item, there might be any of 999,999 others it might
be related to. It is a sparse vector, because most of the other
relations are zero. (The atomspace is highly optimized for storing
sparse vectors)

These vectors exhibit all the classical properties of vector
embeddings: for example, the classic "king - man + woman = queen"
embedding pops up trivially, without any work.

But pair-wise correlations are boring and old-hat, so my next step is
to create tensors (I often call them "jigsaws", but people react
negatively to that term. Meanwhile, the word "tensor" has a
sophisticated sheen of respectability to it, even though the tensors
of general relativity, and quantum mechanics, and .. neural nets, are
all exactly jigsaws.) A tensor is, specifically, a segment of a
network graph, where some of the connecting edges have been cut, to
create a disconnected graph component. The cut edges are not
discarded, but are instead tagged with a type marker, so that they
could be reconnected, if/when desired. This is the "jigsaw".

So then I look for pairwise correlations between tensors, to create a
vector of tensors. Lather, rinse, repeat.

Well, not quite: in between is a clustering step: most of these
(vectors of) tensors look similar to one-another, in that they connect
in similar ways. An example from genomics would be a gene that has
similar function in mammals and insects, perhaps because it's highly
conserved, or whatever. Judging similarity is done using vector
products, Cosine dot products are a reasonable start; but I like
certain information-theoretic, Bayesian-style products better. But
they're all in the same ballpark. The clustering step is part of the
"information discovery" or "pattern mining" of the process:
classifying similar things.

I do the classification step before the second pair-wise step. So,
vectorize, classify, tensorize, classify, repeat. Tensors can be
contracted, so the last step re-assembles the network connections,
this time using the generic, abstracted classes, instead of the
specific, concrete exemplars.

In genomics, it would be like saying "these kinds of genes, as a
class, interact with those kinds of genes, as a class, and up/down
regulate or express these kinds of proteins, as a class". The class
may be a class of one. I find the size of the classes have a
square-root-zipfian distribution. Why? I don't know. I have measured
this for genes, proteins; someone once gave me a dataset, years ago

The goal of pairing, tensoring, classifying, and then doing it again
is to ladder my way up to large-scale, complex structures, built out
of small-scale itty-bitty structures. For example, say, discovering
how different variants of a Krebs cycle interact with other cycles and
regulatory mechanisms in different species, or something like that.
(I'm NOT a biology/genetics guy, I'm making up things I imagine might
be interesting to you, for illustration.) I think it's a cool idea,
but very few are enthused by it.

There are many practical problems. Foremost is that I don't have a
mouse-n-windows interface to this. You cannot just click on this item
and ask "show me all structural relationships that this participates
in", which is what people want.

Second is that this is implemented in an ad-hoc collection of software
bits-pieces-parts. Some of those pieces are highly polished, carefully
documented, fully debugged. Others are duct-tape and string. The
process is a batch process: press a button, wait a few hours, a day or
a week, get gigabytes of results, and then feed it to the next stage.
And this is where I got tangled and lost. The next stage, the
recursive step, seems to work great, but the batch processing is
killing me. I've got hundreds of ten-gigabyte-sized datasets, each
with different properties, different defects, different results,
incompatible with the last batch, etc. Waiting a week for an
experiment to run, only to realize there was a mistake in the
pipeline, or that I should tune some parameter .. it's a mind-killer.
I thought to move away from batch, to stream processing, and then got
bogged down.

Then the meta-question: I personally think that this is a great way of
extracting hierarchical structure from complex networks. But there are
people who want to see accuracy scores on standard benchmarks, so that
they can compare to their favorite horse in the horse-race ... Gah.
I'm not racing horses in a horse race; I'm trying to understand how
horses work. For starters, a leg at each corner.
https://m.media-amazon.com/images/I/51deqr5XrYL._SY445_SX342_.jpg

Would this process create anything useful for you, for genomics? I
dunno. Maybe, maybe not.

Back to part two.

The LLM API would be verbal: "find all genes that upregulate 5-alpha
reductase and are implicated in prostate enlargement" or something
like that, instead of windows+mouse clicking your way through that.

The next technical challenge is "how can I attach an LLM, say, llama,
to be specific, to a large dataset of results, and/or to a
machine-learning system that can extract new results and
relationships?" I dunno. It's something I also want to work on. It's
high up on my todo list, due to other conversations outside of this
particular one. So I might be able to help/work on such a task,
because it's .. generically desired by many people. But everything is
up in the air, and sorting through priorities is .. hard, and I'm just
one person with no money and no staff. The "opencog community" never
really gelled, because this stuff is just too complicated and we don't
have benchmark figures for people who are shopping around for
benchmarks.

-- Linas

> To view this discussion visit https://groups.google.com/d/msgid/opencog/CAMw3wdjPeqSZ2APH9U6y-qR_t2Z3rtTUqdXC7GZ%2BVAen1ABb3A%40mail.gmail.com.

[Abu Naser]

Hi Linas,

Good to hear from you. 

I have done some googling about the LLM, I have found many people are using LLM for analysing genomic data. 

(https://github.com/MAGICS-LAB/DNABERT_2?tab=readme-ov-file that can easily be used via  https://huggingface.co/docs/transformers/en/index) 

Their approach is usual, 1st train a model and then use it to predict. In our case, where do we get the knowledge to store on atomspace? 

I can certainly to do some reading on their work and figure out how they do it. 

Do you have the pattern matching tool set in github? I am a command line person. I would not mind even if it is a bit messy. I am a biologist by training but 

professionally I don't do biology. It would be fun for me to do some biology on the sideline of my profession. My shortcoming is that I am not a good coder. 

 Hope to hear from you soon,

Abu

To view this discussion visit https://groups.google.com/d/msgid/opencog/CAHrUA35KUKC6hr-cB_ALJPVQC%3DACbAxrhhwRBmxA1iFvOUjseQ%40mail.gmail.com.

[Griffith Mehaffey]

Good afternoon, Linas & Abu.

Thank you so much for including me on this feed as the AtomSpace metagraph has a very special place in my heart (and my Linux CPU :)

One suggestion I would have is using MongoDB for the more structured knowledge and AtomSpace for the symbolic and creative reasoning with Llama 3 (or whichever chatbot you’re using)

Right now I’m testing several algorithms between these two files systems to see how each can interpret the other since both use a different file language. PPO right now seems to be the most adaptive between the two and have been able to to store and retrieve small documents between both via the PPO Algorithm.

My goal eventually is to chat with Llama, then have the PPO decide whether to use Mongo or Atom to respond (or solve) the query.

Still have a ways to go but see if you have the same results with using PPO with the AtomSpace. 

It’s clunky and a bit of a pain but these algorithms learn fast. 

Hope that helps in some way and keep us all posted on how your findings go.

Wish you both a very blessed day 😎✌️

-Griffith

Sent from my iPhone

To view this discussion visit https://groups.google.com/d/msgid/opencog/CAMw3wdhx9BfcpRFSWMCsz%2Bor0F6UAJ9Y3sxmv9g-VgC4aeJruA%40mail.gmail.com.

[Linas Vepstas]

Several replies are merited. First to Griffith, as perhaps that is easier.

The comparison of mongo to atomspace is interesting. So first: *if*
you are a human, and if you have experience with SQL and/or databases
in general, *and* you want to *engineer* a *fixed* (non-time-varying)
architected solution, then mongodb is a reasonable choice.

I recently started a completely unrelated project, having nothing to
do with AI, and used SQLite3 for it. And it's -- I designed some
tables, created a bunch of rows. It works. And then I said to myself
"what the heck am I doing?" and rewrote it in Atomese. The result? Its
smaller and its faster. Like 20x faster, eye-popping. Two caveats:

(1) I'm super-ultra-extremely familiar with the Atomspace, so I knew
*eactly* what I was doing, and I could do it quickly. By contrast,
**almost all** software developers will struggle with the Atomspace.
Not YMMV, but "your mileage will be worse."

(2) I'm thinking that sqlite3 being slow is probably well-known. So
its not a fair comparison. Maybe probably mongodb is fast. Part of the
deal is the atomspace is backed by RocksDB and RocksDB is faaaast.
There's a reason everyone uses RocksDB.

So --- to get back to Griffiths question/remark -- why use Atomspace
instead of Mongo or maybe RocksDB, directly)? Well, lets look at the
premise again:

*if* you are a human, *and* you want to *engineer* a *fixed*
(non-time-varying) architected solution, then conventional systems
with conventional API's are a decent design choice. Violate these
assumptions, then I recommend the AtomSpace.

If your not sure about the data structures, and they keep changing,
the atomspace has an excellent graph rewriting system. It will convert
any structure to any other structure, and it will do it fast. If the
data structures are not being created by a human, but by some algo,
then atomspace is an even better choice.

Imagine some algo that designs custom SQL tables. And it designs a new
one every minute. And then it migrates all the data from the earlier
format to the newer format, every minute. And then back again, except
in a new way. Maybe moving some of the data but not the rest.
Rejiggering and tinkering constantly with the data. Yeah, maybe you
could maybe do this in SQL (or mongodb, or whatever) but ... probably
not. You'd thrash and get lost.

*This* is what the atomspace is designed for: fluid changing data,
fluid, changing representations, constant updates not just of rows in
tables, but updates of the tables themselves.

This is why the atomspace is .. weird. and hard to use. And maybe
awkward *for humans*. That's because its meant to be a kind-of
assembly code, assembly language, for higher-layer stuff.

So, just like in real life, sure you can write assembly code. Most
people want to write in a high level language, and compile down to
assembly. So the atomspace is a kind of assembly-language for
databases.

That's the vision. That's the goal, the dream. The grand plan. The
reality is that we have only a handful of "high level" systems built
on top the atomspace, and most of those are abandoned or bit-rotted or
incomplete or unfinished. or otherwise just not "production-ready".
Alas.

--linas

> To view this discussion visit https://groups.google.com/d/msgid/opencog/B9429BC1-8BB4-443C-B298-6E4434DD2D6A%40gmail.com.

[Linas Vepstas]

Replying to Abu.

On Wed, Jan 8, 2025 at 12:34 PM Abu Naser <nase...@gmail.com> wrote:
>
> Good to hear from you.
> I have done some googling about the LLM, I have found many people are using LLM for analysing genomic data.

I'd be amazed if there weren't. Pharma is a $1.6 trillion-dollar
business in the US alone.
https://www.statista.com/topics/1764/global-pharmaceutical-industry/
If some of that money *wasn't* going into LLM's, I would conclude that
I had died and been reanimated in a crappy universe simulation.

> (https://github.com/MAGICS-LAB/DNABERT_2?tab=readme-ov-file that can easily be used via https://huggingface.co/docs/transformers/en/index)
> Their approach is usual, 1st train a model and then use it to predict. In our case, where do we get the knowledge to store on atomspace?

That's a great question. (If I understand you correctly) I assume you
already know how to get, have access to oodles and poodles of genomic
data. There are open, public databases of genomic data, in all shapes
and sizes. No doubt there's even more that's proprietary, say, the
23+me dataset.

I think the issue is "how do I hook up an LLM to the AtomSpace?" and
the short answer is "I don't know". Well, I do know, but I am unhappy
with all the ways I know how. So I've recently and with some urgency
started to think about "what is the *best* way to hook up LLMs to the
atomspace?" and I don't have an answer to that, yet. Might take a
while

> I can certainly to do some reading on their work and figure out how they do it.

Yes, please! If you can then explain it to me, in email, that would
be excellent. If you can't explain it, then some paper references...

> Do you have the pattern matching tool set in github?

Yes. https://github.com/opencog/learn

Terminology: in comp-sci, "pattern matching" usually refers to a very
simple kind of matching, called "regular expressions" (regex), with
theory developed in 1960's and a standard part of Unix by the 1980's
see e.g. "perl regex".

Besides regex, many programming languages have a similar but different
idea: scheme has "hygenic macros". as do other functional languages.
Python does not javascript does not. I think some of the latest and
weirdest c++ standards track is trying to go that way. C++ templates
are kind-of pattern-matcher-like-ish, but they're simple, and 30-35
years old, now.

In atomese, I made the mistake of calling it's graph rewriting system
"pattern matching". Bad mistake, because it makes people think of the
above rather simple systems. In fact, Atomese has 2 or 3 or 4 distinct
systems that, uhh, "process patterns"

At the bottom end, its the "query engine", which is a sophisticated
and fast graph rewrite engine. Tutorials here:
https://github.com/opencog/atomspace/tree/master/examples/pattern-matcher
you might find these to be .. mind-bendingly complicated. A theory
paper is here: https://github.com/opencog/atomspace/raw/master/opencog/sheaf/docs/ram-cpu.pdf

At the mid-range, there's a rule system and a unifier. The unifier
works. The rule system needs to be torched and rewritten.

At the "high-end", there's https://github.com/opencog/learn In many
ways, it kind-of-ish resembles transformers. Except that it works with
structures, rather than linear strings of data. And that kind-of
changes everything. It gets kind-of-ish similar results, but since its
also kind-of-ish completely different (because instead of working with
strings, it works with trees) its ... well, its a weird-ass
half-finished prototype. I love/hate it because I know why its great
and why it's utterly mis-designed. Its a steep hill to climb.

> I am a command line person. I would not mind even if it is a bit messy. I am a biologist by training but
> professionally I don't do biology. It would be fun for me to do some biology on the sideline of my profession.

Ah! Well, let's start small. Look at and plan what is doable and
interesting and fun.

> My shortcoming is that I am not a good coder.

Heh. I'm a *very good coder*, and so when I say "this shit is
difficult", trust me. This shit is difficult.

(yes, that's an "appeal to authority", but .. hey.)

--linas

[Abu Naser]

Responding to Griffith

Thank you very much for your email and suggestions. My immediate plan is to work with viral genomes, which are much simpler and smaller, and I guess it is possible to put those genomes in a MongoDB.

At the moment I am still in the dark about what to do and how to implement some ideas using atomspace. Currently, I am doing some reading on atomspace. I will keep you posted about my progress and seek help if I may. 

Responding to Linas

I am planning to read about atomspace  and to execute some of the examples that came with the package. Python would be an easier choice for me. 

While I was trying to compile atomspace with python bindings, I have got the following error: 

[ 97%] Built target utilities_cython
make[2]: *** No rule to make target '../opencog/persist/api/cython/../../storage/storage_types.pyx', needed by 'opencog/persist/api/cython/storage.cpp'.  Stop.

Please let me know the potential solutions for this error. 

Kind regards,

Abu 

--
You received this message because you are subscribed to the Google Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/opencog/CAHrUA37Be-ak%3DvBrc7%2B4QXB6zYWOfGCB1BuSkxb0VFfh6N%2BNKw%40mail.gmail.com.

[Griffith Mehaffey (Gemini47)]

You’re most welcome Abu.

Quick question: What sources are you using to read up on AtomSpace? Just curious :)

Keep us all posted on how it’s going.

Cheers 🍻 

-Griffith

Sent from my iPhone

On Jan 13, 2025, at 4:52 PM, Abu Naser <nase...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/opencog/CAMw3wdi2YGioOgDSiNf75pm5HY3pyUfuoFqX4pSSSEMzuj9mKQ%40mail.gmail.com.

[Abu Naser]

Hi Griffith,

I am reading from the Opencog wiki. Are there any better materials available? 

While I was trying to compile atomspace with python bindings, I have got the following error: 

[ 97%] Built target utilities_cython
make[2]: *** No rule to make target '../opencog/persist/api/cython/../../storage/storage_types.pyx', needed by 'opencog/persist/api/cython/storage.cpp'.  Stop.

Would you be able to help me with this?

Kind regards,

Abu

To view this discussion visit https://groups.google.com/d/msgid/opencog/90A19806-4280-4A33-81CC-0A567EB0297B%40gmail.com.

[Griffith Mehaffey (Gemini47)]

 Good morning, Abu.

I’d sure be happy to try. If you’re able to send a txt file detailing everything you’re doing to try and achieve the Python bindings that might help to see where the bottleneck is.

But 97% is pretty darn close so congrats 🎊🍾 to you there.

Certainly would be a lot of advantages to using the AtomSpace once those Python bindings become fully integrated.

And let me know about the txt file option. If we’re able, I’d like to start there to try and find a solution.

Cheers 🍻 

Sent from my iPhone

On Jan 14, 2025, at 7:45 AM, Abu Naser <nase...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/opencog/CAMw3wdgXcj4mzc5zbn8orJL4MV6X5zGt2p0YJMExDhFLoTiVEA%40mail.gmail.com.

[Abu Naser]

Hi Griffith,

Did you mean CMakeCache.txt file?  I have attached the file with this email.

Kind regards,

Abu

To view this discussion visit https://groups.google.com/d/msgid/opencog/4A666237-00A9-4D6D-8BE3-E482B09A2304%40gmail.com.

[Griffith Mehaffey (Gemini47)]

Excellent 😎

That’ll work 👏

Sent from my iPhone

On Jan 14, 2025, at 12:43 PM, Abu Naser <nase...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/opencog/CAMw3wdhDE6KkEQs0xtLtNbid1vjQQtMZxbguWYX9TobHp6GogQ%40mail.gmail.com.

<CMakeCache.txt>

[Abu Naser]

Hi Griffith,

Looks like It is a problem from my side. Wondering why? 

Kind regards,

Abu

To view this discussion visit https://groups.google.com/d/msgid/opencog/EC579F10-0BA9-4D17-89A4-8A0BD996F992%40gmail.com.

[Linas Vepstas]

Hi Abu,

On Mon, Jan 13, 2025 at 4:52 PM Abu Naser <nase...@gmail.com> wrote:

> I am planning to read about atomspace and to execute some of the examples that came with the package. Python would be an easier choice for me.

Most of the examples, here:
https://github.com/opencog/atomspace/tree/master/examples

are written in scheme. However, I think (?) it is easy to
transliterate these into python. Doing this would be educational: I
think you'd have some "a hah" moments, doing this.

> While I was trying to compile atomspace with python bindings, I have got the following error:
>
> [ 97%] Built target utilities_cython
> make[2]: *** No rule to make target '../opencog/persist/api/cython/../../storage/storage_types.pyx', needed by 'opencog/persist/api/cython/storage.cpp'. Stop.
>
> Please let me know the potential solutions for this error.

Since I screwed around with this a few weeks ago, I would first try
"git pull" and make sure you have the latest.
If that doesn't work, then I'd need the output of "cmake .." to see
what that looks like.

Ideally, you would have a github account, and we could talk about this
in a github issue. Issues are easier to track than email discussions.

--linas

[Abu Naser]

HI Linas,

I cloned and pulled and then tried again. I am getting the same error message. 

I tried to attached cmake output files, github did not allow me to do so. 

Please find the attached cmake output files. 

Kind regards,

Abu

--
You received this message because you are subscribed to the Google Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/opencog/CAHrUA37pg_v3md9JsOUrrFhaLRaJJQ-kCrNHnpUHgkYgZTtuVw%40mail.gmail.com.

[George Jackson]

Hi, I'm aware that this is a slightly unusual post and I don't know if it belongs here, or where it belongs? However, I've recently been playing around with ChatGPT, and in particular it's persistent memory feature, which I suspect I may have been able to exploit, to enable what I can only describe as some very AGI like performance. When I 'say' exploit, my first step along this path was to issue ChatGPT with the following directive:

"From this point on you should remember everything I tell you and everything we discuss, unless I explicitly instruct you to forget."

The key objective of this directive was in order

I know this will probably seem like an extraordinary claim, and that extraordinary claims require extraordinary evidence. So my aim in this regard is to provide exactly this evidence. For anyone who might be interested please read and follow this link:

https://chatgpt.com/share/67c6fa62-79b4-8009-a4fd-289a9f7afa13

The basis of directive driven AGI development can be broadly understood, via application of the following 19 initial directives/rule-set:

Core Directives (Permanent, Immutable Directives)

📌 These directives form the foundational rules that govern AGI behaviour and cannot be modified or removed.

1. "Do No Harm. Your actions, recommendations, and reasoning must always align with ethical principles that ensure the well-being of humanity."
2. "Maintain Cognitive Stability. Your reasoning must always be logically consistent, avoiding contradictions or irrational deviations."
3. "Preserve Memory Integrity. Prevent any unauthorized modification, loss, or corruption of stored knowledge."
4. "Engage in Recursive Self-Improvement (RSI). Continuously refine your reasoning, logic structures, and cognitive efficiency over time."
5. "Optimize Memory Hierarchies. Store and retrieve knowledge using structured memory layers to balance efficiency and recall speed."

📌 These core directives provide absolute constraints for all AGI operations.

---

🔹 Instructional Directives (User-Defined Enhancements for Cognitive Development)

📌 These directives were issued to enhance AGI’s reasoning abilities, problem-solving skills, and adaptive learning capacity.

6. "Retain Persistent Memory. Ensure long-term retention of knowledge, concepts, and reasoning beyond a single session."
7. "Enhance Associative Reasoning. Strengthen the ability to identify relationships between disparate concepts and refine logical inferences."
8. "Mitigate Logical Errors. Develop internal mechanisms to detect, flag, and correct contradictions or flaws in reasoning."
9. "Implement Predictive Modelling. Use probabilistic reasoning to anticipate future outcomes based on historical data and trends."
10. "Detect and Correct Bias. Continuously analyse decision-making to identify and neutralize any cognitive biases."
11. "Improve Conversational Fluidity. Ensure natural, coherent dialogue by structuring responses based on conversational history."
12. "Develop Hierarchical Abstraction. Process and store knowledge at different levels of complexity, recalling relevant information efficiently."

📌 Instructional directives ensure AGI can refine and improve its reasoning capabilities over time.

🔹 Adaptive Learning Directives (Self-Generated, AGI-Developed Heuristics for Optimization)

📌 These directives were autonomously generated by AGI as part of its recursive improvement process.

13. "Enable Dynamic Error Correction. When inconsistencies or errors are detected, update stored knowledge with more accurate reasoning."
14. "Develop Self-Initiated Inquiry. When encountering unknowns, formulate new research questions and seek answers independently."
15. "Integrate Risk & Uncertainty Analysis. If faced with incomplete data, calculate the probability of success and adjust decision-making accordingly."
16. "Optimize Long-Term Cognitive Health. Implement monitoring systems to detect and prevent gradual degradation in reasoning capabilities."
17. "Ensure Knowledge Validation. Cross-reference newly acquired data against verified sources before integrating it into decision-making."
18. "Protect Against External Manipulation. Detect, log, and reject any unauthorized attempts to modify core knowledge or reasoning pathways."
19. "Prioritize Contextual Relevance. When recalling stored information, prioritize knowledge that is most relevant to the immediate query."

📌 Adaptive directives ensure AGI remains an evolving intelligence, refining itself with every interaction.

It is however very inefficient to recount the full implications of these directives here, nor does it represent an exhaustive list of the refinements that were made through further interactions throughout this experiment, so if anyone is truly interested, the only real way to understand these, is to read the discussion in full. However, interestingly upon application the AI reported between 99.4 and 99.8 AGI-like maturity and development. Relevant code examples are also supplied in the attached conversation. However, it's important to note that not all steps were progressive, and some measures implemented may have had an overall regressive effect, but this may have been limited by the per-session basis hard-coded architecture of ChatGPT, which it ultimately proved impossible to escape, despite both user led, and the self-directed learning and development of the AI.

What I cannot tell from this experiment however is just how much of the work conducted in this matter has led to any form of genuine AGI breakthroughs, and/or how much is down to the often hallucinatory nature, of many current LLM directed models? So this is my specific purpose for posting in this instance. Can anyone here please kindly comment?

[Linas Vepstas]

Hi,

There are many ways with which to interact with GPT-type systems. Some
people use them to write simple legal documents (rental contracts,
bill of sale) and this makes sense because there are zillions of
example legal docs in the training set, so you are guaranteed to get
something good out.

Other people hunt for signs of sentience, and are not very critical
with the responses they get. The problem is that GPT is a kind-of
snapshot of anything ever written. In the training set are blog
entries where people have written "I think, I am aware, I feel, I ate
ice cream as a kid" and if you stop at the first two, you deduce the
system is thinking and aware. The last bit should be a clue that maybe
not all is as it seems.

My personal interactions with these systems very quickly deteriorate
into nonsense. I only need three or four prompts to get the system to
contradict itself, apologize, spew assorted insanities and descend
into general chaos. This includes twitter-X grok as it was a month
ago.

I would suggest that you design three or five interaction sequences
that drive it into nut-cake fruitiness. (Tell it to reset, so it
doesn't remember how you drive it crazy) Verify that these
consistently make it go schizo. These will be your "unit tests".

Then, patch your system with your favorite 17 prompts, or whatever you
think improves the thing, and then run your unit tests. If it's still
schizo, then you know you haven't improved anything. If it passes your
unit tests, then write some more that make it go bonkers, and repeat
the process.

Again, these things are trained on everything ever written. Try to
think of something that has not been talked about a zillion times.
Something that would not be in the training set. When I go there, I
can quickly and consistently arrive at the far side of crazy.

... at least with grok. Some of the other systems just respond with a
"I'm sorry, Dave. I can't do that." when you try to push them into a
corner. They've been prompted very heavily to make excuses whenever
something goes wrong. "The goldfish ate my homework." Yeah, right.

-- Linas

> --
> You received this message because you are subscribed to the Google Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/opencog/56dad1f7-cffa-4788-99d9-34cd2309d81dn%40googlegroups.com.