The Uhoo Project
The Uhoo Project is very ambitious. I feel it is the first attempt to allow an artificial
life form to exist on its own, purely for its own (albeit at this time unknown)
purposes, independent from human influence and interference. The idea is to develop
a piece of software that provides a template, similar to the idea of the von Neumann
constructor, but without the imposed restrictions.
Uhoo came about by accident. In dire need to flesh out my thesis and sticking to
wanting to develop true artificial intelligence, I looked to the past for examples
of anything that remotely resembled my notions. The figure on the left represents
a data-space constructor, a geometric representation of how data is stored. The
key is that the system knows internally how its information is structured and parses
it as a function of its evolution. That is, there are specific addresses governing
the input and output schemes but how it resolves the data and the compactness--its
resolution--determines the manifest behavior. Granted, there is a lot of
unpredictability by this method, but it serves to get something going that can generate
substantive experimental data.
One of the most significant challenges of this project has been simulating in real
code the expressions of form and function that is Uhoo. I left the last entry with
a note that I was working on the Constructor. This line of inquiry led me to understand
that I could build the constructor to the form:
However, how could this be realized in reusable code? Here, in the above figure,
represents the Uhoo form—initially constructed by the work of three agents—given
to the unique attribute of dataspaces filled to a particular resolution, in this
instance 1. Each dataspace represents one bit in this version. This is only one
face of a tetrahedron but at this time, it is limited to two dimensions with the
only avenue for replication to be the increasing resolution of the dataspaces. So
far so good. The question is: after the agents’ work is completed and the schema
links provided to the compiler, how can this form be realized in a common framework-type
platform such as .NET? Additionally, adding the consideration of how to simulate
artificial life without interference in its growth, where should testing begin?
It is the goal here to submit the code generated here to a physical machine driven
by an ARM-7 32-bit microprocessor suitable for low power applications such as a
mobile robot.
The Creation of the Uhoo Constructor
It all comes down to the how the database is constructed and my insistence that
it constructs it itself based upon given parameters. I want to 'seed' the form,
not scratch-build it. Others far smarter than me had spent countless hours trying
to map environments trying to anticipate how the machine would make decisions that
an infant can. And, after Brooks admitted failure in The New Scientist in
November 2006, I knew I had but one choice--to throw everything I knew away and
start fresh. The irony and paradox tends to confound me often but it seems to me
that if I build the seed and the means of how to go about executing a flavor
of programmatic sequencing, then I was on the right track. Think about the life
of a living organism and try to mimic its behavior in technology, this is where
I'm at now.
The Uhoo Form Based on an Archimedes Conjecture
In thinking about AL, I was wondering what attempts had been accomplished in history.
To reference my query, I understood that autonomy and self-organization, however
forced, would be the identifier of such a machine. I began with the Renissance Era
of Europe and had a look at some interesting renditions. Following that, I went
further back to the Greeks and the machines from the island of Rhodes. According
to Pindar in his Seventh Olympic Ode:
-
The animated figures stand
-
Adorning every public street
-
And seem to breathe in stone, or
-
move their marble feet.
Even though myth, I figure there is at least some fragment of truth to it.