# Evolutionary Programming & presentation-format.

## chris glur — 2010-01-11 01:03:23

    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 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'.

## chris glur — 2010-01-11 01:09:25

    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.

## Don Groves — 2010-01-11 01:14:09

    On 10 Jan 2010, at 17:03, chris glur wrote:

     > 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.

     I found it new and enlightening.

     > 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

    >> 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'.

     The goal of "Joy material" appears to be to teach the reader the

    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

    >

    >

    >

## John Nowak — 2010-01-11 02:41:49

    On Jan 10, 2010, at 8:03 PM, chris glur wrote:

     > 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?

     No due to macros, lexical scoping, etc.

    - jn