Recent changes to bloghttp://sourceforge.net/p/smoothlife/blog/Recent changes to blogenSat, 01 Dec 2012 12:33:55 -0000relativistic SmoothLife, 2ndhttp://sourceforge.net/p/smoothlife/blog/2012/12/relativistic-smoothlife-2nd/Hello all,
so regarding relativistic SmoothLife, I had this idea:
In non-relativistic SmoothLife we integrate over two subsets of Euclidean space, the disk and the ring, with radiuses defined according to a Euclidean metric dr^2 = dx^2 + dy^2.
If the time dimension were also Euclidean we could simply extend the integration to all past times with "time radiuses" defined according to a metric dr^2 = dx^2 + dy^2 + dt^2.
This means we would integrate over two half balls (one with a hole in it). But we could not "rotate" in the time direction, there would have to be a preferred frame of reference. Even if we could rotate, causality would be confused anyway, so to keep everything in order, time has to be hyperbolic. That's why the relativistic metric is dr^2 = dx^2 + dy^2 - dt^2 (or dr^2 = dt^2 - dx^2 - dy^2). But still, maybe for non-relativistic SmoothLife this half ball integration scheme could be fun to try out.
For relativistic SmoothLife we would integrate over two subsets of the past lightcone to get our new state. One with r<r_i and one with r_i<r<r_a, with all r's defined in the relativistic metric. A kernel of this form then should be invariant under Lorentz transformations, including boosts.
Another way to think of it is: integrate over all events that can reach the now in time t_i or less from the past, and over all events that can reach in t_i<t<t_a. With a finite, constant speed of information propagation that is the same in all reference frames.
I'm not quite sure at the moment, however, how such a kernel would look like, or how to program a simulation of it, or if it would be possible to find gliders in such a simulation. But it's fun to think that it could work, anyway.
The nice thing is: if it doesn't work, we could think of something else. Because the one thing we never run out of is ideas. But until this hasn't been tried out, it is unclear whether we have to think of something else or not. So, the motivation to try it, isn't really to see if it works, but if we can finally stop thinking about it.
Why do I have to do everything on my own, even the WELTFORMEL !!!?
SmoothLife with delayed time (see the SmoothLife DT video on my youtube channel) did something similar, but it did not integrate over all past events, just the ones lying on the flat kernel and reaching the center at a certain time. This kernel can be depicted fairly easily: it's just the surface of the tip of a "past lightcone". But of course in a non-relativistic sense, and so it is not Lorentz invariant.
ionreqSat, 01 Dec 2012 12:33:55 -0000http://sourceforge.netf62a22211061662a579154a72eeedf928a185b0frelativistic SmoothLifehttp://sourceforge.net/p/smoothlife/blog/2012/06/relativistic-smoothlife/Idea alert! Wouldn't it be nice, if SmoothLife were Lorentz invariant?
Like Konrad Zuse said in his paper "rechnender Raum" (calculating space), the first objection from physicists against cellular automaton based physics is always, that it isn't Lorentz invariant. But then, he says, we have to think of ways how we could MAKE it Lorentz invariant, and not simply write it off. See, that's the attitude I like. Maybe now with the SmoothLife model where we have a PDE, and no grid (at least theoretically), this would help to make a step in this direction.
So the question is: how can an equation of the form
d_t f(x,t) = S f(x,t) (1)
be made Lorentz invariant?
Well, here is one idea, I had: think of the Maxwell equations where we too have an ordinary time derivative on the left hand side and something else on the right hand side. So what's the trick, why are the Maxwell equations Lorentz invariant, and (1) is not? The trick is that we have another Maxwell equation with a time derivative on the left hand side and a different "something else" on the right hand side. And these two "something else"s can transform into each other! So maybe if we replicate this structure we could get Lorentz invariance. That was my idea today. We would have something like
d_t f(x,t) = S g(x,t) and
d_t g(x,t) = T f(x,t)
i.e. two fields instead of only one. And maybe two different nonlinear operators. (But maybe as well only one, who knows: S=T ?) Maybe we would have to make f and g complex or vectors. But we would still get gliders with the right nonlinear operators S and the right values for the snm function. Maybe these gliders then would have a phase just like photons. Imagine that, gliders with a phase! You think I'm crazy? Well, actually there's a whole chapter in a book already about this topic: "Game of Life Cellular Automata" (Adamatzky). They look at a quantum mechanical phase for the cells of a cellular automaton. But relativistic cellular automata? Has anyone ever considered this?
AS you know, SmoothLife on a sphere works, as there is a metric involved. It can be used for correcting the distortion of square arrays when projected onto a sphere. This underlying metric could be coupled to the field. Or to emphasize it more: it could be MADE coupling to the field. So this sounds like general relativity even. This gives me hope somehow that there could be something going in this direction. There could be length contraction of the disk and ring kernels for example. In case of something moving with the speed of light these shapes could even be flattened, i.e. have one dimension less, and still be meaningful, as you can see with SmoothLife working equally well in 3D, 2D and even 1D.
So, all in all, for me, there are so many tantalizing hints that it could work, that I just can't stop thinking about it. But, as always, having the idea is the easy part. Now there would be some work to do. And I have done nothing as of yet, I'm just talking out of the blue here. I'm feeling a bit tired. There are so many other things to do, so many other ideas.
ionreqFri, 22 Jun 2012 02:38:17 -0000http://sourceforge.netb256370469c670df3eaea83d9e8a4a02448b669bmodifying snmhttp://sourceforge.net/p/smoothlife/blog/2012/05/modifying-snm/Just had an idea how to modify snm in an interesting way, in order to get "the good stuff back" from GoL. What if we take our usual snm and put a filter over it, letting through only the stuff at integer positions and setting to 0 the stuff in between?
So, for instance one could define a 2D gaussian bump at positions n,m in snm such that if we take
(gaussian(3,0) + gaussian(2,1) + gaussian (3,1))*snm
we would get the GoL rules in a smooth way. Of course the widths of the gaussian would have to be adjusted.
Or we simply could set to 0 all stripes between integer locations. We would have 8 such stripes in the n direction and one in the m direction. Of course again in a smooth way, not with hard steps. Maybe we even could use a sine function for this.
Just an idea. I haven't tried it, and probably won't in the near future, because I'm a bit fed up with SmoothLife right now. But that's normal, don't worry. My love for it will come back, and then there will be a bunch of new stuff implemented. That's how it has always been. Can sometimes take years...
ionreqTue, 08 May 2012 12:58:59 -0000http://sourceforge.net3a5a0394804ffef71b0f96498b099ca938b501ceglider constructorhttp://sourceforge.net/p/smoothlife/blog/2012/04/glider-constructor/In my presentation I listed the idea of a glider constructor as a "research topic". When I put this up it was true, but then I implemented it not long afterwards. The reason was, that I was searching for a 3D glider then, and I wanted to be able to draw a shape that I had in mind and see if it works, at least approximately. The point is that I didn't want to draw the whole shape, but only one half of the profile. The rotational symmetry then would be calculated automatically and give the whole 3D glider.
So I wrote a little FreeBasic program where I could draw, calculate the 3D shape, and then let it run the time steps. But it soon was clear that I wouldn't be able to draw a shape that is stable. The thing always blew up over time, even it had made a few steps at the beginning. I wanted to know why and what was going on, so I did what I had had in mind anyway: implementing the glider constructor and constructing and displaying of the snm function.
Programwise this is no big deal: just let an array represent the snm function and set values in it according to the shifted glider. Of course it turned out that with a low resolution of this snm array there are many collisions: certain (n,m) pairs occur multiple times over the glider, at least approximately, and are then rounded to the same array location. This is no problem if the snm value at this coordinate is the same for all the occurances. But it leads to a problem if it is not, because then you can't decide to which of the two values snm to set to.
Explicitly in the program I did it as follows: the snm array is initialized with 0.5, displayed as grey. The glider is drawn in white (1) on a black background (0). So when the calculation of snm is finished and it is displayed, there are white and black dots on a grey background. The points where collisions occured are marked in red. I increased the resolution of the snm array and then it turned out that I really can draw a glider and let it run, even if the snm array looks rather chaotic, i.e. with many black and white dots mixed in wide areas. I also could confirm that with the generic smooth glider shape, this is not the case. There the black and white dots are nicely seperated. They would have to be of course, because the snm array that should come out in that case should simply look like our generic four parameter sigmoid snm function, like we have defined it in all our SmoothLife programs. There the 1 and 0 areas are seperated after all.
So, arbitrary glider shapes are not really possible, because of areas in snm where black and white dots collide. But the glider constructor is nonetheless useful, because the interesting thing now is: we can draw different glider shapes and see if we potentially would be able to define an snm function that generates them. The only property that they should have is seperated white and black areas. In the main program there would be a way to let snm be an array, transfer the calculated snm array from the glider constructor and see if it is really generated and runs.
Check it out in the FreeBasic directory!
Use it like this:
Draw a glider in the black square, then press space.
It will calculate the snm array and show the collisions (the little red dots can be hard to see).
The number of collisions is also displayed below it.
With zero collisions your glider should then appear below the original one.
With collisions you should see it blow up, i.e. see the square become more and more grey.
Press space again and you are again in drawing mode.
Now you can modify your glider, e.g. fill little holes or smooth the outline.
Then press space again to see if it has less collisions and how the areas where black and white dots are mixed have in- or decreased in size.
Or you press w or s to set a speed for your glider.
This of course leads also to a different snm array.
It can happen that with speed 0 there are collisions and with a speed >0 there are none.
Remember that the correct size for a glider also depends on the kernel size, i.e. the outer radius.
As a default it is set to 12 in the program, so your perfect glider is somewhere around 24x24 pixels in size.
ionreqFri, 27 Apr 2012 13:29:43 -0000http://sourceforge.net1600d815e32b23e2ea00b2c50c08c021c9af4b79additive transition function, new smooth time stepping mode (fail)http://sourceforge.net/p/smoothlife/blog/2012/04/additive-transition-function-new-smooth-time-stepping-mode-fail/Concerning the search for the generic smooth time stepping mode, I came up with an intriguing idea today which nonetheless failed, as of yet. Remember that like in the original GoL for SmoothLife with discrete time stepping we consider snm the new function value for each time step. So for snm to be an additive value one has to consider the analog in the original GoL first! That was my idea today. I haven't tried it explicitly, but it is straightforward. Just imagine instead of setting cells to 0 or 1, subtracting or adding 1 appropriately. These would be the rules of additive GoL:
- if a cell is 0 then add 1 if it has 3 neighbors
- if a cell is 1 then subtract 1 if it has less than 2 or more than 3 neighbors
(leave it as it is in all other cases)
Unlike in all previous attempts, this is directly translatable into a smooth, continuous snm!
We take our discrete snm and lower the death-end by 1, i.e. subtract 1 there. So if the value is outside the d1,d2 interval, 1 is subtracted. If it is inside, nothing is added or subtracted, it stays the same, namely 1. Likewise at the birth-end, if it is outside the birth interval it stays 0, if it is inside, 1 is added. Of course there has to be a smooth interpolation in between, but we already have many ways to do that. We can use our smooth step functions for this.
To make a long story short: I tried it, but sadly it lead to unsatisfactory results. Nothing spectacular. Maybe I did something wrong, maybe I'll try again one day. But for now I consider this path as leading to nothing.
ionreqMon, 09 Apr 2012 20:21:14 -0000http://sourceforge.net748574d097ec2b811a5e1a041bbe436bed1bc557other (smooth) life that is not SmoothLifehttp://sourceforge.net/p/smoothlife/blog/2012/03/other-smooth-life-that-is-not-smoothlife/
Kellie Michele Evans - Larger than Life
http://www.csun.edu/~kme52026/thesis.html
Marcus Pivato - RealLife
http://arxiv.org/abs/math.DS/0503504
http://en.wikipedia.org/wiki/Life-like_cellular_automaton
Chapter 12 in "Game of Life Cellular Automata", Andrew Adamatzky, Springer 2010
Bruce MacLennan - Continuous Spatial Automata
http://web.eecs.utk.edu/~mclennan/contin-comp.html
Leon Chua - Cellular Neural Networks
http://en.wikipedia.org/wiki/Cellular_neural_network
Jonathan McCabe - Multiscale Turing Patterns
http://www.jonathanmccabe.com/
http://vimeo.com/jonathanmccabe
H.-G. Purwins - Dissipative Solitons in Reaction Diffusion Systems
http://www.uni-muenster.de/Physik.AP/Purwins/RD/index-de.html
http://en.wikipedia.org/wiki/Dissipative_solitons
Robert Munafo - Roy Williams Xmorphia
http://mrob.com/pub/comp/xmorphia/index.html
http://www.youtube.com/user/mrob143
Please, if you have any idea how SmoothLife is related to any of this stuff (or are interested in relating it deliberatly), contact me.
Are the SmoothLife disk and ring kernels Greens functions of differential operators?
Are smooth gliders Goldstone bosons of a field equation?
Can SmoothLife be translated to a Gray-Scott, Ginzburg-Landau, Swift-Hohenberg, FitzHugh-Nagumo model?
Can all this be used to find an other, better smooth time stepping mode?
ionreqThu, 22 Mar 2012 08:50:33 -0000http://sourceforge.neta0c439f48c19f05a57d3a1f9d01817f333a7dd6bnew smooth time stepping modehttp://sourceforge.net/p/smoothlife/blog/2012/03/new-smooth-time-stepping-mode/just found a new time stepping mode. now we've got three to choose from (not counting the delayed time and the acceleration modes, which I consider very experimental, and which are not included in the source code).
mode 0 (discrete)
f(x,t+1) = S\[snm\] f(x,t)
mode 1 (smooth)
f(x,t+dt) = f(x,t) + dt S\[snm'\] f(x,t) with snm' = 2*snm-1
this becomes in the limit dt->0 in the Euler integration sense
d_t f(x,t) = S\[snm'\] f(x,t)
mode 2 (smooth 2)
f(x,t+c) = (1-c) f(x,t) + c S\[snm\] f(x,t) = f(x,t) + c (S\[snm\] f(x,t) - f(x,t))
which becomes in the limit c->0 (Euler integration)
d_t f(x,t) = S\[snm\] f(x,t) - f(x,t) = (S\[snm\] - 1) f(x,t)
but becomes in the limit c->1
f(x,t+1) = S\[snm\] f(x,t)
so what we've done here is, we have invented a linear combination of the two cases c=1 and c=0 that we want to have, but don't know what is in between. the simplest solution is a linear combination. for infinitesimal c it generates an equation of the form we want to have, but not with an operator we are satisfied with. why? because it doesn't generate the same generic gliders as in the mode 0 case. we want to be able to switch between discrete and smooth time stepping and get the exact same glider form. only one time hopping in discrete steps and the other time gliding along smoothly. neither of the two smooth modes achieves that unfortunately. but both lead to interesting forms of life with gliders, oscillators and stable structures, so they have a reason to exist in their own right.
or in other words: in the mode 1 case we get the right form of the equation, but with a different operator. that this operator has to be different from the mode 0 operator is clear, but we haven't yet found the right one. in the mode 2 case we get a familiar operator (at least including the mode 0 one), but a slightly different form of equation. so what we seek is a sort of mixture. always obeying the limit c->1 where we have to get the discrete time stepping.
the search for the real smooth time stepping mode will go on, this is just the beginning.
probably the real solution to the problem involves derivatives of x on the right hand side somehow.
ionreqSun, 11 Mar 2012 18:50:18 -0000http://sourceforge.net343cff7b06725f5dad4dfb6ed49f1900f4a910bfRealLife and SmoothLifehttp://sourceforge.net/p/smoothlife/blog/2012/03/reallife-and-smoothlife/"Didn't you just implement RealLife from Pivato?", I hear you ask. Well, no I didn't, because RealLife can not be run on a computer. Pivato himself says so. I consider RealLife a special case of SmoothLife for inner radius going to zero. With this notion it is clear that RealLife can never be simulated on any finite grid/lattice/mesh, because as soon as the inner radius approaches the grid spacing, it is over. You have to do some smoothing/mean field approximation for the inner point. Then you can let the outer radius go to infinity. But as it turns out, you don't need a very small inner radius, it makes no qualitative difference. Even with inner radius one third of outer radius the glider looks basically the same as you can see if you compare the generic smooth glider with the bugs of LtL. RealLife is a theoretical, mathematical model. SmoothLife has the advantage that it can also be run on a computer. And we have to be able to experiment, don't we?ionreqSun, 11 Mar 2012 18:49:10 -0000http://sourceforge.net3f5a856fedacc208058335cb33292586a33fdcc7Introduction, how I discovered SmoothLifehttp://sourceforge.net/p/smoothlife/blog/2012/03/introduction-how-i-discovered-smoothlife/Welcome to the SmoothLife developer Blog!
Be sure to check out
http://www.youtube.com/user/ionreq
especially the SmoothLife playlist
and especially the presentation therein.
You may have guessed it, but SmoothLife is not the first Game of Life implementation I ever wrote. I could show you a Game of Life implementation I wrote in Assembler on the Commodore Amiga from 1992 that uses the graphics co-processor called Blitter that the Amiga had (already in 1985). So, GoL for me always was linked to image processing.
I grew up with 16 or 32 colors (out of 4096) and pixelated lines and circles. When I got a PC with true color graphics, I was fascinated with anti-aliasing, i.e. using color hues to give the appearence of smooth edges. I wrote many programs that calculated this effect on a per pixel basis long before there were GPUs with multisampling or FSAA that you can simply switch on.
Plus of course I was always fascinated by the dynamics and the richness of forms of the Game of Life. Gliders, blinkers, spaceships, etc. I know all of it, and the people that do research in this area are my heroes. I always wanted to see a glider that can go in any direction, or at least in directions other than diagonal and orthogonal.
So, I guess I was the perfect person to discover SmoothLife, nobody else could have done it. One day I decided to write my n+1st Game of Life implementation this time using GLSL. (Well, to be honest, after the Amiga/Blitter implementation I always wrote generalizations, i.e. different rules, more than 2 states, etc., but nothing much came ever out of it.) So, there were these two nested loops to count the neighbors, this time executed by a graphics card shader program, great. Millions of generations per second. We've come far. So why not extend the neighborhood a little bit and see what happens, that's just one number in the for-loops, i.e. a radius. Radius 1 Game of Life, radius >1 something else, I love generalization. In general. I immediately looked it up on the internet and found "Larger than Life" by Kellie Michele Evans. Of course, there's nothing new under the sun. (And I'm still not sure if SmoothLife is new, even after months of internet research.)
From there everything went very fast. In LtL there are oblique gliders (bugs), but they are rare. I wanted to see more of them. Well, what can I do? I can make a circular neighborhood, I had the notion of a radius anyway already. And I can make the edges of this neighborhood anti-aliased, cause that's how I roll anyway. And the GPU forces you to use float instead of int anyway. So I was more or less forced to do what I did. Anyway. But lo and behold, to no avail. So the reason why the diagonal gliders are diagonal is not the outside shape of the kernel, but ... the INSIDE! Of course, we are on a square grid, and the cell in the middle feels it, always. So how do we get rid of a square grid? We can't, but we can make the hole in the middle also round, with anti-aliasing. I considered this idea mind-blowingly new and original, I thought, noone ever could have had it before. But now I know that's how Turing patterns work, of course. It just seems, nobody has ever used it for the Game of Life.
I was very excited if anyone had already found this, did internet research best I could, and am still doing it, discovered many exciting things (and still do), that are close, but not SmoothLife. I guess this is, because you need an implementation that lets you vary parameters in real-time and observe the effects, to be able to find interesting patterns. And this is only recently possible with GPUs. It just so happened that I was the first one of the growing number of GPU programmers who cared for it. I guess SmoothLife will have a great future. It is the Game of Life for the 21st century. Considering how popular Conway's Game of Life has gotten over the last 40 years, it is daunting for me. I really hope, I am not viewed as the new Conway, cause I am not. There is also Kellie Michele Evans, Marcus Pivato, Bruce MacLennan, and many others. I just did a little implementation on the GPU, you know. With FFT, ok, but anyone can do that. That's not hard. Really. It's fun.
The other possibility is, that SmoothLife has to be re-discovered five times over the next 20 years by five different people until it gets popular. And maybe 50 years from now, someone will do a little historic research and find who discovered it first: probably a russian guy in the late 1940s. Or no: I bet Gauss already knew about SmoothLife. Probably in the works of Plato there is already a hint of the idea of SmoothLife. Or there are cave drawings that clearly show the disk and ring shaped kernels of SmoothLife.
ionreqSun, 11 Mar 2012 18:48:00 -0000http://sourceforge.net2a58bd0321a754b22476afb1fd83da29eff77caa