[stack] Evolutionary Programming & presentation-format.

I'm using the subject of Evolutionary Programming as a vehicle to
discuss presentation-formatting.

The format & sequesnce of presentation of 'joy material' eg.
on latrobe.edu.au is very strange and frustrating for me.

Rather than only criticize I'll use the post of:-
    <[email protected]>    Mon, Nov 10, 2008 at 4:59 AM
    Title:  Evolutionary Programming
to show show how 'it can/should be done' - IMO.

>The idea is to write a program that writes Joy programs, tests them for
>fitness against samples of the task data, where the task is do something
>like handwriting recognition.

So here's his 'top-goal' which achors the rest of the text and gives it
direction.  It was called 'top down design' in the 70's. In contrast,
when I read 'joy tutorials/material', it's just a mass of unrelated floating
facts, without any unifying goal direction.

>1. A program generator takes as input an existing program and returns a
>small modification of it, such as adding, deleting, or replacing a single
>atom or item in a list, etc. ...

I guess where 'joy' comes in, is that the code must remain syntactically
valid after it's been modified, and joy satisfies this easily - or does it?
Considering lisp, which consists to nested symbolic-expressions: if you
replaced any one s-exprn with another, I guess it would remain
syntactically valid? And I guess that if joy uses concatination instead
of nesting, then it's even easier to replace pieces/s-exprns?
The essence is 'what are the "atoms"' like they are the bracketed
s-exprns in lisp?

> Use this generator to generate a slew of offspring from each of
> the programs, if any, that made it through fitness testing for the previous
> generation.

>3. Execute each generated program on the test data and measure
>fitness basedon the results. Save the programs with the highest
>fitness rating and discard all the rest.

So the complete idea is captured in this 1, 2, 3 description; and the
rest is merely refinement.  Like "hello world" is a complete stand-alone
demonstration, and the rest is merely refinement. There's no need to
hold your breath for 10 pages, hoping to find out what the goal is,
like when I try to read 'joy material'.
-----------
> Sticking closely to the evolutionary paradigm can mean that one
> must start with truly simple versions of the task, such as distinguishing
> between two values of a variable.

You've chosen "distinguishing between two values of a variable"
because it's on the trajectory to your stated final gaol: handwriting
recognition.
writing-recognition <-- distinguishing between finite alphabet.
Notice how I state the goal first, ie. left-most.
IMO code should be written with the design-idea [falsely called the
comment] on the left, ie. first.
--------
Since I can't see what "distinguish between two values of a variable",
means, I'll try to evolve the algorithm here/now:-

"distinguish between two values of a variable" is impossible.
He means "distinguish between two values", possibly
at two different times  -- to a single variable.
Since digital computers have, at the lowest/atomic level,
the ability to (a < b), (a = b), (a > b)..etc. it's difficult to see
how/why one would want to 'evolve' towards this.

So let's try a less-abstract/more-concrete task which
may be in the 'writing recognition' domain. eg.;
"find code which follows a line" in the sense of an ant
following a line of ink & plotting its co-ordinates
while it's progressing.

Apparently this is not the most fundamental task?
What is the definition of fundamental in this context?
What is the general definition of fundamental?
A. perhaps: that other tasks can be composed of it ?

Perhaps the 'algebra of evolution' does NOT have
tasks 'composed of' fundamental/atomic tasks?
Evolutionary tasks may be ordered in complexity, in the
sense that one is likely to be completed before the other.
But perhaps they are not 'additive' or factorisable, in the
sense that if  you evolve a hand and an eye, you are
progressing towards a thing that has hands and eyes.
Because perhaps the hand & eye can't be 'factored';
i.e. evolved independantly ?
....
I suspect that the very concept of "we are making progress,
because we've got a hand and an eye already" is invalid
because ....
Here's a convoluted analogy: I raised 2 topics:
1. why don't ya'all accept and use the software techniques
 which were formulated in the 70s: successive refinement
 ..etc. to explain your theories.
2. an analysis of evolutionary programming.

Now "1" acknowledges the important common mental
 attributes of humans [as evolved]; whereas "2"
 must be carefull NOT to assume that evolutionary
 programming would benefit by eg. decomposition and
 factoring. We humans, use decomposition and
 factoring, to limit the memory required - as determined
 by human psychology. But the genetically evolving
 program has no such requirements.
People can be offended, but tomatoes can't.
The well proven techniques which you should use to design
software and structue your joy-tutorials, and are based
on the evolved nature of human minds, do NOT apply to
self-evolving automata.

So if the final goal is to "recognise writing", how can you
know that this can be divided into sub-goals A, B, C....
Because deciding *that* is taking the decision away from
the automata.   Or ?

== Chris Glur.

PS. You will have read
http://www.idsia.ch/~juergen/evolution.html
http://www.idsia.ch/~juergen/rnnevolution.html
http://www.idsia.ch/~juergen/resilientmachines.html
http://www.idsia.ch/~juergen/metalearner.html
 as I recall he modifies/evolves 'forth-like' code.
The results seem to have been good.
Right now I can't remember how he 'slices the
 atomic parts of forth-like'.