Eugen Leitl wrote: > On Sun, Feb 18, 2007 at 12:40:03AM -0800, Samantha Atkins wrote: > > >> Really? I question whether you can get anywhere near the same level of >> reflection and true data <-> code equivalence in any other standard >> language. I would think this capability might be very important >> especially to a Seed AI. >> > > <snip..> > > However, the AI school represented here seems to assume a seed AI (an > open-ended agent > capable of directly extracting information from its environment) is > sufficiently simple > to be specified by a team of human programmers, and implemented explictly by > a team of human programmers. This type of approach is most clearest > represented > by Cyc, which is sterile.
Cyc was never intended to be a Seed AI to the best of my knowledge. If not it doesn't make a very clear case against seed AI. > The reason is assumption that the internal architecture > of human cognition is fully inspectable by human analyst introspection alone, > and > that furthermore the resulting extracted architecture is below the complexity > ceiling > accessible to a human team of programmers. I believe both assumptions are > incorrect. > I don't believe that any real intelligence will be reasonably inspectable by human analysts. As a working sofware geek these last three decades or so I am quite aware of the limits of human understanding of even perfectly mundane moderately large systems of code. I think the primary assumption with Seed AI is that humans can put together something that has some small basis of generalizable learning ability and the capacity to self improve from there. That is still a tall order but it doesn't require that humans are going to understand the code very well, especially after an iteration or two. > There are approaches which involve stochastical methods, > information theory and evolutionary computation which appear potentially > fertile, > though the details of the projects are hard to evaluate, since lacking > sufficient > numbers of peer-reviewed publications, source code, or even interactive > demonstrations. > Lisp does not particularly excel at these numerics-heavy applications, though > e.g. > Koza used a subset of Lisp sexpr with reasonably good results. It is quite possible to write numerics-heavy applications in lisp where needed that approach the speed of C. With suitable declarations and tuned code generation there is no reason for any significant gap. Unlike most languages such tuned subsystems can be created within the language itself fairly seamlessly. Among other things Lisp excels as DSL environment. What I find problematic with Lisp is that it has been stuck in the academic/specialist closet too long. Python, for instance, has a far greater wealth of libraries and glue for many tasks. The Common Lisp standard doesn't even specify a threading and IPC model. Too much is done differently in different implementations. Too much has to be created or reparented from the efforts of others in order to as efficiently produce many types of practical systems. That I have a problem with. - samantha ----- 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
