From: ben goertzel (ben@goertzel.org)
Date: Thu Apr 18 2002 - 10:03:16 MDT
> The most straightforward mathematical definition is "brevity of program
> size", but as I state explicitly, another valuable definition is "brevity
of
> runtime".
Not in the stuff I'm reading... maybe one of your other works? Anyway,
brevity of program size is a special case of brevity of runtime, not the
other way around. This should become clear shortly...
***
I discussed this stuff in The STructure of Intelligence in 1993. I guess I
should be more general about it in the Novamente book.
Neither brevity of prog. size nor brevity of runtime are special cases of
each other, actually. Both are special cases of the general notion of
"simplicity measure" though.
***
> -- similarity defined relative to the knowledge base K defined by the
system
> in question
(Not "similarity" defined relative to the knowledge base K - what would
that
mean? - but "similarity" defined relative to a goal-oriented role. That's
why you need a surrounding AI for the definition to make sense.)
***
But a given AI may have many different goals. In each goal, in each
context, there may be a different goal & context - dependent similarity
measure. This is true. Then the notion of pattern can be applied especially
in the context of that goal/context pair.
***
I think it makes a big difference, in practice, whether you call what
you're
looking for "simplicity" or "useful complexity". It makes a big difference
whether you're looking for a "representation as something simpler" or
"complexity that renders a problem tractable". It makes a big difference
whether you're looking for "similarity", what I would call a correspondence
mapping, or for "utility" in a goal context. These concepts may be related
mathematically but their intuitive surface manifestations are different. So
psychologically there is a definite difference, one that IMHO shows a
strong
surface correspondence with our respective beliefs about how AI should be
pursued.
***
I disagree, I think you read way too much into a difference in verbiage.
The fact that I use a language of "representation" in defining pattern
doesn't say anything about the relevanct of goals and contexts to
Novamente.
I settled on that language in 1990 or so and it may say a little more about
my frame of mind then than about my frame of mind now, also.
***
How can we mathematically define tractability? It will come as no surprise
to any reader of DGI that I want to define it in terms of fitness
landscapes. Suppose that a system S is at a point P within a landscape L,
and you want to get from P to Q. What is the distance between P and Q? One
way is to define "distance" as inversely proportional to the probability of
system S taking the step to Q from P. Another way is to define distance as
the amount of computing power that needs to be expended to get from P to Q.
***
But this latter definition is just the algorithmic infomration of Q
relative to P, where you use both program size & runtime to gauge
simplicity. You're just giving a new word, "tractability", to something
quite familiar.
It's fine if you like your choice of word better, but a new name doesn't
make it a new concept!!
it's not MY original concept either. I think William Bennett from IBM in
the 1970's was the one who started using runtime complexity along with
prog. length in this context
**
"Useful complexity", or complexity that contributes to tractability, is a
pattern that, when added to the system S, tends to decrease the distance
between P and Q. If the pattern decreases the distance between a very broad
range of Ps and Qs, then the pattern might be said to have something to do
with "general intelligence", as above.
**
I( P | Q and R) < I(P|Q)
***
But I will say that when you look at AI from this perspective, it does shed
another spotlight on why AI projects tend to fail. The tractability of the
problem is merely the zeroth step. The manageability of the problem space
is the first derivative. The manageability of the expertise space is the
second derivative. Coding an AI, or an AI modifying itself, is the third
derivative. Strongly recursive seed AI is the fourth derivative. If all
you see of that is the immediate problem, the zeroth derivative, and you
write some piece of code that solves it directly, then naturally you're
going to do a comical bounce off the problem of Real AI - like backing up,
getting a good wind, and running headlong into a thirty-mile wall of rubber
cement.
***
It seems very clear to me that what you are doing is attaching a different
verbiage to some old & familiar ideas.
If you & others find your new verbiage more intuitive, that's great. But
formally, these ideas are nothing new really. They're there in my 1993 book
and they're there in various papers from the alg. inf. theory literature
from the 70's and 80's.
However, I think the ideas are correct, so I'm not going to complain too
much ;->
ben
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:38 MDT