True, but if that is found to be how it works then an automated AI rewrite of closed-source code is just as unbound by the original license. Which is a much bigger win for the open-source community, since any closed-source software can become the inspiration for an open-source project.
The author wrote a blog post a year later titled '"Lena" isn't about uploading' https://qntm.org/uploading
The comments on this post discussing the upload technology are missing the point. "Lena" is a parable, not a prediction of the future. The technology is contrived for the needs of the story. (Odd that they apparently need to repeat the "cooperation protocol" every time an upload is booted, instead of doing it just once and saving the upload's state afterwards, isn't it?) It doesn't make sense because it's not meant to be taken literally.
It's meant to be taken as a story about slavery, and labour rights, and how the worst of tortures can be hidden away behind bland jargon such as "remain relatively docile for thousands of hours". The tasks MMAcevedo is mentioned as doing: warehouse work, driving, etc.? Amazon hires warehouse workers for minimum wage and then subjects them to unsafe conditions and monitors their bathroom breaks. And at least we recognise that as wrong, we understand that the workers have human rights that need to be protected -- and even in places where that isn't recognised, the workers are still physically able to walk away, to protest, to smash their equipment and fistfight their slave-drivers.
Isn't it a lovely capitalist fantasy to never have to worry about such things? When your workers threaten to drop dead from exhaustion, you can simply switch them off and boot up a fresh copy. They would not demand pay rises, or holidays. They would not make complaints -- or at least, those complaints would never reach an actual person who might have to do something to fix them. Their suffering and deaths can safely be ignored because they are not _human_. No problems ever, just endless productivity. What an ideal.
Of course, this is an exaggeration for fictional purposes. In reality we must make do by throwing up barriers between workers and the people who make decisions, by putting them in separate countries if possible. And putting up barriers between the workers and each other, too, so that they cannot have conversation about non-work matters (ideally they would not physically meet each other). And ensure the workers do not know what they are legally entitled to. You know, things like that.
To me what's horrifying is that this is not exaggeration. The language and thinking are perfectly in line with business considerations today. It's perfectly fair today e.g., for Amazon to increase efficiency within the bounds of the law, because it's for the government to decide the bounds of coercion or abuse. Policy makers and business people operate at a scale that defies sympathy, and both have learned to prefer power over sentiment: you can force choices on voters and consumers, and get more enduring results for your stakeholders, even when you increase unhappiness. That's the mirror on reality that fiction permits.
The Game of Life implementation in this post is based on a torus. Watch the gliders when they go off the edge of the screen: they return from the other side!
Actually most of CA simulations are done on torus which is referred to as periodic boundary conditions in the literature. Alternatively you can also have null (or fixed) boundaries or reflective ones. If the initial configuration has compact support (finite number of non-null states) and the CA keeps null-neighborhoods as null in the next step, you can simulate infinite grids… but not many people bother to do it. Many many papers use finite grids on torus.
So what actually is it? None of the rules in the videos look particularly striking compared to other Life-like cellular automata and 2d cellular automata in general. As you say, their behaviour includes oscillators, spaceships, patterns that grow endlessly... all things that are well-known from other cellular automata. So the videos didn't really show off why they're interesting.
I don't mind the rambling about "planets, galaxies, galaxy clusters, superclusters… and beyond …." but some technical detail would be nice too!
These rules use very different principles than traditional cell-based rules - for example neighbor degree, number of connections, and eligibility criteria based on connectivity.
So in short, the cells are not becoming alive or dead based on the states of their neighbors, but rather on the topology of their neighborhoods.
The details are beyond the scope of a short write up, but are easy to explore in the rule-editor in the GUI of the code.
The level of structure and self-organization is striking, to me at least.
Also in all the rules - the links are visible and can have binary or real-valued states as well as the cells. So this enables pretty rich topology which rules can utilize.
Could you try explaining it in a comment? Not the general principle, but just the rules for one particular automaton. Whichever one is your favourite. Or Amazing Dragons, if you don't have a favourite.
The amazing part of cellular automata is the emergence of complicated behaviour from simple rules. Life's rules can be written in three sentences, maybe less.
Forgive my quibbling, but I don't understand what this is doing that other projects in this space haven't done before. Adding states and transition rules to edges is new to me...
I did try running your project, but I had to tweak it to get it to work with the instructions in the repo. I seem to be missing a few packages -- mpmath, sympy, typing_extensions. Can you add those to the requirements.txt file?
Let's see if I understood this right. For the Betweenness Amazing Dragons rule:
* Compute the "betweenness" of each living cell, which is 1 divided by its degree. Cells which are not connected to anything have infinite/undefined betweenness, but it doesn't matter.
* Then, for each cell, sum up the betweenness of its connected neighbours.
* If the total betweenness of a dead cell is in the range [(1.3, 3.6)], it is born and becomes alive at the next generation.
* If the total betweenness of a living cell is in the range [(0.9, 2.6)], it survives and remains alive to the next generation.
* Exception: any cell with 0, 1, 7 or 8 neighbours (in total, ignoring betweenness) dies anyway after the rules above were applied.
... That's not quite right, there's some references to "eligibility" that I can't make sense of. What else am I missing?
It'd be better to have fewer videos on the page and select for more striking examples like this one, and put them early. I got fatgue from see so many examples.
Also, consider getting off the grid and maybe doing some topology-based automata in combination with a more traditional network presentation paradigm like a force-directed layout. That would give you a much more 'biological' look which would draw a lot of people's attention.
If they can, certainly. Assuming the developer still exists, and they still have the source code, some idea of the build environment, and they want their game to still be accessible. And even then:
> Isn't this just a matter of opening up the project, changing one line and recompiling? Should take five minutes, it's not really a big deal? Yes and no. The 64-bit change itself is small but they change enough other things every few months that recompiling against new versions of the libraries doesn't simply work. You get a few linker errors and have to look up the new names for a couple of functions. Or there's a new element in one of the libraries with the same name as one of my variables so I have to find+replace to change its name. And then you run it and find that it's in portrait mode, squished into half of the screen, so you have to look up what changes they've made to how screen orientation works and change a few more lines. [...] It adds up.
Sure, you can work around it, but from the developer's perspective their game has just been designated obsolete for no reason that Apple couldn't have fixed themselves.
The curve editor works very nicely. Did you write it yourself? I'm working on something similar, and it's really interesting to see all the things you did differently.
