From: Eugene Leitl (eugene.leitl@lrz.uni-muenchen.de)
Date: Thu Apr 06 2000 - 20:43:48 PDT
Jeff Bone writes:
> I'm very surprised that Koza is looking at this problem from this angle, if
> that's in fact what your comment indicates. Isn't GP different from the
I should have stated that perhaps less ambiguous. Upon questioning by
moi, he was aware of mutating code brittleness, but, at least
according to his reaction, and despite the admitted handcoded
nonrandomness of the machine instruction mutation function, he sees no
value in making the mutation function part of the population
pool. Maybe he knows something we don't know. I had the impression
grad students (one of which was present) were actually doing all the
grunt work (surprise).
> "shotgunning the bits" approach of GA? IIRC, it's based on mutating a
GP is a special case of GA. Code is data, interpreted by an algorithm,
whether embodied as virtual machine (whether Lisp or Java) or cast in
silicon.
> parsetree-like higher-order representation of a computation, and is therefore
> more abstractly about breeding algorithms (for which the phase space has less
Well, he used to be breeding trees made from SEXPR subset. Now he is
doing more of the same, only with Javur opcodes (JavaVM is a stack
machine, which is probably where the trees come in).
> dimensions?) (At least, this is what I recall from Koza's GP tome. It was
> all about twiddling around lisp-like representations of algorithms, wasn't
> it?)
I am not sure why the phase/state space should have fewer dimensions
with GP. Moreover, a mutation function in the pool would be acting
adaptively, pruning unnecessary degrees of freedom by actively
ignoring them.
My quibble with any higher languages is that they are too remote from
the hardware layer, thus being extremely inefficient. Systems should
mutate machine code (and in future, FPGA and its ilk) directly.
> Nah, the if you just twiddle bits you can do it more cheaply but you probably
> get more crap than if you mutate some higher-order, more abstract
> representation. I imagine the pure-GP approach has better cost / benefit
Which is why I said one has to make mutation function part of the pool.
> characteristics than brute GA. (NB: those terms should actually be
> reversed... GP is more about algorithms, while GA seems to be more about
> programming at the bitstream level.)
You're defining GA too narrowly. GA is darwin in machina, no other
constraints given. Hence GP is a subset of GA. If GA is meanwhile too
narrow, let's call it evolutionary computation.
This archive was generated by hypermail 2b29 : Thu Apr 06 2000 - 21:00:06 PDT