----- Original Message -----
From: "Pei Wang" <[EMAIL PROTECTED]>
To: <agi@v2.listbox.com>
Sent: Thursday, March 29, 2007 1:13 PM
Subject: Re: [agi] small code small hardware
> As I said before, I don't think it is a good idea to allow that
> flexibility. If all the desired changed can be made in the content
> language, why bother to modify the Java code?
Does that mean that 1 algorithm (or a small number of algorithms programmed
in Java) is all that it will take to make an AGI? Will the AGI at some
point not need any modifications to it's Java code to continue to get
smarter and solve new problems? Is flexibility of all kinds bad or just
flexibility that has to do with an AGI producing code?
> I'll need to redesign the system in that case. I know it sounds less
> exciting than "the system will redesign itself", but at least for the
> near future, the latter path will cause more troubles than successes.
Why do you believe this? I am not asking you to change/redesign your system
but just explain the reasons why more choice (in problem solving) is bad.
If an AGI *can* make/change programs, why would they have to use this
facility to redesign parts of itself that might cause a problem?
> I cannot guarantee that. What I'm doing is to add in the algorithms I
> think is necessary, and see what will happen.
>
> Can you guarantee a self-modifying system always makes the right changes?
I can't *guarantee* that I would make the *right changes* if I was working
on your source code! Code is rarely bug free but that doesn't mean that
some coding ability isn't useful for an AGI is it? Changes could be
confined to areas that don't affect it's goals or in test areas. I can see
using code to solve problems that would be difficult or impossible using
data only. I don't think that constitutes changes to *core* areas although
it still means the AGI can change itself.
> The key is not "program vs. data", but "data in one level is program
> in another level". I fully agree with you that an AGI should be able
> to generate and modify algorithms, but it don't necessarily mean the
> source code.
This implies that you believe that some algorithms are "source code" worthy
and others can be made/modified by the AGI. Is this correct? If so, will
the efficiency of the AGI algorithms be substantially less than the ones
programmed by humans in Java? Can you agree that any AGI must be able to
create and use a model to predict something? This condition isn't the only
definition of an AGI, by any means, but would you say an AGI must have that
kind of modeling capability? If yes, then how does a person create and
execute that model with many iterations if the tools available are only
data? If your system was asked to create a model of a line given a Y
intercept and a slope, how would it take a number as input, calculate the
result and display it using data only?
If the above set of questions is walking when you are at the crawling stage,
I understand if you can't answer them. I am really not trying to pick on
you.
My design so far does exactly what you said above. ("data in one level is
program in another level") My language system is programmed in C++ and
can't change itself at all. No AGI code is written in C++, however. The
AGI will be written in only the language created by the C++ so that it can
change/create it's programs. My AGI programs will be considered data from
the C++ programs' point of view. The difference is that my whole AGI
program will be coded in a totally changeable, very high speed language as
oposed to a high speed human created one.
All errors in this internal language are totally trapable (unlike C++) so
that the AGI could actually make programming mistakes without affecting
normal data or concurrent operation.
I am sure you are very busy so don't feel you must respond. If you have the
time, however, your answers might help me a great deal.
-- David Clark
-----
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/?list_id=303
