After doing some quick Google searches, it appears as though this is caused by me compiling the script with Python 2.6 and you perhaps using an older version than that? What version of Python are you using?Lewis wrote:I keep getting this error:
Not off the list entirely, just down quite a few spots (you'll see them verified lower on the list, in the 9k generations range). Some of your really high-count ones got inflated a lot because (using one specific example here) they created a glider in the middle of the debris that managed to escape without touching anything. Because it took another couple thousand generations for the glider to get sufficiently far away from the stationary debris for the script to be able to tell that things had settled down, the number got inflated quite a bit. Hence the unfortunate need for the "Verified?" column on the table.Elithrion wrote:Also, I notice that some previously verified >12k generations patterns have vanished off the list - de-verified, are they? So, does the search yield many false positives?
Well, the goal is to add that functionality to it as well (as well as user statistics and all sorts of fun things), but I unfortunately have no real idea how to implement an effective census script. If anyone has ideas, I'm all ears, as I would love to get it implemented.Lewis wrote:I fixed the problem. I hadn't un-installed the older version of Python when I got the newer version. I just needed to direct Golly to the 2.6 dll file. The program seems to be working for now.
Also, Will the program ever gather statistics of pattern frequencies or just finding long-lived patterns?
Yeah, a torus would be idea, but, as you said, I don't think Golly supports toroidal universes. The vast census on Ostrasinski's website is based on a non-toroidal universe, though (just a "for the record").Macbi wrote:I think all the census programs worked on a torus, so that you don't get weird edge effects. If you use 2048*2048 then (because the patterns tend to take less time than 2048 gens to settle down) they won't "know" that they're on a torus. Golly can't do tori yet though, can it?
Puffers (if they ever did come up) are no problem, they just artificially inflate the lifespan until they get away from the "core".Lewis wrote:How does the program handle puffers? Would it mess up the results on here or would that soup just be discarded?
Yep, I'm not worried about the sending the server aspect of it, I think I've got that figured out now. It's how to go about doing the actual counting (like in a really realistic coded, efficient kinda way).Elithrion wrote:If you really want a census, I imagine that the best way to go about it would be to have the program count the objects produced, and store the resulting count on the computer (in some suitably encoded form?) until the end of the session, at which point the counts would be sent to the server. Maybe?
Yep, I don't think that'd be hard to do at all. The only thing is I don't really know how to code any really cool scripts like glider collision-checkers and stuff like that. If anyone knows how to code something that would make for a good internet-y script like this, I'd be happy to give it the server treatment.For a search, I imagine when you run the script it would message the server asking where it should start, the server would check the list of what areas are completed in a given search, and what programs are currently running, and then suggest a starting location and "direction" of search to the script. The script would then start the search and tell the server it's still running and how far it's gotten every five minutes or something. So, let's say it's a fresh search and two instances start - one is assigned the very beginning of the search and told to search forward, the second is assigned the end and told to search backward. Let's say five minutes later another one joins - it's assigned the 1/3 point of the segment between the two searchers and told to search forward as well. The server might ask the scripts to change direction/location on the 5 minute check-ins too. Or something like that? It doesn't sound like it should be insanely complicated, I don't think >.>
Could the census be used in rules with different neighborhoods? I'd be quite interested in running a census of B24/S13 in the Von Neumann neighborhood.Nathaniel wrote: Edit: Also, I'd personally like to have a census script so that we can collect censuses of other Life-like rules (I imagine that Lewis has 2x2 in mind himself).
If Golly supports it, then there's no reason for it to not work with minimal modifications to the script.Lewis wrote:Could the census be used in rules with different neighborhoods? I'd be quite interested in running a census of B24/S13 in the Von Neumann neighborhood.
It means that, for one reason or another, the script couldn't make a connection to the server. All the files that the script tries to upload are saved on your harddrive though - do a search for "methuselah" and the files should appear (in Golly's data directory), and their filenames are "methuselah_XXXXX.rle", where "XXXXX" is the lifespan of the methuselah. It's not particularly important until a really big one slips through the cracks (eg. if you find one that says "methuselah_45235.rle", you might want to verify it and claim itLewis wrote:Occasionally, the program says 'The pattern could not be uploaded and has been saved to a data file' or something. (the message only shows for a second or s obefore disappearing). What does this mean?
)On a torus no ships could "escape" so you just wouldn't count any. Although I guess if you were (un)lucky you could get one just whizzing round and round the torus. In an unbounded census the amount of spaceships produced would be proportional to the perimeter (presumably), whereas the amount of still lives would be proportional to the area, which is a bit odd.hkoenig wrote:It's not that hard to write an "unbounded" Life application. (Keep lists of cells instead of an array). Also, with a torus how do you really manage to handle escaping Gliders and such? If you are going to do a real census you need to let those objects escape and count 'em.I think all the census programs worked on a torus
w00tMost users ever online was 6 on 17 minutes ago
Also, where is this data directory? I appear to not be in possession of one (using Golly 2.0 if that's relevant) and a search of the whole harddrive for "methuselah" yielded no appropriate files despite the fact that I seem to have received that message a few times.Nathaniel wrote:All the files that the script tries to upload are saved on your harddrive though - do a search for "methuselah" and the files should appear (in Golly's data directory), and their filenames are "methuselah_XXXXX.rle"
For me it's located at C:\Users\Nathaniel\appdata\Roaming\GollyElithrion wrote:Also, where is this data directory? I appear to not be in possession of one (using Golly 2.0 if that's relevant) and a search of the whole harddrive for "methuselah" yielded no appropriate files despite the fact that I seem to have received that message a few times.
Hrm... there might be, actually. I'd change them to a reasonable limit while I test thatElithrion wrote:Ah, it exists! And contains 95 files! Also, question: I haven't had any patterns added to the list since I changed my "name" and "email" to be several hundred characters long. Is there some sort of invisible limit on that?
Yeah, I'll experiment with some different methods for the next version. I just wanted a "the pattern is done evolving" criterion that was fast for short-lived soup (since those are the vast majority), is general for any Life-like rule, but the trade-off is that it lags quite a bit for long-lived soup. Basically it computes the hash values within a square of side length 20 + (gencount/8), centred at (0,0) and waits for a repetition. Thus, if the pattern emits a glider anywhere near the end of its evolution, you have to wait for that glider to escape from that box before the lack of evolution is noticed. I suppose that could enforce some density condition as well to improve the check a bit, but I'd get a little nervous about other Life-like rules without thinking about it more first.Elithrion wrote:Yeah, I figured out that it logs all files shortly after making the post, but you didn't see the edit that took place that time
But, still, I don't understand why its generation count is off quite so much. Let's take your top ranking soup. It was logged at 21k generations, but verification took 4.5k off from that. At generation 16888, it's basically a mess dead centre and a number of gliders flying off in all directions, but quite a ways off from the mess already. And then apparently its death is not noticed for another 4000 generations? There should be a better-performing way >.>
Code: Select all
-bash: install_name_tool: command not found
But, still, I don't understand why its generation count is off quite so much. [...] There should be a better-performing way >.>
I know that WinLife32 has a neat autostop feature. The explanation at http://www.winlife32.com/tech-faq.htm could be of your interest:I suppose that could enforce some density condition as well to improve the check a bit, but I'd get a little nervous about other Life-like rules without thinking about it more first.
However, as far as I know, WinLife32 is not able to deduce when switch engines do stabilize.How does the Autostop feature work?
The growth algorithm computes a signature for every generation, at negligible cost. This signature, which is based on the neighbor state for each live cell, is the same for any two patterns composed of the same objects (collections of contiguous cells). This means that moving objects such as gliders do not affect it. If two nearby generations have the same signature, then another cycle is grown. If the signatures match throughout the cycle, then the patterns themselves are compared (which is a much more expensive operation). Anything which is not common to the two generations is analysed to see if it is composed of known moving objects (typically gliders). If so then their trajectories are analysed to foresee possible interactions. Sometimes the only way to analyse them is to run the pattern until there is no possibility of interaction - that is why you sometimes see a pattern (particularly a random broth) grow for thousands of generations, then get a message saying it is not interesting from a much lower generation.
Another worry I have with that is that it seems to be quite Life-specific (part of the algorithm works by checking know spaceships), while I would like to keep this as rule-independent as possible. I hadn't even really started trying to optimize it yet though in v1.00, so I'm sure we can do much better than has been done so far.DivusIulius wrote:However, as far as I know, WinLife32 is not able to deduce when switch engines do stabilize.