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.
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.
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:
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.
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.
In the meantime however, on to increased functionality.
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.
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.
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.
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.
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