www lispmeister.com

About

A life with Lisp blog

index | rss2.0 | atom

Author

Products

Order Succesful Lisp directly from bookfix.com


Order Successful Lisp by David B. Lamkins at amazon.de
German Shop: Lisp t-shirt
US Shop: JohnMcCarthy Lisp tshirt

Categories

Links

del.icio.us/lispmeister
bookfix.com
medigist.de
Successful Lisp
lemonodor.com
Foresight Institute
Lawrence Lessig
nanobot
Bill Clementson
FuturePundit
Planet Lisp
Nanotechnology Now
Nanodot.org
Unvollstaendigkeit

Archives

Calendar

Creative Commons License
hacker emblem blosxom

2006/11/03

R.U.Sirius interviews Ben Goertzel

Ben Goertzel

Ben Goertzel, author of The Hidden Pattern and Artificial General Intelligence (both books highly recommended), talks about the Singularity, artificial intelligence, how to be human after transcending and a lot of other wild topics. [via boingboing]

Links:

2006/01/12

Gödel Machines

Gödel Machines Jürgen Schmidhuber, who is one of the directors of IDSIA, wrote an interesting paper titled Gödel Machines: Self-Referential Universal Problem Solvers Making Provably Optimal Self-Improvements.
Given is an arbitrary computational problem whose solution may require interaction with a possibly reactive environment. For example, the goal may be to maximize the future expected reward of a robot. While executing its initial (possibly sub-optimal) problem solving strategy, the Gödel machine simultaneously runs a proof searcher which systematically and repeatedly tests proof techniques. Proof techniques are programs that may read any part of the Gödel machine's storage, and write on a reserved part which may be reset for each new proof technique test. In our example Gödel machine this writable storage includes the variables proof and switchprog, where switchprog holds a potentially unrestricted program whose execution could completely rewrite any part of the Gödel machine's current software. Normally the current switchprog is not executed. However, proof techniques may invoke a special subroutine check() which tests whether proof currently holds a proof showing that the utility of stopping the systematic proof searcher and transferring control to the current switchprog at a precisely defined point in the near future exceeds the utility of continuing the search until some alternative switchprog is found. Such proofs are derivable from the proof searcher's axiom scheme which formally describes the utility function to be maximized (typically the expected future reward in the expected remaining lifetime of the Gödel machine), the computational costs of hardware instructions (from which all programs are composed), and the effects of hardware instructions on the Gödel machine's state. The axiom scheme also formalizes known probabilistic properties of the environment, and also the initial Gödel machine state and software, which includes the axiom scheme itself (no circular argument here). Thus proof techniques can reason about expected costs and results of all programs including the proof searcher.
Seems like Eliezer S. Yudkowsky isn't the only one working on a Seed AI after all.

(thanks Calypso!)

2005/12/02

Accelerating Change 2005: Prospects for AI

Jacobstein-Lincoln-Norvig-Olhausen

ITConversations has a recording of an interesting panel discussion at Accelerating Change 2005 on The Prospects for AI with Neil Jacobstein, Patrick Lincoln, Peter Norvig and Bruno Olshausen.

2005/10/07

Vernor Vinge: Hard Takeoff Video

Five years ago I attended the annual conference for senior associates of the Foresight Institute. One of the speakers was Vernor Vinge talking about the Singularity. I've made a short clip from his presentation available as a Quicktime video [3.4MB]. Vinge's lower margin for a hard takeoff is 36 hours. I'll try to unearth the actual tape of this presentation and make it available online.

2004/07/15

Mozart Programming System

Mozart Programming System

Stefan Lehmke, author and maintainer of the supercool TeXPower presentation system, recommended the Mozart Programming System and the programming language Oz as an ideal platform for building agent based systems (like my conceptual workbench, which is of course pure Common Lisp).

The Mozart Programming System is an advanced development platform for intelligent, distributed applications. The system is the result of a decade of research in programming language design and implementation, constraint-based inference, distributed computing, and human-computer interfaces. As a result, Mozart is unequaled in expressive power and functionality. Mozart has an interactive incremental development environment and a production-quality implementation for Unix and Windows platforms.

Mozart is based on the Oz language, which supports declarative programming, object-oriented programming, constraint programming, and concurrency as part of a coherent whole. For distribution, Mozart provides a true network transparent implementation with support for network awareness, openness, and fault tolerance. Security is upcoming.

I've been browsing through the documentation and I wonder how they expect to build distributed applications, without a notion of capabilities and delegation, like for example provided in the E programming language. Unless I missed something (quite likely), thread synchronization is still difficult (not trivial, like in E).
- posted by Ralph Richard Cook - 2004/7/16 04:51:22
I believe that 'thread synchronization' is achieved the same way it is in the Erlang language, in other words it's ignored. Communication between 'processes' is done via asynchronous message passing. This mechanism is even used as a language idiom in Erlang to simulate object-based programming (not sure how they do inheritance). Another advantage is that communicating with a process on another machine is done exactly the same way as it is on the same machine. I put 'processes' in quotes because in Erlang that's what they're called, but it's not like a heavyweight process (fork) or even a thread, I think they just round-robin it or something. If it sounds slow, don't worry - those guys depend on processes like the Lisp guys depend on lists, so a lot of work has been done to make them fast. An example is the YAWS web server written in Erlang, which can handle 40,000 users at once on the same machine that Apache with threads can handel about 8,000. Er, anyway, back to Oz, I think their concurrency mechanisms are similar to Erlangs.
They are introducing E features - posted by Heiko - 2004/7/16 18:45:25
Hi! The Mozart guys have a project running to introduce such features from E.http://renoir.info.ucl.ac.be/twiki/bin/view/INGI/MILOSProject (sorry for my bad english.)
a comment on thread synchronization in Mozart - posted by Stefan Mandl - 2005/3/11 22:59:43
Threads in Mozart/Oz are handled differently than in Erlang. They use the so-called dataflow semantics of variables, i.e. a variable has two different states: unbound and bound. When a variable comes to life, it is in unbound state and every thread that is trying to access its value will be blocked until some other thread assigns a value to the variable. This value will not change from then on. Variables can be passed around without assigning values to them. Very elegant in my opinion.

2004/06/17

The Role of Raw Power in Intelligence

We're on vacation in Spain and I finally have time to relax, catch up with my reading list and spend some quality time with my lovely wife Nanna and my kids. If you're interested in AI, watching kids will teach you about the difficulty of seemingly simple real world tasks. Like filling, pressurizing, aiming and shooting a water gun. It turns out pressurizing, aiming and shooting is hard wired, while filling the damn thing is almost beyond the capability of a three year old boy. And talking about fun, after a day at the beach, nothing beats a little recreational programming in Lisp and a glass of wine.

Back to the reading list:

Over the last couple of weeks I collected numerous papers in a Read This! folder. This morning I read a paper written by Hans Moravec in 1975 titled: The Role of Raw Power in Intelligence. Thirty years after its publication it's still quite to the point:

The enormous shortage of ability to compute is distorting our work, creating problems where there are none, making others impossibly difficult, and generally causing effort to be misdirected. Shouldn't this view be more widespread, if it is as obvious as I claim?

In the early days of AI the thought that existing machines might be much too small was widespread, but there was hope that clever mathematics and advancing computer technology could soon make up the difference. Since then computers have improved by a factor of ten every five years, but, in spite of reasonably diligent work by a reasonable number of people, the results have been embarrassingly sparse. The realization that available compute power might still be vastly inadequate has since been swept under the rug, due to wishful thinking and a feeling that there was nothing to be done about it anyway and that voicing such an opinion could cause AI to be considered impractical, resulting in reduced funding.

There is also an element of scientific snobbery. Many of the most influential names in the field seem to feel that AI should be like the theoretical side of physics, the essential problem being to find the laws of universe relating to intelligence. Once these are known, the thinking goes, construction of efficient intelligent machines will be trivial. Suggestions that the problems are essentially engineering ones of scale and complexity, and can be solved by incremental improvements and occasional insights into sub-problems, are treated with disdain.

This attitude is a variant of the philosophical notion that all truth can be arrived at by pure thought, and is unfounded and harmful. One wonders what state space travel would be in if the Goddards and von Brauns had spent their time trying to find the universal laws of rocket construction before trying to build space ships. AI needs a stronger experimental base. Like other branches of endeavor (notably physics, aeronautics and meteorology), we should realize our desperate need for more computing, and do things about it.

cute! - posted by mrs lamkins - 2004/6/20 08:09:03
that's a FANTASTIC photo!

2004/04/05

COGENT: Cognitive Objects within a Graphical EnviroNmenT

COGENT is a really nice project that uses a graphical environment for cognitive modelling. It's GNU licensed and the developers provide binary installers for Windows, Linux and Mac OSX. In the backend they use SWI Prolog to do the modelling. The user can do most of the modelling via visual programming and the UNIX/OSX version is scriptable. The book Modelling High-Level Cognitive Processes by Richard P. Cooper utilizes the COGENT environment for it's examples.

2004/03/26

The Importance of Fudgability

Over at kasei threre's a good article about fudgability of software solutions.
In hindsight, we had made several major mistakes - mistakes that seem to be repeated again and again throughout the software industry.

Part of the problem was how arrogant we were. We believed that we could spend a couple of days watching trained lawyers perform a highly-skilled job, talk briefly to them, and then make their jobs completely obsolete.

Worse, we made the job completely non-fudgable. In any human process there's always a degree to which the outcome can be fudged by the person performing the task. Even when the rules are simple or well-understood, there are always cases when someone will have a compelling reason to do things differently. In this case we didn't even know all the rules, and discovered to our horror that there were many more edge-cases than we'd imagined.


(via Lorand Bruhacs)
Arrogant Software - posted by Ascription is an anathema to any enthusiasm - 2004/3/26 22:09:32
I love this quote. Part of the problem was how arrogant we were. We believed that we could spend a couple of days watching trained lawyers perform a highly-skilled job, talk briefly to them, and then make their jobs completely obsolete. - here It resonates nicely with the fun that Clay's been is having tearing into the social software dudes; even if I don't entirely agree with him. When I young I used to go to parties with lots of artists and theater people. They would ask what I did and upon replying that I wrote software a painful silence would follow. I'd sometimes indulge myself by inserting toward the end of that silence the assertion. "My dream is to put an entire city of people out of work!" In reality my dream is to create new cities of people. Don't tell anybody; but a lot of that arrogant social software seems to be doing just that. Who'd a thought, weird huh?...

2004/02/20

Self Adjusting Computation

Via Emery Berger in gmane.comp.lang.lightweight comes a recommendation for this research page by Umut A. Acar. Some of tasty papers there:

2003/12/14

Intel's Probabilistic Networks Library

PGMT Team And here's a photo of the OSPNL development team. And here's Intels introduction to the PNL.