Present : Lee, Tom, Emma

Scribe : Emma

Updates on Collaborations and Lab News

Zeke and Micah busy with Div III work

David Gagne Coming to UMass. Welcome, David!

Lee met with Ranjan Srivastava last week. Recall that possible projects include:

• Modeling biochemical processes with GAs
• Using some form of GP to evolve fabrication recipes for electrodes
• Evolving gyroids.

Also to note : Ranjan’s lab uses Common Lisp.

Discussions with Kourosh Danai and his grad student Bill LaCava

Picked up work with David Clark again

Lee’s Linear Operator work and Tom’s ULTRA work

• Still having issues on calculator problems.
• Right now the problem’s been simplified to single-digit entry
• Problems might lie in the test cases? Tom thinks that we need more test cases and that errors might be propagated by dependencies between the test cases.
• ULTRA not doing the kind of recombination we want – Lee thinks that from the data he’s seen in the runs, we’re not exploring the space the way we would like to.
• Want modularity in the handling of the digits in the calculator problem
• Tom’s suggested: tag space inheritance? His argument is that inheriting code that’s already tagged lends itself to modularity and aggregating genetic change. Lee’s objection is that this messes with the functioning of uniform mutation and has high potential for bloat.
• Another idea is to try out the operators with smaller problems.

GPTP

• Emma and Tom to meet tomorrow to work on a draft. If it seems that this wouldn’t work out for GPTP, will need to punt.

Workshops

• Want a workshop paper on either ULTA or environments
• Lexicase can be an undergrad workshop paper

Present: Lee, Tom (scribe), Emma (hangout)

Next meeting: Not at normal time because of UMass candidate Friday. Stay tuned to email for more info.

Candidate Friday

• Tom and Emma should hang out with our poster.
• Drop off poster by Wednesday. We still need poster board.

GECCO Workshop on Stack-based GP

• We should be submitting something(s) to this.
• Something with the calculator or kata bowling problem may do.
• Something else entirely, such as modularity (esp. of tags), new genetic operators, or environments may be good.

GPTP

• We need to figure out what to submit to this ASAP.
• Something with COSMOS may be good.
  • Need to know by the end of the weekend.

Clojush Refactor

• Can just remove SNAPSHOT.
• Make common.clj one level down, make it available to all.
• Stick with refactored code.
• Linear crossover will be coming soon.

Modularity

• Number of tags may not be a good measure of connection costs, but we don’t have other ideas yet.

Size-based tournaments

• Tom knows what he needs to for working on a journal article.

Talk about paper

talk about linear genetic operators
need to decide on GPTP Topic and authors

Sean Luke’s email about pushing to CJ

tell sean to package it up in whatever form you’ve got it
we talked at length about git

we talked about the paper for a little while

• Present: Lee, Tom, Emma, Kwaku (remotely)
• Scribe: Tom

NOTE: Next week we will meet from 9 to 11 AM on Friday, Feb. 8th.

Clojure Refactor

Emma has recommended some changes to Clojush, including adding command line arguments. We decided to take an incremental approach to making the changes. More information will come by email.

Uniform Crossover

• Why: We think uniform crossover may be useful for a variety of reasons, including to combat bloat.
• Idea: We want the mutability of any one point in the program to be equal.]
• How: Lee has suggested a crossover / mutation technique that allows each point to be taken from one parent or the other, using either zippers or layers.

Other note: Tom suggested using a linear uniform crossover, where each token (parenthesis or instruction or literal) could be chosen for the swap point. This would allow for a variety of crossover and mutation techniques, many of which could be borrowed from linear GAs (one or two point crossover, uniform crossover, etc.). The only downside is that some sort of repair would be necessary to ensure parenthesis matching after the crossover or mutation.

Administrative:

meeting time is returned to 1-3 for next week, but beyond that is up in the air

everyone should let Lee know when we are available in the spring semester, and if not, when we will know

Cluster testing / benchmarking / distributed Clojure:

Should we use a “cloud” clustery thing? … meh

Why isn’t our cluster doing the awesome? We’re not sure, more cores is not appearing to help…

If clooj wont work launch stuff from a comandline with java.jar

Calculator Problem:

selection methods

-these are modal problems, and we need not to avg, but to look at the ones that work well in individual cases

–lexicase selection

–removeing redundant cases

–lexicase with small tournaments to determine which problems are valued

–lexicase which after narrowing down the pool for a correct in one section, will look for other correct combinations

–parito stuff

–start with simple problems and then once they solve you add new aspects to the problems, and you could tie cases together, randomly

–seeding

–lexicase stops the intelligence of evolution regarding prioritizing which part of the problem to chase

operators

-amalgamation

–walks through 2 parents and makes a child that roughly takes what is in the mama or papa or neither or both

-parenthesis adder

–can be added anywhere

-tagger

–randomly replaces chunks of code with a tag and moves that code chunk to tagspace

-if or tager

–makes an if or statement for two tags, and then fills them with random crap in the tagspace

Things to discuss:

• Weighted lexicase selection

Present Scribe: Micah

Present : Lee, Tom, Emma, Ian

Scribe : Emma

IMPORTANT ISSUES

We need to address problems that we aren’t solving but need to be. i.e. Kata bowling and the calculator problem Next week’s meeting is from 10am-noon.

99 Problems

Lee – focusing on case redundancy elimination

If we’re driving evolution with software test cases, there are going to be hundreds of cases that are going to be solved correctly with the current population. Result : cases are never actually redundant.

Solution : grouped lexicase selection? The problem with this is that it’s way too slow.

New idea : GENETICS – this has something to do with Lee’s amalgamation operator.

Program Synthesis

Emma is currently working on implementing Sumit’s string processing grammar and learning algorithm, looking for ways in which we can improve upon it, addressing problems that the current implementation cannot solve.

Statistical Possibilities

We’ve been contacted by some folks Lee spoke with at GECCO. They are interested in our work on new metrics and statistical tests. We discussed paper possibilities, including using the bioavailability data. Thus far no news on the contacts.

Visualisation

• Lee is proposing a visualization project for Ian to work on. The idea is to implement a visual version of push execution state. Previous work was done in processing and incantr. Future work to be done in Quill(?)? The idea here is to have a self-contained project to be incorporated into Clojush.
• Another visualization project would be to show the tag space. The idea would be to have an animation that shows how tags are being used during execution. Lee would like to see both where tags are used in the tag range, as well as which tags are called during execution. Emma suggested using a heatmap to show usage, where the color represents presence of a tag and intensity represents frequency of hits.

Present: Lee, Tom, Emma, Micah (GHangout), Kwaku (GHangout)

Scribe: Tom

Note: If you need jobs done soon, you can send them to Emma to have them done on the UMass cluster.

GECCO Ideas

Here are some things that we can do to try to solve the kata bowling and calculator problems.

Selection

Both Lee and Tom will try out weighted lexicase with tournaments and redundancy test case removal.

Weighted Lexicase

The idea here is to give more pressure toward important test cases.

• Lee’s idea: 2 lists: one random, one sorted “easiest to hardest” by solution rates. Then, 1/2 the time you pick from one list, half the time the other, with removal from both, for the lexicase ordering.
  • Has some problems, such as the “worst” test case getting considerably more attention than the second to “worst” case.
• Tournament-based weighted lexicase:
  • Run tournaments based on solution rates of test cases. This means you select n test cases at random, and then select the test case with the lowest solution rate to go next in the lexicase ordering. Repeat, with removal, over the test cases until all are in the list.
  • Seems reasonable. Both Tom and Lee will try this out.

Clustering / Redundancy Test Case Removal

The idea here is the reduce the importance of similar test cases.

• Lee’s Redundant Test Case Removal
  • Idea: If two (or more) test cases create the same exact ordering amongst the population, then treat them as 1 test case.
  • In initial experiments of the calculator problem, this resulted in some test cases being grouped together in the first few generations, but after that all 34 test cases reacted exactly the same.
  • Same thing happened when only looking at the elite set for each test case.
  • But, these runs were done when not using the measure during selection; we might see different results if we’re using the measure.

Tom thinks other clustering algorithms might also be worth trying, though he agrees with Lee that these might introduce annoying parameters / other issues.

Genetic Operators

Lee has been trying some things:

• Mutation:
  • Tagging mutations – replace some code with a tagged_# call, and put (tag_#) at the beginning of the program.
  • Paren adding mutations
• Crossover:
  • Complementary lexicase mate selection
  • Amalgamation

Instructions

It may be worthwhile to experiment with different instructions / new instructions / combinatorics of instructions.

Present: Lee, Emma, Tom, Kwaku, Josiah, Tom, Omri

Scribe: Emma

Scheduling

• Next meeting – 21st at Lee’s house
• No Meeting on the 28th
• Next Meeting : January 4th, usual time and place

Grant

Submission to an NSF software engineering grant – continue doing what we’re already doing, but with more of an emphasis on introduction to programming problems, rather than agents

Papers

With Kata Bowling not working out, submissions for GECCO are unclear.

Benchmarking

• Josiah wanting to check out price per performance over 5 years for hardware
• Had been making the assumption that multicore machines were improving performance
• Lee’s runs are deterministic; Tom’s are not
• In many cases, multithreaded = hit
• problem seems to be inherent in Clojure
• Josiah is checking out the numbers with a company that designs high performance JVMs

Scribe: Tom

Attending: Lee, Tom, Emma, Josiah

Benchmarking the Cluster

Lots of weird stuff is going on. See emails for more information. Josiah is going to try lein 2, map, and removing parallel garbage collection.

Memory issues on Cluster

We’re getting weird things with out of memory errors. For now, Tom is only going to use racks 1 and 2, which haven’t given any issues.

GECCO Paper Things

COSMOS paper followup is on hold.

Calculator

Lee’s going to try some things to figure this out:

• Weird genetic operators
• Big instruction crutches (like mult_by_10) to see if it can be solved.
• Another big crutch could be taking out all math and see if it’s solved. If not, then there’s something more fundamental going on.
• Maybe try staging of test cases from easy to hard.

Kata Bowling

Tom will try some things here as well:

• Validation set to test near-solutions, to see if they’re close to general or just memorizing solutions.
  • If they aren’t generalizing, it might be worthwhile to do something more interesting with test cases such as changing which test cases are used every (few) generation(s).
• Maybe try bigger instruction crutches here too.

This led to a discussion of burn-in period that could be used before evolution to make sure the initial guys are sufficiently good.

Details

Scribe: Emma Present: Lee, Micah, Tom, Zeke, Kwaku, Emma Reading for next week: None

Agenda

Tom wants to discuss GSXover random code generation and how we can fix it. It might be a good idea to re-skim the emails related to this if you wish to be involved in the discussion.

Lee’s updates

• Funding – current grants, upcoming projects, different directions
• New focus back on the calculator problem, modality, modularity, concepts related to our recent work using GSX, etc.
• number pressing to number, boolean output
• run program once to establish tag space
• map of button to tag (hard-coded) -> each button has a particular tag value
• tagging, boolean, float, exec stacks
• how wrong is it -> need a gradient, rather than 0-1 loss
• due to tag spaces, new genetic operators like “concatenation” might be useful. new one called “amalgamation’
• TODO: investigate tradeoffs between redundancy and modularity (Kwaku’s done much recent work on this)
• refactoring

Micah’s update

Kwaku’s update

<super secret things about modularity>

Tom’s update

• kata bowling runs – searching for consistency in what’s causing some runs to do well and what’s causing some to perform poorly
• gsxover – should we continue working on this? if yes, how can we make it work?
• tom’s recent work has raised the probability of getting something successful

– added scope -> lee suggesting a scope macro/interface -> how to get adfs without explicitly having adfs -> connection with mutation? – changed scope (specific function set for random code in GSX)

Zeke’s update

• validation, things related to the Domingos paper Lee forwarded.
• held up by chemdoodle release delay