The bad news
Takens series might have killed my hopes, but it did it before I invested much time
Takens' series are a useful tool for evaluating the quality of randomness. When choosing this method I did know what to reach as a goal, I had a compass, and this compass was filling the space phase uniformely without patterns : f(x) => f(x+1) should not show signs of preference for space. Seeing my tweaked game of life with enhanced self injected entropy converge to a Sierpinsky gasket. Maybe it's not totally bad given I don't know it's lyapounov exponent (aka fractal dimension), but I refuse to let anyone use a method that displays strongly biased entropy in the space phase.
Good randomness for scientific usage or cryptographic one should be evenly distributed. Here is a pertubed game of life, with self injection of « chaos » into itself displaying a Sierpinky Gasket as a strange attractor, followed by a test sample of consecutive deterministric pseudo random numbers which source is the random python's PRNG.
Normally, I can conclude here with : « don't let friends use biased randomness and don't roll your own crypto ».
But I won't : first and foremost I want to higlight that keeping a clear view of what you do is important and knowing fast when you fail is as much postive experience as succeeding slowly.
The good news
The importance of visualisation
Since the beginning of the experiment as a python-tk proof of concept I added a visual interface. Here is the interface :
I added the possibility not only to see in real time the Takens series, but also the non overlapping evolutions of the pertubed game of life with the original one (level of gray coding the discrepancies).
I can testify I detected A LOT OF bugs through this. Manipulating code is easy, and making mistakes even easier. By keeping a view of the initial problem I kept a strong way of checking everything was making sense.
Data visualisation is the second compass with Takens series that helped me save a lot of time to not conclude falsely I made a unique discovery.
python-tk is bearing the load
Every cycle, I communicate back and forth between tk and python, python sending up to 2500 tcl commands in less than 1 second to update de canvas. Just for this it proved useful in giving me trust in the concept.
I was often asked why not tkinter or pure tcl ?
Well, python has data structures such as sets that supports operations that maps nicely with the concepts used in bit arithmetic (xor, and, or ...) that tcl does not have.
In python I can also additionnaly call matplotlib if I want to do 3D scatters or use the very performant numpy arrays. On the other hand, I have experience in Tk/Tcl and have a better grasp of how I deal with GUI in Tk rather than in tkinter. It's a question of comfort not a question of « one best way ». And it was fun to code this way without to much abstractions in the way.
Is the experiment over ?
Yes, it is time consuming.
However, I strongly suspect and would like to check in the future, that the strange attractor in the shape of a Sierpinsky Gasket is due to the symetry in the first neighbours in an hexagonal shape. I would -if I was paid for it explore other kinds of neighbouroud and rules.
For instance we could add a second ring of neighbours and maybe use them as anti-ferromagnetic rules. Maybe I would use random neighbourhood to check if the Sierpinsky gasket disappears .... and so long.
The nice part for this experimentations would be that I have the tooling that is ready.
Annexe the code
The code is available here as a gist on github
No comments:
Post a Comment