Lifelib

[pzq_alex]

Compiling on a Linux-based cloud machine with clang++-11, this works just fine. But if I try the same code on my MacBook Air, I get a boatload of errors. Seems like it's related to compiler versions...is there anyone who has gotten C++ Lifelib working on a Mac? If so, what compiler did you use?

What errors specifically?

[yoleo]

I edited my original post to add an attachment, the output upon running

Code: Select all

gcc lifelib_test.cpp

[pzq_alex]

I edited my original post to add an attachment, the output upon running

Code: Select all

gcc lifelib_test.cpp

Try passing -std=c++2a to the compiler?

[yoleo]

Thank you!! That fixes it.

Another question: reading the source code for lifelib, what's the use case for handles and ihandles? The hypertree.h says "maps symbol to a node in the hypertree," but there's nothing in the code that explicitly creates any ihandles or handles.

Edit: never mind, figured it out. They're used, it's just obscured by a few layers of function calls in pattern2.h. The data of a pattern is stored in a hypernode, so creating or modifying a pattern turns into calls to the gethandle/sethandle/newihandle functions. It's just mostly done via calling the basepattern constructor or changehnode, which then manipulates the handles.

edit: I decided to type up some of my notes on the code and post them, in case anyone else finds them useful. They're incomplete, not necessarily accurate, etc. just some notes about what's-what. (I find templates really confusing and hard to parse.) Points of confusion are marked with (???)

[apg]

Thank you!! That fixes it.

Another question: reading the source code for lifelib, what's the use case for handles and ihandles? The hypertree.h says "maps symbol to a node in the hypertree," but there's nothing in the code that explicitly creates any ihandles or handles.

To further clarify, the purpose is so that the hypertree knows which nodes are being used elsewhere in the program. This is necessary because otherwise it wouldn't know which nodes can be cleared during hashlife's garbage-collection phase. The string handles aren't used anywhere; they were originally planned for a 'VLSI editor' built on top of lifelib where you can define increasingly complex components in terms of simpler components and assign human-readable names to them. I later added the integer handles (ihandles) and abstracted them away into the pattern class, so they're an implementation detail.

[snowman]

Is there yet a way to delete pattern objects in python-lifelib? I find my programs take up a lot of RAM, seemingly full of patterns that I only need to access once.

[snowman]

Is it possible to have python-lifelib take advantage of GPU processing? My friend wanted to help me run a search program using CUDA, but it appears there's only a dedicated branch on regular lifelib.

[confocaloid]

Does Python 3 lifelib design allow creating and using more than one session in a single run of a script? (Either using several sessions that are active at the same time, or deactivating the active session and creating a new one without restarting the Python script.)

Code: Select all

import lifelib
# ...
sess1 = lifelib.load_rules("b3s23")
# ... (do something, then possibly deactivate sess1)
sess2 = lifelib.load_rules("b38s23")
# ... (do something, then possibly deactivate sess2)
sess3 = lifelib.load_rules(input_rulestring)
# ... (do something, then possibly deactivate sess3)
for rulestring in [ "b3s23", "b38s23", "b3s238", "b38s238", "b36s23" ]:  # there could be several dozens of rulestrings in this list
    sess = lifelib.load_rules(rulestring)
    # ... (do something, then deactivate sess)

[Vort]

What minimum torus size lifelib supports?

I tried different sizes and all of them produce either compilation errors or wrong output.
For example, how to advance this pattern by 48 ticks?

Code: Select all

x = 28, y = 28, rule = B3/S23:T28,28
13b2o11$10b3o$10bo$o10bo15bo$o15bo10bo$17bo$15b3o11$13b2o!

I tried it this way:

Code: Select all

#include "lifelib/pattern2.h"
#include "lifelib/upattern.h"

#include <iostream>

int main()
{
	apg::upattern<apg::VTile28, 28> upat(28, 28);
	upat.insertPattern("13b2o11$10b3o$10bo$"
		"o10bo15bo$o15bo10bo$17bo$15b3o11$13b2o!");
	upat.advance(0, 0, 48);

	std::vector<apg::bitworld> bwv(1);
	upat.extractPattern(bwv);

	apg::lifetree<uint32_t, 1> lt(10);
	apg::pattern pat(&lt, bwv, "b3s23:T28,28");
	pat.write_rle(std::cout);
	return 0;
}

But I got this:

Code: Select all

x = 28, y = 28, rule = B3/S23:T28,28
13b3o10bo$27bo12$o26bo$o26bo12$o$bo10b3o!

[muzik]

Does lifelib support running patterns on toroidal bounded grids? I remember bounded grid soup searching was stated as something which could possibly be done for apgsearch v4.x with an update to ulife, but can't remember anything after that point indicating that it came to anything:

@muzik Good idea. The ulife algorithm in v4.x will be able to run either:

• A virtually-unbounded flat plane, as is the case in 3.x;
• A fixed rectangular torus with width divisible by 16 (at least 48) and height divisible by 32 (at least 64).

...at exactly the same speed (comparable to, and maybe slightly faster than, apgmera's vlife algorithm).

[Vort]

Does lifelib support running patterns on toroidal bounded grids?

I started trying because I read in wiki article Lifelib#Comparison of data structures "upattern, Supported topologies: Torus, infinite plane". If it is not true, article should be corrected.

[Aleph]

Is there a "proper" way to install lifelib using a preexisting cygwin installation? I did some dumb stuff with the help of Sokwe and seem to have gotten it to work, however I had also used lifelib.install_cygwin() in parallel. At the same time, lifelib appears to be working when being used with a jupyter notebook launched from my old cygwin installation.

One thing I did learn is that you are going to have a very bad day trying to install jupyter from within cygwin (one component will just straight up refuse to work, saying something about cygwin being unsupported); just install it outside of cygwin and then run it inside of cygwin.

Also, is there a reason why this code takes so long to run? Using Golly and oscar on this pattern takes about 2 seconds, but using lifelib and Brent's algorithm takes about 44 seconds. Finally, trying to get the apgcode just straight up throws an error.

Code: Select all

x = 86, y = 5, rule = B2cn3ajq4ajqr5c/S1e2ce3acnr4aky5aeij6ac78
86o$86o$86o$86o$o!

Code: Select all

def p(pattern):
  n=0#exponent for Brent's algorithm
  while True:
    waypoint=pattern
    for i in range(1<<n):
      pattern=pattern[1]
      if pattern==waypoint:
        return (waypoint,n,i+1)
    n+=1

w="86o$"
pattern=lt.pattern(w+w+w+w+"o!")
pattern_,n,period=p(pattern)

print(str(period))
print(pattern_.apgcode)

[confocaloid]

I think lifelib can also be used without installing or using jupyter-related functionality.

Code: Select all

# mkdir test
# cd test
# git clone https://gitlab.com/apgoucher/lifelib.git
# python3
# >>> import lifelib
# >>> sess = lifelib.load_rules("b3s23")
# >>> lt = sess.lifetree(n_layers = 1, memory = 256)
# >>> p = lt.pattern("xq4_153")
# >>> print(p.rle_string())
# >>> lt.pattern("3o$2bo$bo!").apgcode

[...] Also, is there a reason why this code takes so long to run? Using Golly and oscar on this pattern takes about 2 seconds, but using lifelib and Brent's algorithm takes about 44 seconds. [...]

Even with Golly and oscar, the time depends on whether the active algorithm is QuickLife or HashLife. I just tested this pattern (in Golly) and got ~20 seconds with HashLife vs. ~10 seconds with QuickLife. This can be expected for patterns that are hard to predict except by actually evolving them. HashLife works better for larger engineered patterns with visible structure evolved with a high step; QuickLife works better for small or "chaotic" patterns evolved tick-by-tick.

[Aleph]

I think lifelib can also be used without installing or using jupyter-related functionality.

Code: Select all

# mkdir test
# cd test
# git clone https://gitlab.com/apgoucher/lifelib.git
# python3
# >>> import lifelib
# >>> sess = lifelib.load_rules("b3s23")
# >>> lt = sess.lifetree(n_layers = 1, memory = 256)
# >>> p = lt.pattern("xq4_153")
# >>> print(p.rle_string())
# >>> lt.pattern("3o$2bo$bo!").apgcode

Good point. The intended purpose of jupyter for me was just slightly better QOL. Cloning lifelib is probably a better way to install it in any case though.

[...] Also, is there a reason why this code takes so long to run? Using Golly and oscar on this pattern takes about 2 seconds, but using lifelib and Brent's algorithm takes about 44 seconds. [...]

Even with Golly and oscar, the time depends on whether the active algorithm is QuickLife or HashLife. I just tested this pattern (in Golly) and got ~20 seconds with HashLife vs. ~10 seconds with QuickLife. This can be expected for patterns that are hard to predict except by actually evolving them. HashLife works better for larger engineered patterns with visible structure evolved with a high step; QuickLife works better for small or "chaotic" patterns evolved tick-by-tick.

Here's the thing: Tom Rockicki did some benchmarking with various algorithms, and it seems like there was not a single case where QuickLife was faster than lifelib. Strangely enough, if I'm "just running" these patterns, HashLife is faster than QuickLife, but the moment oscar gets involved, QuickLife suddenly wins. However, the 2:1 ratio you're getting with HashLife to QuickLife still pales in comparison to the 22:1 ratio I'm getting with lifelib to QuickLife, and lifelib is supposedly optimized for speed.
https://conwaylife.com/wiki/Lifelib#Performance
EDIT: How does this take THIRTEEN seconds to run??? HashLife can do it in about one, and QuickLife isn't far behind. Isn't lifelib supposed to be faster???

Code: Select all

w="219o$"
q=lt.pattern(w+w+w+w+"o!")
r=q[1<<20]