eyvindn

the unity/minecraft level of abstraction is a common one in AFIFE, and too often ends up being Spore - looking and behaving in very interesting ways, but remaining just that. those approaches are on the wrong side of the performance vs evolvability curve - scale is a necessary ingredient and running things at a physics sim level is just too taxing.

it is of course entirely possible we are on the flip side and too low-level - this is something we're trying to find out.

yes! very soon!

this is my personal take;

I agree, for the same reasons you mentioned, resource constraints will need to be baked in (they are already, to some extent, if you consider the constrained resource to be z80-CPU-seconds the program has access to). something more akin to energy in our real world, which can be manipulated, aggregated, shared, pooled, stolen, etc feels more natural, however.

imo meaningful intelligence could conceivably developed in a soup (even in-silico), unclear on what timeline, but grounding it with human and/or real-world data is necessary to make it useful to us (bio-compatible, if you will?)

there are many bottlenecks in the substrate - memory limits being one of them. other things like the A-B concatenation inherited from the bff paper also severely limit the possible dynamics. understanding and avoiding these bottlenecks are some of our next steps!

as other folks have replied, Z80 is more expressive and yields more interesting replicators faster. however the question of how complex to make the "base layer", if you will, remains open. we expect it to also be an ease of auto-evolution vs. performance tradeoff.

second question is a good question :)

authors here - happy to answer any questions! we’re excited for this line of work and see this as the first step on a longer journey.

^ yes. this is what we hope.

:)

colab with all code will be available next week, will add link from the article.

thanks for catching this, the figure for the target was inverted when exporting for publication, corrected now.

could you link the drone swarm command article?

Authors here - will do our best to answer any questions.

There's some recent work that involves NCAs in a 3D setting by Horibe et. al [1] and tweet [2]. Other work by Risi and collaborators is definitely worth checking out as well.

[1] https://arxiv.org/abs/2102.02579 [2] https://twitter.com/risi1979/status/1358018266824912897

That repo contains the code, figures and text for the article. It's set to public now.

The texture template images come from [1], a collection of textures categorised by "description".

[1] https://www.robots.ox.ac.uk/~vgg/data/dtd/

The second cell looks a section title ("Imports and Notebook Utilities"), but contains the definitions of these functions and the imports. Run this cell and I suspect things should work.

Apologies, not my intention. I was also under the impression seminal could be used to mean ”first” in the succession of our works and this is what I had intended to communicate.

Thanks for noticing. This is a typo stemming from early experiments. We started out with 16 channels, but switched to 12 channels of state when this worked just as well. I've submitted a correction.

EDIT: Alex replied below. For more details on quantisation see footnotes in our seminal work [1]

[1] https://distill.pub/2020/growing-ca/

Authors here. If you have any questions we'll do our best to answer them! Glad to see people find our work interesting thus far.

We also encourage anyone interested to play with the linked Google Colabs [1][2] and read the other articles in the Distill thread. In the Colabs you'll find a bunch more pre-trained textures as well as a workflow to train on your own images, plus some of the scaffolding to recreate figures.

[1] https://colab.sandbox.google.com/github/google-research/self... [2] https://colab.sandbox.google.com/github/google-research/self...

Would you mind sharing what panel this is?

This is an interesting idea and innovative approach - exciting stuff and congratulations on securing the 200k investment.

Some questions regarding the underlying technology:

You mention a "self-healing" grid. If one of these laser lines gets disrupted, say by a bird, or someone knocks over the laser receiver - how quickly does the PoP reroute traffic over a different path in the grid? Does it wait for a timeout, or is there some meta-data from the laser link to know when the interface is down?

One of the reasons you use the laser PoPs is that underground fibre is expensive. However - given that you have to pull overground fibre to every customer within the PoP - the total "length" of fibre in play will be roughly equal to the length of fibre required in a traditional underground installation. What's the advantage then? Why can't you pull all the fibre overground and bypass having laser PoPs completely?

Finally - given the massive investment in 4G and price wars in India, I would assume you are competing with mobile broadband routers. How is performance of such solutions in dense cities like Bengaluru? Is it unreliable or congested enough for people to want to pay for a dedicated fibre/laser internet connection?

The idea I think is very useful from a UX perspective.

Some questions that immediately hit me:

How will you incentivise users to want to jump on a video chat with a random person? I think some people may be frightened by the thought of a stranger opening a video chat with them?

Currently the video opens full screen. Have you considered having a floating window to allow the user to continue interacting with the website?

Have you considered tracking interactions or even sharing the users screen to allow you, as a UX person, to see what the user is seeing (while talking with them).

Very solid demo! Thanks for sharing.

Authors here. Had great fun making this. We think Distill is an excellent medium.

Happy to respond to any questions (although likely with a few hours delay as we are in CEST and nearing our bedtime).

Thank you. We will take a look at this. Currently we are working through a backlog of communication.

Yes. Several other applications (both with and without an underlying 2D grid) are in the pipeline which we hope to publicise soon.

Diffusion-reaction systems were an inspiration in general. Using a Laplace operator (or the discretised equivalent for our 2D grid) might have trouble learning to generate these patterns - the Laplacian wouldn’t always provide unique information as to where a cell might be based on its neighbours. It’s possible the network would learn to exploit the hidden channels to bypass this directional invariance. Starting from a single pixel in such a setting would indeed need some mechanism to break the symmetry (stochastic updates as used here, for instance).

1) This is often the first question many people familiar with NNs ask and rightly so. Compression was not one of our goals with this article, and it would look like a terrible compression algorithm if that were its purpose. In fact, the model displayed here is about 8.3k parameters, although the WebGL model is quantized (more info on this in the last section), and each model learns to encode an image consisting of 44x44x3 = 5808 integers. We made no attempt to minimize this number. The key thing to bear in mind is that all the cells have the exact same rule and the image generation starts from a single one of them - meaning they have to learn to communicate locally with their neighbours to self-organize in the correct pattern. This is a very non-trivial task and the majority of the model’s parameters are likely going towards this communication protocol and growth behavior.

2) We have not tried 3D. As for animations, some of our earliest experiments suggested one could achieve “animations” by applying the loss at key-points to have the model learn to iterate through these points across several time steps.

3) One could argue the WebGL implementation does this to some extent by quantizing the learned weights we take from the Tensorflow training code. The model remains very resilient and worked out of the box in almost all cases. Moreover, if one tried to inject explicit noise to the CA in a given location, some models would have no problems adapting to it, while others would fail miserably. Some early experiments yielded some remarkably resistant models, able to resist while being subject to continuous globally occurring noise. We suspect explicitly training them while introducing noise would allow us to drive the model towards more consistently resistant behaviors.

4) One of the main obstacles to larger patterns at the moment is memory usage during a forward/backward pass. There are optimization and tricks we plan to employ to generate larger and more complex patterns, which may be discussed in a follow up thread.

We have a lot of future applications and directions in mind, including the feasibility of applying this to distributed computing and consensus. In particular, the idea of training a model generating CA parameters instead of having a CA fit a specific pattern is of great interest to us and the synthetic biological field. Feel free to get in touch.

1. The results do not depend on speed in principle. The difference between 60FPS and “max” can be several orders of magnitude depending on your hardware, so it’s likely you may see instabilities that exist on much longer horizons at higher speeds.

Interactions will play out very differently at different speeds because you are interacting with a sped-up/slowed down version of the CA.

2. We haven’t done any rigorous studies of regenerative capability, although this is certainly on our to-do list. From empirically playing with them, models seem to be more susceptible to damage to the centre of their bodies than to limbs, likely as a result of “growing” outwards.