9 October 2013

Present: Lee, Tom (scribe), Bill, Daniel, Jake, Karthik, Eddie, Frode, George, Omri

No meeting next week. The following week, Conor and Chris will be visiting our meeting, and will also talk from 4:00-5:30 that day.



  • Working on Push visualization.
  • Div 3: Growth + Animation


  • SIMD and complexity theory
  • Integer sequences and GP
  • Evolving test cases?


  • Working on Python Push


  • Reading about other evolutionary algorithms.


  • Switching back to a developmental approach


  • Div 3: GP + mathematics
  • When will GP solve a problem


Israel Trip

  • Someone should look into Humies awards to see what makes good GP results.

Max-Points Bug

  • ┬áBecause the pushgp argument (max-points) has a different name from the global variable (global-max-points-in-program), the global variable is not being reset when max-points is given as an argument
    • This is a problem for Push instructions that use the global variable to determine if a piece of code is too big to put on the code/exec stacks. In particular, many code stack instructions and exec_s and exec_y use it to limit the size of code on those stacks. Because of this bug, those instructions will limit code to 100 points during execution, even if max-points is set by a pushgp argument.
    • Fortunately, this bug does not affect genetic operators, which use max-points directly when it is passed to the breed function.
  • Tom is going to fix this bug by changing all occurrences of “global-max-points-in-program” to “global-max-points”. He will also check if there are any other name mismatches between global variables and pushgp arguments.

 No-Paren Mutation ULTRA

  • An initial look into no-paren mutation ULTRA looks good using the Change problem.
  • But, since the Change problem doesn’t use semantic parens, we should test it on a problem that requires paren structure.
  • Tom will test it on a synthetic problem that we discussed, which we will, for now, call the “damped oscillator tree” problem, which builds a program that looks like this:
    • (0 0 0 0 0 ((0 0 0 ((0) 0 0)) 0 0 0 0))
    • The problem will (initially) use overlap as the fitness function.

Calc Problem

  • Alternative error measures like Levenshtein distance could be important.
  • Which test cases should we use out of all of them?
    • For now, we want to try using a random subset of all the test cases each generation.
    • This will require validation of seemingly perfect solutions. It may be possible to do this in the problem-specific report.
    • Tom notes that Schmidt and Lipson tried random subsets of test cases in their co-evolved fitness predictors work, and they fared rather poorly.
    • If this works for Calc, we should also try it for WC.


1 thought on “9 October 2013

  1. Pingback: Past Meeting Notes | Computational Intelligence Laboratory

Leave a Reply

Your email address will not be published. Required fields are marked *