> BG> "Optimizing the optimizer" is what we've called "supercompiling the
> BG> supercompiler", it's a natural idea, but we're not there yet.
>
> I didn't mean "supercompiling the supercompiler" but rather, "evolving"
> the supercompiler through known techniques such as GA.  I have no idea
> how feasible something like that is...the main attraction I see is
> that -- assuming it can be set up properly -- it can run without human
> intervention (e.g., it even could, with the right PR, be run as a
> SETI-like wide-distribution problem). Obviously, once you've got
> something that works pretty well, supercompiling the supercompiler
> is the next step...

I think evolving the supercompiler is feasible.

The first step toward that would be "adapting the supercompiler."  It has a
lot of parameters, and setting them for a particular program (the subject of
optimization) can be a bit of an art form.  This process could be automated
via an evolutionary or reinforcement learning approach....

Evolving the supercompiler would require representing the supercompilation
process itself inside a powerful procedure learning framework like Novamente
[i.e. like Novamente is intended to be in a little while, because the
procedure learning components are not yet complete].  Because it's a big and
complex program, it would require Novamente's procedure learning aspects to
be working pretty damn well!!

But yeah, this (as I've said before) is my default path to making Novamente
self-modifying & self-improving (& thus launching it on a trajectory of
exponentially improving intelligence).  I don't want to expose Novamente to
its own raw sourcecode, I want to expose it to the mathematical graph
representation of its code as produced within the supercompiler.  Much
easier to think about and reason about, if you're a Novamente instead of
human whose cognition is tied to visual perception and natural language....
The fusion of Novamente and the supercompiler could be a great
self-rewriting intelligent software system.

Of course there are some minor tech obstacles here, e.g. Novamente is in C
whereas the Supercompiler works on Java.  But issues of language porting are
actually small compared to issues of getting Novamente and the Supercompiler
both to actually fully work as desired!!!


> BG> Making a test suite for supercompilation is not as easy as you imply,
> BG> actually.  Testing speedup is easy, but checking that the
> supercompiler
> BG> hasn't introduced subtle errors into the program, is very hard.
>
> I can see where that's the case with real-world modern languages...I'm
> surprised (pleasantly!) to see this idea applied there, rather than in
> (forgot the correct term) "provable" languages and others restricted
> mostly to academia.

Yep.  Fortunately, the folks on this list are far from the only clever
people in the world who are willing to spend their time on projects the
mainstream R&D establishment considers "too far out."  ;-)  Valentin Turchin
(the guru behind the supercompiler) has been doing that for 55 years or so
(he's in his late 70's; he invented Refal, the Russian LISP so to speak, and
in the late 1960's he wrote a book touching on many Singularity and Global
Brain ish notions).  And Andrei and Arkady Klimov, the main tech guys
underlying the supercompiler project, are mighty clever and dedicated.  The
sort of folks that makes one thing there may be hope for us hairless apes
after all ;)

ben g

Ben

-------
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/

Reply via email to