On Thu, Jul 3, 2008 at 12:59 AM, William Pearson <[EMAIL PROTECTED]> wrote: > 2008/7/2 Vladimir Nesov <[EMAIL PROTECTED]>: >> On Wed, Jul 2, 2008 at 9:09 PM, William Pearson <[EMAIL PROTECTED]> wrote: >>> They would get less credit from the human supervisor. Let me expand on >>> what I meant about the economic competition. Let us say vmprogram A >>> makes a copy of itself, called A', with some purposeful tweaks, trying >>> to make itself more efficient. >> >> So, this process performs optimization, A has a goal that it tries to >> express in form of A'. What is the problem with the algorithm that A >> uses? If this algorithm is stupid (in a technical sense), A' is worse >> than A and we can detect that. But this means that in fact, A' doesn't >> do its job and all the search pressure comes from program B that ranks >> the performance of A or A'. This >> generate-blindly-or-even-stupidly-and-check is a very inefficient >> algorithm. If, on the other hand, A happens to be a good program, then >> A' has a good change of being better than A, and anyway A has some >> understanding of what 'better' means, then what is the role of B? B >> adds almost no additional pressure, almost everything is done by A. >> >> How do you distribute the optimization pressure between generating >> programs (A) and checking programs (B)? Why do you need to do that at >> all, what is the benefit of generating and checking separately, >> compared to reliably generating from the same point (A alone)? If >> generation is not reliable enough, it probably won't be useful as >> optimization pressure anyway. >> > > The point of A and A' is that A', if better, may one day completely > replace A. What is very good? Is 1 in 100 chances of making a mistake > when generating its successor very good? If you want A' to be able to > replace A, that is only 100 generations before you have made a bad > mistake, and then where do you go? You have a bugged program and > nothing to act as a watchdog. > > Also if A' is better than time A at time t, there is no guarantee that > it will stay that way. Changes in the environment might favour one > optimisation over another. If they both do things well, but different > things then both A and A' might survive in different niches. >
I suggest you read ( http://sl4.org/wiki/KnowabilityOfFAI ) If your program is a faulty optimizer that can't pump the reliability out of its optimization, you are doomed. I assume you argue that you don't want to include B in A, because a descendant of A may start to fail unexpectedly. But if you reliably copy B inside each of A's descendants, this particular problem won't appear. The main question is: what is the difference between just trying to build a self-improving program A and doing so inside your testing environment. If there is no difference, you add nothing by your framework. If there is, it would be good to find out what it is. > I would also be interested in why you think we have programmers and > system testers in the real world. > Testing that doesn't even depend on program's internal structure and only checks its output (as in your economy setup) isn't nearly good enough. Testing that you're referring to in this post (activity performed by humans, based on specific implementation and understanding of high-level specification that says what algorithm should do) has very little to do with testing that you propose in the framework (fixed program B). Anyway, you should answer on that question yourself: what is the essence of useful activity that is performed by software testing and that you capture in your framework. Arguing that there must be some such essence and that it must transfer to your setting isn't reliable. > Also worth noting is most optimisation will be done inside the > vmprograms, this process is only for very fundamental code changes, > e.g. changing representations, biases, ways of creating offspring. > Things that cannot be tested easily any other way. I'm quite happy for > it to be slow, because this process is not where the majority of > quickness of the system will rest. But this process is needed for > intelligence else you will be stuck with certain ways of doing things > when they are not useful. > Being stuck in development is a problem of search process, it can as well be a problem of process A that should be resolved from within A. -- Vladimir Nesov [EMAIL PROTECTED] http://causalityrelay.wordpress.com/ ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?member_id=8660244&id_secret=106510220-47b225 Powered by Listbox: http://www.listbox.com
