ConwayLife.com

https://catagolue.appspot.com/haul/b3s/C1?committed=2
This would suggest that Catagolue does not accept hauls containing zero objects. This greatly skews the statistics for this rule, because, from the times of submission, it appears that most hauls produce zero objects, meaning that the results displayed on Catagolue show a much greater frequency of objects than actually exists.

In my computer, parallelization makes apgmera to run slower. Are you sure apgmera can be parallelized properly?
I am using Intel Core i7-2670QM, and Windows 10 Pro 64bit.

David wrote:In my computer, parallelization makes apgmera to run slower. Are you sure apgmera can be parallelized properly?
I am using Intel Core i7-2670QM, and Windows 10 Pro 64bit.

Yes, Windows has some difficulty with OpenMP parallelisation (unlike Linux, for instance). A suggested workaround is to run N single-core instances of apgmera; this is what biggiemac did on his Windows machines.

calcyman wrote: Yes, Windows has some difficulty with OpenMP parallelisation (unlike Linux, for instance). A suggested workaround is to run N single-core instances of apgmera; this is what biggiemac did on his Windows machines.

Well, that is parallel, but not concurrent. I can't expect any speed improval from it.
What about using the standard parallelized algorithms?

David wrote: Well, that is parallel, but not concurrent. I can't expect any speed improval from it.

I don't understand -- if you have n instances running on separate cores, then you'll produce n times as many soups per unit time.

calcyman wrote: I don't understand -- if you have n instances running on separate cores, then you'll produce n times as many soups per unit time.

Suppose that the time complexity of apgmera is O(f(n)). As I have 4 cores, the time complexity would be O(f(n) / 4), but by the definition of big O notation, the time complexity falls back to O(f(n)).
If you use concurrent algorithms, I can expect improval in time complexity. For example, for a sorting algorithm, it's time complexity would be O(n log n) if it is neither parallel nor concurrent, but it could be O(log³ n), O(log² n), or even O(log n) if it is parallel and concurrent.
You can use the thread support library, or if possible, the parallelism TS.

David wrote:
Suppose that the time complexity of apgmera is O(f(n)).

What is n?

All apgsearch is doing is many independent iterations of the same task - evolve random soup and census objects. The operative word there is "independent," which differentiates it from the sorting algorithm you mentioned. Soups need to share no information. As such, there is no way to have a better asymptotic complexity using a finite number of cores, just speed things up by a constant factor as Adam mentioned.

calcyman wrote:What is n?

Whatever n is, the point is the time complexity cannot be improved by just speeding things up by a constant factor.

biggiemac wrote:All apgsearch is doing is many independent iterations of the same task - evolve random soup and census objects. The operative word there is "independent," which differentiates it from the sorting algorithm you mentioned. Soups need to share no information. As such, there is no way to have a better asymptotic complexity using a finite number of cores, just speed things up by a constant factor as Adam mentioned.

But within a single soup, there might be a way to have a better complexity. Generate a random soup with parallelism and concurrency, evolve it with parallelism and concurrency, census objects with parallelism and concurrency, etc.

A soup takes O(1) time to run; the only possible improvements are those that reduce the constant factor.

Also (speaking of algorithms more generally), if you have k cores, you can't get any better than a k-fold time improvement over a single-core machine. In many cases, even that is optimistic (see Amdahl's law).

Hello, I am now a Linux user. Specifically, Linux Mint 17.3 'Rosa', MATE 64-bit.
I've installed apgmera and tried to compile it, but I get the following error message: The last two lines can be translated to:

You appear not to have the g++ compiler installed. Try

Rich Holmes wrote:You appear not to have the g++ compiler installed. Try

Code: Select all

sudo apt-get update && sudo apt-get install build-essential

Well, since I had already updated the system, I typed only "sudo apt-get install build-essential", and that worked. Thank you. And I can now do parallel processing practically.

Professor and cloverleaf interchange haven't been named in catagolue yet.

It appears Apgsearch doesn't separate pseudo still lifes properly:
https://catagolue.appspot.com/object/xs ... zx11/b3s23
The two boats should be separated as well as the other two.

David wrote:It appears Apgsearch doesn't separate pseudo still lifes properly:
https://catagolue.appspot.com/object/xs ... zx11/b3s23
The two boats should be separated as well as the other two.

That is...strange, to say the least

I have a vague idea:use apgsearch to generate a random string,encode it into a QR code,then treat it like a normal soup in apgsearch.

GUYTU6J wrote:I have a vague idea:use apgsearch to generate a random string,encode it into a QR code,then treat it like a normal soup in apgsearch.

That was my original idea, but I chose SHA-256 for cryptographic security: it's impossible to reverse-engineer (say) a loafer into a trivial predecessor and submit it as part of a haul.

calcyman wrote:

GUYTU6J wrote:I have a vague idea:use apgsearch to generate a random string,encode it into a QR code,then treat it like a normal soup in apgsearch.

That was my original idea, but I chose SHA-256 for cryptographic security: it's impossible to reverse-engineer (say) a loafer into a trivial predecessor and submit it as part of a haul.

No, that is not his idea, I think. I think he means to generate a random string, make a QR code with that random string and use the QR code as the soup.

Saka wrote:

calcyman wrote:

GUYTU6J wrote:I have a vague idea:use apgsearch to generate a random string,encode it into a QR code,then treat it like a normal soup in apgsearch.

That was my original idea, but I chose SHA-256 for cryptographic security: it's impossible to reverse-engineer (say) a loafer into a trivial predecessor and submit it as part of a haul.

No, that is not his idea, I think. I think he means to generate a random string, make a QR code with that random string and use the QR code as the soup.

Yes, that's what I meant. But you can construct a QR code which is also a loafer predecessor, and then compute the string which yields that particular QR code. Then submit a haul to Catagolue containing that string, and the census will mistakenly believe that a loafer has occurred naturally.

calcyman wrote: Yes, that's what I meant. But you can construct a QR code which is also a loafer predecessor, and then compute the string which yields that particular QR code. Then submit a haul to Catagolue containing that string, and the census will mistakenly believe that a loafer has occurred naturally.

Ah, I see

How many distinct 16x16 soups are there of the two different x8 symmetries?

I calculate 2^36, or about 70B.

Haven't we already covered most of this space, with high probability? We are above
the 100B mark for both symmetries.

Or is this just well known and understood and people are focusing on other symmetries?

rokicki wrote:How many distinct 16x16 soups are there of the two different x8 symmetries?

We use 32x32 for those, though.
Edit: Ah , disregard i'm an idiot.

drc wrote:

rokicki wrote:How many distinct 16x16 soups are there of the two different x8 symmetries?

We use 32x32 for those, though.

That's an important point: All symmetries (excl. D8 I think) are based off of a 16x16 soup with additional copies translated, rotated, and superimposed upon each other accordingly.

Is there any limit to the number of soups? I've been running apgsearch for Day & Night [b3678s34678].
The haul of 10000 soups is uploaded, but the haul of 100000000 soups is not.