23 June 2017
Worked many evolutionary variants over the past few days. All result in systems that play a halfway decent game, with the potential to capitalize on user mistakes, and often block near-wins by the user. Some will occasionallyguarantee a win by EEXIST, but none are what would be considered "near perfect" (where perfect for tic-tac-toe probably means no loss, and (depending on first move) mostly wins).
There remains some fundamental issues with choosing a good training metric:
The current run uses WIN=2, DRAW=0, LOSE=-2 The idea is that a draw should neither hurt nor benefit our survival (draws are inevitable, but not necessaril desirable). Losses should definitely degrade the score. So the highest score will definitely be the most wins and fewest losses. The number of draws is not directly worked into the fitness measure: only losses and wins (but fewer draws increases the max possible score).
Even though a perfect game player hasn't emerged, the work clearly demonstrates more of what EEXIST is able to do: sequential behaviors based on a variety of input conditions and orders hints at the possibility of controlled, state machine-like configurations. This is exciting!
20 June 2017
57 generations ran in around 27 hours (remote server). Not bad, but the system has (at least) 2 main weaknesses:
Trying a new trainer that checks EEXIST's moves and imposes a penalty when it misses a good move (meaning a chance to win or block.
19 June 2017
Sidebar note: while the evolutionary work is intriguing, it's remarkable that the system can play tic tac toe at all. The gameplay is triggered by injecting chemicals into one region of the system; the system produces chemicals in response, and their location signifies a move. Each move by the opponent is presented as a further infusion of chemicals. That this should play out under certain sets of bias gradients is in itself interesting (to me).
19 June 2017
Ran 50 generations overnight. Best score=201, most scores are around 190-200. Scoring is LOSE=1, DRAW=4, WIN=5. WIth 50 games, perfect score is 250 (impossible since some games are unwinnable). 200 suggests (perhaps) draw as the most likely outcome, and in fact that's what is observed (Gen 51, Individual 0): mostly it forces a draw.
I'm re-running with LOSE=1, DRAW=2, WIN=5. Yes, draws are sometimes unavoidable, but that doesn't mean they should be rewarded on par with a win (otherwise the system may evolve to always draw, as it seems to have been doing). Even with a harsh penalty for a DRAW, the pressure should be on WIN (5 vs 2 or 1).
This system is likely tripped up by an opponent who doesn't always do the obvious. EEXIST doesn't know how to win: so if it has 2 marks in a row and the opponent doesn't block, it may not take advantage and make the winning move. Against a good opponent, it won't have learned that. SO perhaps it needs mixed trining: a good opponent and a random opponent, alternating games?
18 June 2017 PM
I've made a headless version of the system (E6HL) that runs on eexist.org It's comparable in speed to my laptop, but more reliable (no sporadic Windows reboots) and the machine is unused now that the term has ended. It's posting results to a webpage: http://eexist.org/~nick/shared/status.html
18 June 2017
Overnight run only got through 5 generations. Forfeit of first 5 games awards final score of 0 without running remaining tests. This sped up things quite a bit, but forfeits occurring later (say every other game) cause a significant delay. May need a stricter rule: total of 5 forfeits (not necessarily consecutive) could end the test.
Obviously this system is not going to "learn" in the classic sense. It has no idea that if there are 2 marks in a row it should fill in the 3rd square to win (or block). It's just a pattern matcher (yet I still hope that maybe somewhere these are the same?) But it will likely learn better with a stronger opponent. I don't want a full AI opponent, but I'm going to add some mid-level behaviors: single-move winning and blocking.
17 June 2017
Started evolving a tic tac toe plyer (EA6). After 5 gens it is rarely losing. Weird.
16 June 2017
Overnight run of pulse generator had disappointing results: only 90 or so, after around 100 generations. But the code was still pre-setting the karma to 2.0. So I changed it to 5.0 (same as others) and re-started, and after 2 generations it already hit 159. So karma is definitely critical. Is more always better?
Found glitch in earlier attempt to reduce # digits in output file. Fixed, and genome seems to behave consistently with only 3-4 digits after the DP. So the system doesn't seem inherently chaotic as it did before :)
15 June 2017
New evolutionary system is amazing! XOR evolved easily. NAND evolved in 13 generations, with no manual tweaking of the system (initial karma=5). Frequency discriminator evolved an almost-perfect (126142/128000) behavior in only 2 generations! 1st member of 3rd gen scored 127429/128000; but behavior then degraded slightly.
I've modified the Genome class to only (potentially) mutate when mating: the best individuals are preserved without any mutation. This ensures the best individuals(s) always survive (thus the top scores should never drop).
14 June 2017
Re-tackled conservation issue, found and fixed the problem. Karma has an interesting effect now: too much leads to spastic behavior, but so does too little. Re-evolving older circuits, beginning with 3-input XOR.
13 June 2017
Can generate 150 pulses over 1000 ticks.
12 June 2017
Trying to evolve a pulse generator. Several false starts...
10 June 2017
Improved frequency detector for 1000-tick operation.
9 June 2017
Uploaded videos (under the API section ) to discuss and demonstrate current progress in evolvability experiments.
8 June 2017 PM
Evolved frequency detetor: input [0,4] oscillates every 4 or 8 ticks; output [24,28] is 0 for faster frequency, 1 for lower.
Cleaned up EEXIST API code to add cursors to detail pane, eliminate null-pointer exceptions, display x loc vs. bin #, and prevent scrolling below x-zoom=1.
Frequency detector (ea3) includes a delay command ("d msec") for pausing between sim steps. Useful for monitoring how the system develops into its final state.
8 June 2017
The genome is a series of floating point number. I tried re-writing the genome history using only 2 digits after the decimal point, and the circuits no longer behave correctly. Tried 3 digits, still not working. At 6 digits it works perfectly. Is this solution chaotic?
7 June 2017
Evolved 3-input NAND gate. Since the entire system is devoid of chemicals other than the inputs, an input of (0,0,0) will necessarily have no effect. So I've changed the 1/0 setting as follow: INPUT low=5, high=20. OUTPUT: below 10=low, above 15=high
6 June 2017
Evolved a 3-input XOR. Feels like this is pretty easy now.
5 June 2017
Finally evolved a 2-input XOR gate. Bumping the mutation rate to 5% seems to have made a big difference!
21 May 2017
Beginning with gen 20, every 10th gen also uses out-of-band score to control survival/mating.
20 May 2017
Changed input/output regions to match location of each gene (0-4, 4-8, etc.) This seemed to significantly improve evolvability
19 May 2017
Running in-band tests and using score to control mating etc; plus out-of-band tests just to see how they do. Some of the out-of-band tests actually seem plretty close.
14 May 2017
Evolving XOR with random tests: many reach 5600; one reached 6264. Doesn't seem very reproducible. The prior 6400 was probably matching the intended output pattern, rather than responding to input (and was also when both sdFlow and equilibrium were set to true). Questions: - can we re-evolve *without* the inputs changing? If not, what is it responding to? Is it doubling a frequency? - Then, can we evolve more-complex patterns???
22 Mar 2017
Re-worked the EEXIST Code page to better highlight the API. Heading towards a better code dump for sample drivers.
20 Mar 2017
Added links to API how-to videos. Also started Research page.
12 Mar 2017
Added links to the full V1 API including sample code, documentation, and a standalone playground for experimenting with various knob settings. All links can be found on the EEXIST API page.
7 Mar 2017
Initial API uploaded to GitLab
Linked more old software and papers. Cleaned up inconsistencies across pages.
Added a Resources section to the Cell Matrix area. Uploaded and linked numerous papers, slides and references to other work.
Added a NEWS section; modified sections of the Cell Matrix area. Uploaded and linked a pair of videos given at PSU; video of N. Macias' dissertation defense; and approximately 18 hours worth of video from a semester-long Cell Matrix class given at Virginia Tech several years ago.
Initial version of website completed, with some links in place to online resources.