Mobirise Web Site Builder

Songline Systems News

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:

  • If you train against random moves, you don't necessarily learn to take winning moves or to block potential wins, since you might win anyway or the opponent might miss their own winning move. Penalizing for missing a winning move helps with the former.
  • If you train against opponents who always block, or always take a winning move, then the evolved system may fail against a "bad" player who doesn't do such things.
  • If you train against all possible games, there seem to be many local maxima. You might win 90% of the games (and 90% is a great score!) but if 90% of the games are unrealistic because they contain moves made by a "bad" player, you may be losing 10% (all!) of the games played by a "good" (not bad) player.

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:

  • The opponent never makes a bad move (fails to block or fails to win) so EEXIST is never trained for this possibility; and
  • EEXIST may miss a chance to block or win, leading to a loss or possibly to a draw.

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 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:

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

17 Jan 2017

Uploaded and linked to MOD-88 resources; slides from Villanova talk; and book chapter on self-organizing digital systems.

12 Jan 2017

Linked more old software and papers. Cleaned up inconsistencies across pages.

11 Jan 2017

Added a Resources section to the Cell Matrix area. Uploaded and linked numerous papers, slides and references to other work.

10 Jan 2017

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.

8 Jan 2017

Initial version of website completed, with some links in place to online resources.