Present: Lee, Tom (scribe), Bill, Omri, Frode

Bill

Discussion of GP stats. Basically, it depends on what problem you’re working on, but something like MBF, computational effort, or number of successes may be what you’re looking for. None of them are perfect, and we’re not sure whether or not Fisher’s Exact Test can be applied to success rates since it may require a number of samples.

Simplification

• Maybe a paper related to simplification of evolved Push programs?
• Tom can do experiments, Lee can write up?
• Even more interesting given context of recent work on semantic genetic operators.

Documentation (Frode)

After some discussion, we decided to try Sphynx for documenting Push (the language), and some sort of automatic tool for documenting Clojush.

WC Problem

• Some discussion of maybe also evolving “front end”/main method of WC program to more closely mimic the utility.
• Tom will try some runs not using no-paren-mut + yes bushy code.
• It may be worth trying some different ULTRA parameters once we know what seems best out of ()-padding/’ultra_padding and no-paren-mut/bushy-code.
• May be worthwhile to try ULTRA with a range of parameters.
  • It may be worthwhile to make this a logarithmic range. Tom’s intuition says yes, but doesn’t have a good explanation yet.
  • Lee will implement this.

Omri Div III

Sounds like it will involve Ventpods!

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.

Meeting Notes

Present: Lee, Tom (scribe), Dave, Omri, Frode

Dave

Dave is moving on 🙁

Frode

Frode will be working on getting used to doing Clojush runs and getting back into writing Clojure code.

Omri

• Omri is trying some things related to using Xerox machines for SIMD parallelism using stacked transparencies.
• Unfortunately, adding new stacks in Clojush for just one example file is difficult, and therefore the easiest thing to do is to just change the global definition of the stacks.

Lee

• ULTRA with many noops. This sounds interesting and potentially useful for allowing evolution to determine the correct amounts of noops.
  • Adding noops effectively increases the alternation rate so that it can be set lower.
  • Tom suggests using a fixed program size to encourage homology.
  • A good project would be to look at evolving populations to see how much homology exists, especially comparing something like ULTRA with normal genetic operators.
• If anyone wants to work on calc or other software projects, talk to Lee!

Tom

• Implemented the change problem, which isn’t as difficult as it first appeared, since it may be possible to do without exec stack manipulations and only integer arithmetic.
  • Tom will try some runs with only integers.
  • Tom is interested in general in doing some sort of Linear Push with ULTRA, which may help with matching instructions that need structure with the right connections.
• Bagging and other ensemble techniques are potentially interesting!

Pre-Meeting Agenda

Things Tom wants to discuss:

• Using ML ensemble techniques to combine solutions from multiple GP runs into single solution
• Feature selection might be useful, especially for lexicase!
• The US Change Problem
  • implemented and started testing
  • no solutions so far, but some very close misses, such as some that miss 2 to 5 cases out of every 25
  • It seems that ULTRA is having a hard time using semantic parentheses for instructions that need them, such as exec_y, exec_if, and exec_do*times.
    • I would be interested in trying some paren-free PushGP, where instruction groupings are somehow baked into instructions that need them. Or maybe, those instructions always start a paren, and only the ending paren can vary.
• I’ve been timing the US Change runs, and am starting to get results as to which nodes of the cluster they are most efficient for.

Lee adds:

• Noops and ULTRA.
• Results for CREST/COW

Present: Lee, Tom (scribe), David, Kyle, Jake, Daniel, Kwaku (he could see us, we couldn’t see him)

Semester meeting time: Wednesdays from 10AM to noon, starting next week.

Lee’s To Do:

• Edit info on website.
• Merge changes into Clojush, including Tom’s pull request and Kyle’s RNG code.

Clojush RNG

Things aren’t too bad, so we don’t have to do anything drastic like redo all of our runs. Kyle’s new code should solve the problem, at least as well as can be done using Java’s RNG.

Lexicase Speed

Tom will try out making error lists into error vectors, which should hopefully speed up lexicase. More news to follow after this has been tested.

FRIGHT Paper

• Uses rule-based evolution for ghost team vs. Ms. Pac-Man
• Uses ECJ!
• Seems related to other rule-based systems and learning classifier systems

Ventpods

• Lee has ideas for making ventpods create waste
• Programming is getting there.

Calc Problem Updates

• Something recently added is helping!
  • Single-digit and double-digit entry tests and single digit math seem to be evolving decently.
• Changes include:
  • Back to regular lexicase
  • Each “test” generates 2 cases:
    • Numerical difference from desired output
    • Levenshtein distance of string to desired string
    • Important to think about fitness function carefully!
    • Also, a meta test case that counts the number of other test cases that aren’t zero
• Many no-ops may be helpful!?!?
  • Homology / ULTRA / ???
  • May want to try some sort of ULTRA with pre-specified or evolved “crossover points”

Lexicase Subset Division (Dave’s Idea)

• Related to spacial co-evolution if we use neighborhoods like trivial geography.
• How to make lexicase faster by using fewer test cases?

Age-Enhanced Lexicase

Idea: make age a test case used in lexicase selection.

• Is one age case enough?
• Other added cases may be helpful!
• Try on other problems?