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
- Someone should look into Humies awards to see what makes good GP results.
- 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.
- 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.