Crossover Results 02/29/2018

Weekly Meeting

Our weekly meeting shed some important light on what needs to happen in this project to continue moving toward our goal of having an exhibit by the end of this month.

Firstly, a brief discussion shed some light on the errors that my program was exhibiting, and allowed for me to fix the crossover function in my code. It now functions as it should.

Similarly, Mutate was adjusted so that it will change a smaller amount of each automata each time.

Generating now occurs continuously when selected, allowing us to actually run the program and leave.

buttons now

Other things that were handled during the week include:

Looking into how printing can be done on campus to help us save costs. During this experiment I printed off two cellular automata and tested pasting them on foam board with two glues: rubber cement & wood glue. I determined that we could manage to print within our budget by doing this, and this was a feasible way to get it done.

Requested the appropriate funding to get this done. This fit within out budget of $100 exactly, although some small supplies like fishing wire might need to still be bought.

A brief 30 minute running of the generation sequence, which gave some interesting results, and let me know what I need to work on for the weekend.

Generation Sequence



Unfortunately, my scoring metric cannot be considered complete. This comes to light due to how the program ended up scoring the above three images. the farthest left had the highest score, of 0.47, the second had a score of 0.44, and the third had a score of 0.33.

Although the color is correct, the best rated is clearly a bad automata, since it has no clear shapes, never mind large and medium shapes.

I edited my scoring metric to not only reward medium and large shapes, but also to discourage small shapes. After running my program again for a little bit I got:

Score: 0.5612573910617795

I also had to go back and re-implement “view best” to actually show the top ten automata and their scores in the database, which I had accidentally re-implemented a different way. It now prints the top ten, and shows the best automata.

It seems the shapes might be forming up nicely, but I will run a longer test this evening.

However, now might be an appropriate time to consider brightness in my color scheme. If colors are similar, we need to differentiate shapes by brightness. This allows us to see shapes even when grayscaled. This has been taken into account, and a test will be run to find a new best automata.

Evening Test

This image scored the best, still pixelated.


This image scored the worst.

Attempts to Fix Scoring Metric

What we do NOT want is these static-y images. They do not at all fulfill the hypothesis for what makes a good image, and should definitely not be coming out the top pick of many generations.

To figure out how to better adjust my metric, I started identifying shapes in my automata to look for patterns on how shapes appear in automatas that are pixelated vs shapely.

As a quick fix for this, I implemented a new piece of the scoring that will simply give a 1.0 if the automata has less than 400 squares, and a 0 otherwise. This is a brief attempt at punishing the pixelated messes that form.

I will run the program overnight and update my blog tomorrow on its progress.

Update** automata0321938279 : 0.5571521983240745

In the meantime however, on to increased functionality.

Functionality Edits

Automatically delete the lowest scores

To start off testing, I created a button so I could call my function on command to delete the lowest scores. This will be removed later on down the line, and happen automatically with crossover and mutation.

kill bad

This was then implemented to automatically delete scores that are not in the top 50, keeping the top 50 in our database at all time.

After confirming it works with the button, I removed the button, and re-implemented it inside Cross + Mut so it will constantly be called while the program generates new images.

Generational Differences

As it stands in my program, you cannot tell when an automata has been generated. Was it generated by crossover in the 5th generation? We don’t really know, since as it stands the automata are put in three folders, and named entirely randomly.

jumbled mess
As you can see, these images are not intuitively organized, and lack any indication of generation whatsoever.

What can I do to fix this problem?

A quick sketch helped me figure out how I might like to implement this file directory.


So now I will go about implementation. First up changing the names to represent crossover or mutation, instead of a file for it. Then, adding a incrementing file path into the program, so that the files create a directory of the generations.

generations complete
Here you can see my idea implemented. I could not use periods because of SQLite query errors, but each automata still stars with the number of its generation. Furthermore, and most importantly, there is a file path for each new generation.


We had a discussion on threads, and here are the notes from that:

Scoring part is so slow

For threads to work, the program needs to export the images first. In a separate function happening at the same time, it needs to loop through and score all the images.

Dynamically make a bunch of image plane objects. This will allow scoring to have an unseen plane to use. We want to score many images at once.

  • Separate Ferrers code into a separate function
  • Test to see if calling it once in the same code where nromally it would get called with imagename it will work
  • Once that is done look into making a separate image pane object

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s