CopperSearch

[Alexey_Nigin]

To simeks & everybody:

I performed the following searches using C version of CopperSearch:

Code: Select all

o1
0123
4567
89ab
cdef
ghij
klmn
opqr
stuv
....
stuv
opqr
klmn
ghij
cdef
89ab
4567
0123

Code: Select all

o2
0123
4567
89ab
cdef
ghij
klmn
opqr
stuv
stuv
opqr
klmn
ghij
cdef
89ab
4567
0123

Code: Select all

o3
0123
4567
89ab
cdef
ghij
klmn
opqr
stuv
opqr
klmn
ghij
cdef
89ab
4567
0123

The output files were 500KB, 2MB, and 200KB, respectively. It seems that they contain nothing interesting, although I can't be sure. At least they don't contain the word "spaceship". They primarily consist of tumblers, pentadecathlons + p2, and fumaroles + p2.

I think that the filtering of oscillators should be far more strict. I suggest that periods 1-6,8,10,14-15,30 are declared boring, and all other periods are declared interesting.

To Saka:

I'm not sure I understand your question, but I will try to explain. tumbler.field looks like this:

Code: Select all

.*.....*.
*.*...*.*
*..*.*..*
..*...*..
..ab.cd..

Each of the four variables can be either on or off, giving 16 different combinations. This is the entire search space (1/1). When you tell cs to search, say, the first half (1/2), it will only test the patterns where d is off (or maybe it's a; I don't remember but it doesn't matter). For the second half (2/2), it will only test patterns where d is on. Similarly, for (1/4), it will test patterns where both c and d are off and so on. To find the tumbler, you need to reach the combination where a, b, c, and d are all on, so you will need to search the last part of search space. (1/1), (2/2), (4/4), (8/8), and (16/16) all give the result. As for inputs like search tumbler 0, they are invalid, as you didn't specify the number of parts.

Let me know if this is not what you were asking about.

[HartmutHolzwart]

why would you exclude p10 amd p15 as "uninteresting? Wouldn't you rather exclude oscillators instead?

All small ship with period > 4 are interesting!

[Alexey_Nigin]

why would you exclude p10 amd p15 as "uninteresting? Wouldn't you rather exclude oscillators instead?

All small ship with period > 4 are interesting!

The C program (as well as my version 0.4) distinguishes oscillators and spaceships. The criteria I presented in my previous post should only be used for oscillators. I do not argue that all spaceships with periods other than 4 are notable (simeks, does your program output p2 and p3 spaceships?).

[Saka]

@Alexey_Nigin
I'm not sure what (in the field) is a part

[simeks]

I performed the following searches using C version of CopperSearch:

Those are searches for wide and short ships, and Copperhead have a quite different shape for example. I don't know what shapes are more likely for a high-period ship (assuming all small low-period ships have been found by other means now), but there are many other search areas that could be tried.

The output files were 500KB, 2MB, and 200KB, respectively. It seems that they contain nothing interesting, although I can't be sure. At least they don't contain the word "spaceship". They primarily consist of tumblers, pentadecathlons + p2, and fumaroles + p2.

I think that the filtering of oscillators should be far more strict. I suggest that periods 1-6,8,10,14-15,30 are declared boring, and all other periods are declared interesting.

The amount of output is a problem, I'm considering ways to solve that.
Until then, a suggestion is to sort the resulting output file, to make it easier to scan for unexpected periods.

why would you exclude p10 amd p15 as "uninteresting? Wouldn't you rather exclude oscillators instead?

As Alexey_Nigin stated above, this refers only to oscillators, and the reason is a lot of different variants of the same basic oscillator gets reported, like these:

Code: Select all

x = 69, y = 15, rule = LifeHistory
3A.A27.3A.A27.3A.A$A2.2A27.2A.A28.A2.A$A.2A28.5A28.2A$A.A29.A2.A28.A.
A$A2$.3A29.4A27.4A2$.3A29.4A27.4A2$A$A.A29.A2.A28.A.A$A.2A28.5A28.2A$
A2.2A27.2A.A28.A2.A$3A.A27.3A.A27.3A.A!

To make it feasable to analyse the results manually, we filter some of the most common periods.

Just looking at the period of the end result is a pretty straight-forward idea to implement in a search program, but if we need to start analysing what the different objects in a result is, it gets more complicated.
It might still be worth the trouble to do this, of course...

(simeks, does your program output p2 and p3 spaceships?).

It does. It would also make sense to check for any P4 spaceship where the displacement not one of (2,0) or (1,1), but it doesn't do that yet.

@Alexey_Nigin
I'm not sure what (in the field) is a part

By part, we just mean a particular part of the search space.
For example if the complete search is expected to take 32 hours to run of a single core, then part 5/32 means the patterns that would be tested in the fifth hour of a full search.
It's just simple way to distribute a large search across the different people in a community (or across different cores on the same computer).

[HartmutHolzwart]

I just find it paradoxical that a program/project called "coppersearch" is designed to exclude the copperhead from the solution space. I think the project should be split in two parts:

a) Find small seeds for small medium period oscilllators

b) find small seed for "true" small spaceships excluding oscillators

Would it be feasible to also include things like a switch engine in the solution space?

Even though nothing new was found so far, the project has benefits: We now know more, where there is no small spaceship and we have a new tool. If the tool is only made genereally usable enough, I'm sure people will find new uses the creators didn't imagine.

Just to get this clear: simeks version alrready ran with odd symmetry and didn't find anything?

Cheers,
Hartmut

[Scorbie]

About the flood of results thing: you could see what I have done for RandomAgar:
viewtopic.php?f=9&t=1594&p=23048&hilit= ... gar#p23048

(Scorbie01 is the original randomagar that uses hashes,
src is my tweak to use "oscstring"s instead of hashes.)

It assigns an "oscstring", a string representation of an oscillator for every new one found and saves it to index.txt.
An oscstring contains population difference in consecutive generations.
For instance, the pop of a pulsar is 72->48->56, so the oscstring would be something like:
(48-72) (56-48) (72-56) ---> -24 +8 +16 (sorted in some order that I don't remember.)

Originally RandomAgar saved the hash for each new pattern but it filled with duplicates of the same pattern with a different background.

All the changes I have made to the original program are inside main.cpp.

Hope this helps.