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.

Updates

Jake

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

Omri

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

Eddie

• Working on Python Push

Frode

• Reading about other evolutionary algorithms.

Bill

• Switching back to a developmental approach

Daniel

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

Topics

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.