What errors specifically?yoleo wrote: October 14th, 2022, 9:54 pm 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?
Code: Select all
gcc lifelib_test.cppTry passing -std=c++2a to the compiler?yoleo wrote: October 15th, 2022, 10:43 pm I edited my original post to add an attachment, the output upon runningCode: Select all
gcc lifelib_test.cpp
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.yoleo wrote: October 16th, 2022, 12:10 pm 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.
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)
Code: Select all
x = 28, y = 28, rule = B3/S23:T28,28
13b2o11$10b3o$10bo$o10bo15bo$o15bo10bo$17bo$15b3o11$13b2o!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(<, bwv, "b3s23:T28,28");
pat.write_rle(std::cout);
return 0;
}Code: Select all
x = 28, y = 28, rule = B3/S23:T28,28
13b3o10bo$27bo12$o26bo$o26bo12$o$bo10b3o!calcyman wrote: August 5th, 2017, 11:18 am @muzik Good idea. The ulife algorithm in v4.x will be able to run either:
...at exactly the same speed (comparable to, and maybe slightly faster than, apgmera's vlife algorithm).
- 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).
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.muzik wrote: August 2nd, 2024, 11:02 amDoes lifelib support running patterns on toroidal bounded grids?
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)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
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.wwei47 wrote: December 29th, 2024, 11:15 pm [...] 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. [...]
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.confocaloid wrote: December 29th, 2024, 11:35 pm 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
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.confocaloid wrote: December 29th, 2024, 11:35 pmEven 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.wwei47 wrote: December 29th, 2024, 11:15 pm [...] 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. [...]
Code: Select all
w="219o$"
q=lt.pattern(w+w+w+w+"o!")
r=q[1<<20]