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:-
<ccogan@...> 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 forSo here's his 'top-goal' which achors the rest of the text and gives it
>fitness against samples of the task data, where the task is do something
>like handwriting recognition.
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 aI guess where 'joy' comes in, is that the code must remain syntactically
>small modification of it, such as adding, deleting, or replacing a single
>atom or item in a list, etc. ...
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 ofSo the complete idea is captured in this 1, 2, 3 description; and the
> 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.
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 oneYou've chosen "distinguishing between two values of a variable"
> must start with truly simple versions of the task, such as 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'.
So much for the previous brain-storming.
Let's try some sober design/pseudo-coding.
But first, AFAICS the assumption that the goal can be incrementally approached
[i.e. not a chaotic situation] means that the goal space is continuous, in some
dimensions, in the sense that some syntactic-atoms of the language, might
monotonically change the output over some ranges.
= let the range of 'values' be {0...255} and let this be 'called' continuous.
* then, if for at least some range of some variable: stepping this variable
will monotonically increase/decrease the output, then the goal can be
[partially] approached by stepping this variable - until it reaches a
discontinuity and 'flips' !
= It's difficult to imagine that/how stepping/changing the <control structures>
could be 'continuous'.
= So it looks as if you get a set of disjoint goal-spaces.
AFAI can remember J. Schmidhuber does these kinds of <pre adding human
intelligence> before he runs, and adds human input as guidance between runs.
IMO best results usually are obtained by combined human input to automata.
What are the 'canonical' elements of code and which ones could possibly give
the 'continuity' [attempted to be] described above, so that the goal
of evolution
could be approached [by intelligent hill-climbing] rather than arrived at by
random?
1. control structures : NO.
2. initialised variable/s : some of them might give a 'continuous' output over
a certain range.
3. operators : no continuity can be expected.
AFAICS the above speculation could be tested with the very same automata:
FOR a randon set of codes
Modify/step only one of types {initial values, controlStuctures, operators}
and record the resultant output.
Clearly this is garbage, because controlStuctures and operators canNOT be
meaninlfully ordered, and therefore cannot be 'stepped'.
Let's consider how real Darwinian evolution works?
AFAIKS the 'output' evolves towards its goal, only once the suitable
algorithm/code
already 'exists'. So at that level the code is fixed [proven] and it's iteration
moves the output towards the goal, which has the continuity required for 'hill
climbing', and confirming the code. So all that the feed back does is say "don't
change the code". This is completely different to 'changing the code to get to
the goal'. It's another level of indirection. Or ?
If the path towards the goal has a discontinuity, the code and all the so far
optimistic confirmation runs must be discarded. And I don't see how
knowledge of the
wrong decision/s can be retained to be used for future.
So there's 1: the set of codes which have been tried and failed, and
there's 2: the current 'state'. '2' is a memory but what about '1'.
Well, by Goedel the 'codes' can be ordered, and it they were executed in the
'ordered' sequence, then the automata only needs to know the current Goedel
number to know what code to try next!
So a possible algorithm could be:
FOR Goedel-code 0 till timeOut DO
FOR EACH VAIABLE sweepTheVariable
and use hill-climbing as far as possible to optimise the variables.
But each combination of operator and control-construct gives a new family of
variables.
This is FAR from the original idea of the 'code' hill-climbing towards
the goal !!
== Chris Glur.
I'm posting this to comp.ai.genetic to try to get some answers.
On 10 Jan 2010, at 17:03, chris glur wrote:
> I'm using the subject of Evolutionary Programming as a vehicle toI found it new and enlightening.
> 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:-The goal of "Joy material" appears to be to teach the reader the
> <ccogan@...> 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'.
concepts of Joy via theory and examples. Should there be another?
--
don
> ...
> == 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-li' code.
> The results seem to have been good.
> Right now I can't remember how he 'slices the
> atomic parts of forth-like'.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
On Jan 10, 2010, at 8:03 PM, chris glur wrote:
> I guess where 'joy' comes in, is that the code must remainNo due to macros, lexical scoping, etc.
> 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?
- jn