Sorry about the late reply. <snip some stuff sorted out>
2008/6/30 Vladimir Nesov <[EMAIL PROTECTED]>: > On Tue, Jul 1, 2008 at 2:02 AM, William Pearson <[EMAIL PROTECTED]> wrote: >> 2008/6/30 Vladimir Nesov <[EMAIL PROTECTED]>: > >>> If internals are programmed by humans, why do you need automatic >>> system to assess them? It would be useful if you needed to construct >>> and test some kind of combination/setting automatically, but not if >>> you just test manually-programmed systems. How does the assessment >>> platform help in improving/accelerating the research? >>> >> >> Because to be interesting the human specified programs need to be >> autogenous, as in Josh Storr Hall's terminology, which means >> self-building. Capable of altering the stuff they are made of. In this >> case machine code equivalent. So you need the human to assess the >> improvements the system makes, for whatever purpose the human wants >> the system to perform. >> > > Altering the stuff they are made of is instrumental to achieving the > goal, and should be performed where necessary, but it doesn't happen, > for example, with individual brains. I think it happens at the level of neural structures. I.e. I think neural structures control the development of other neural structures. > (I was planning to do the next > blog post on this theme, maybe tomorrow.) Do you mean to create > population of altered initial designs and somehow select from them (I > hope not, it is orthogonal to what modification is for in the first > place)? Otherwise, why do you still need automated testing? Could you > present a more detailed use case? > I'll try and give a fuller explanation later on. >>>> This means he needs to use a bunch more resources to get a singular >>>> useful system. Also the system might not do what he wants, but I don't >>>> think he minds about that. >>>> >>>> I'm allowing humans to design everything, just allowing the very low >>>> level to vary. Is this clearer? >>> >>> What do you mean by varying low level, especially in human-designed systems? >>> >> The machine code the program is written in. Or in a java VM, the java >> bytecode. >> > > This still didn't make this point clearer. You can't vary the > semantics of low-level elements from which software is built, and if > you don't modify the semantics, any other modification is superficial > and irrelevant. If it's not quite 'software' that you are running, and > it is able to survive the modification of lower level, using the terms > like 'machine code' and 'software' is misleading. And in any case, > it's not clear what this modification of low level achieves. You can't > extract work from obfuscation and tinkering, the optimization comes > from the lawful and consistent pressure in the same direction. > Okay let us clear things up. There are two things that need to be designed, a computer architecture or virtual machine and programs that form the initial set of programs within the system. Let us call the internal programs vmprograms to avoid confusion.The vmprograms should do all the heavy lifting (reasoning, creating new programs), this is where the lawlful and consistent pressure would come from. It is at source code of vmprograms that all needs to be changeable. However the pressure will have to be somewhat experimental to be powerful, you don't know what bugs a new program will have (if you are doing a non-tight proof search through the space of programs). So the point of the VM is to provide a safety net. If an experiment goes awry, then the VM should allow each program to limit the bugged vmprograms ability to affect it and eventually have it removed and the resources applied to it. Here is a toy scenario where the system needs this ability. *Note it is not anything that is like a full AI but illustrates a facet of something a full AI needs IMO*. Consider a system trying to solve a task, e.g. navigate a maze, that also has a number of different people out there giving helpful hints on how to solve the maze. These hints are in the form of patches to the vmprograms, e.g. changing the representation to 6-dimensional, giving another patch language that has better patches. So the system would make copies of the part of it to be patched and then patch it. Now you could give a patch evaluation module to see which patch works best, but what would happen if the module that implemented that vmprogram wanted to be patched? My solution to the problem is to allow the patch and non-patched version compete in the adhoc economic arena, and see which one wins. Does this clear things up? Will Pearson ------------------------------------------- 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
