Shane:
"According to Ben Goertzel, Ph. D, "Since universal intelligence is only
> definable up to an arbitrary constant, it's of at best ~heuristic~ value in
> thinking about the constructure of real AI systems. In reality, different
> universally intelligent modules may be practically applicable to different
> types of problems." [8] <http://www.sl4.org/archive/0104/1137.html>"
>
Ben's comment is about AIXI, so I'll change to that for a moment. I'm
going to have
to be a bit more technical here.
I think the compiler constant issue with Kolmogorov complexity is in some
cases
important, and in others it is not. In the case of Solomonoff's
continuous universal
prior (see my Scholarpedia article on algorithmic probability theory for
details) the
measure converges to the true measure very quickly for any reasonable
choice of
reference machine. With different choices of reference machine the
compiler
constant may mean that the system doesn't converge for a few more bytes of
input.
This isn't an issue for an AGI system that will be processing huge amounts
of data
over time. The optimality of its behaviour in the first hundred bytes of
its existence
really doesn't matter. Even incomputable super AIs go through an
infantile stage,
albeit a very short one.
I would prefer to remain with finite binary sequences for purposes of
discussion, as
I find the introduction of infinity brings a lot of potential for
philosophical confusion.
Are you claiming that the choice of "compiler constant" is not pragmatically
significant in the definition of the Solomonoff-Levin universal prior, and
in Kolmogorov
complexity? For finite binary sequences...
I really don't see this, so it would be great if you could elaborate.
In a practical Novamente context, it seems to make a big difference. If we
make different choices regarding the internal procedure-representation
language Novamente uses, this will make a big difference in what
internally-generated programs NM thinks are simpler ... which will make a
big difference in which ones it retains versus forgets; and which ones it
focuses its attention on and prioritizes for generating actions.
To use another pragmatic example, both LISP and FORTRAN have universal
computing power, but, some programs are **way** shorter to code in LISP than
FORTRAN, and this makes a big practical difference. Even though it's true
that
length(P in FORTRAN) = length(P in LISP) + O(1)
These O(1) contents, that seem so insignificant in abstract theory, can make
a big difference in reality at the human scale...
???
-- Ben
-----
This list is sponsored by AGIRI: http://www.agiri.org/email
To unsubscribe or change your options, please go to:
http://v2.listbox.com/member/?member_id=231415&user_secret=fabd7936
