Universal helix working notes (Completed!)

[biggiemac]

Due to the heads needing to follow so closely in all the shown examples so far I'm also skeptical. It seems possible there is a limitation that scales in size the same way as the period. But if we added a slight obliqueness we might be able to get closer to c/2, since then you can have more than one blinker puffer trail on any given horizontal.

[simsim314]

Yes, that would convince me. But I think the speed limit you can achieve with this method is lower, namely 2c/5.

You're absolutely right! Sorry for the somewhat ignorant response, I had to know better. I now wrote a script, that shows exactly that.

I just calculated the expected shift and step, and saw it to be 2c/5.

Code: Select all

import golly as g 

SL = g.parse("b2o$o2bo$obo$bo!", 9, 0)
Head = g.parse("9$35bo4b3o$34b3o3bo2bo$27b3o3b2obo3bo$27bo2bo2b3o4bo3bo$27bo5b3o4bo$27bo3bob3o5bobo$27bo3bob2o$27bo6b2o$28bobo8b3o$39bo2bo$34bo4bo$34bo4bo3bo$34bo4bo3bo$39bo$34bo5bobo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo8b3o$43bo2bo$34bo8bo$34bo8bo3bo$34bo8bo3bo$43bo$34bo9bobo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo18b3o$34bo18bo2bo$53bo$34bo18bo$34bo19bobo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo$21b3o$21bo2bo9bo$21bo12bo$21bo12bo$22bobo$bo32bo$3o31bo$ob2o30bo$b3o$b3o30bo$b2o31bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo!")
Body = g.parse("o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o!", 34, 151)
Tail = g.parse("$8bo25bo$7b3o24bo$6b2obo24bo$6b3o$7b2o25bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$17b3o14bo$17bo2bo13bo$17bo16bo$17bo3bo$17bo16bo$18bobo13bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$28bo5bo$27b3o4bo$27bob2o3bo$28b3o$28b3o3bo$28b3o3bo$28b2o40$45b3o$44bo2bo$47bo$43bo3bo$47bo$44bobo!", 0, 250)

def Place(dL, dy):
	g.putcells(Head, 0, dy)
	
	for i in xrange(0, (dL + 1) * 12, 12):
		g.putcells(Body, 0, i + dy)
		
	g.putcells(Tail, 0, (dL + 1) * 12 + dy)
	
	return dL * 12
g.new("")
g.putcells(SL)

step = 1
dL = Place(step, 0)
#Place(step, 430 + dL)

SLy = -1186 - 48 * step
period = 3232 + 120 * step 
g.show(str((SLy, period)))

Some trick like keeping the SL in glider form moving forward, will increase the limit - to 0.45, yet 0.5 turned out to be harder than expected. Thanks again.

-----------

Now for my explanation of the problem, although codeholic pointed it out very correctly.

Lets start by the trivial property: by increasing the length of the helix unit by Y we should expect from our current design to have the SL moved by something linear to Y. So lets assume the next helix unit is now moved by Y below, and the SL moved by Y*(large const) or Y*a.

Now, when does the next "reading" occurs? after (Y + Y * a) * 2 ticks, while our SL has moved only by Y*a. So our speed is limited by Y * a / (Y + Y * a) * 2 = 0.5 - 1 / (a + 1) - notice that the parameter a is not length dependent parameter, this is just the property of any such "linear" design.

-----------

This shows that we need something that works above linear i.e we should be able to prolong the helix head and get SL displacement by over-linear function. Or in other words we should have an option to send the SL more forward even when the distance between the helix units is constant.

So how about such an idea: Lets have a stack of these helices that move the signal upwards and leftward, while in parallel we will shoot some *WSS at the moment of our liking. Then a glider will intersect the *WSS at the resulting moment.

This will allow two things:

1. Keep the distance between the helices units constant.
2. Have another "dimension" to work with, that moves faster than c/2.

And this is how we get "super linearity" - we stack more similar helices, instead of prolonging a single helix. This is actually the same idea, but it allows more dense stacking of helices, and thus avoiding the "linearity curse" mentioned above.

Anyone can think of better alternative?

[biggiemac]

How does the signal get from the rightmost green box to the leftmost red one? It would need to be a glider, and the distance that glider has to travel is linear in the overall width, which is itself linear in the desired period. I think that's still limited, and the red box cannot follow as closely behind the green as you believe.

Naively one might just make the final green box much longer so it can advance the signal by further, but of course the maximum length of one of those boxes defines the spacing between units so it doesn't fix the problem.

My understanding is that this can be a very fast oblique helix if you consider only the green boxes made arbitrarily long, and allow the signal to propagate one box right every period. But since the blinker puffer trail defines a length of the unit then it cannot be arbitrarily close to c/2 orthogonal. The way to get c/2 minus epsilon orthogonal requires a distance between units that grows more slowly than the period, ideally a fixed distance but anything sub-linear will do.

[simsim314]

It would need to be a glider, and the distance that glider has to travel is linear in the overall width, which is itself linear in the desired period.

Those rectangles are "helix units" from previous posts. We can make them longer so the glider will need to travel less.

the point is - some of the "weight" is taken by the "broken helix", allowing it to be consistent of as much sub helices as we want, thus removing the linearity constraint on the next "helix bundle".

EDIT In other words the a parameter of each helix bundle of each specific size will be constant, but the longer the helix bundle - the larger the a parameter would be for that bundle.

I'll try to prove it more precisely mathematically and with examples later on..

[biggiemac]

It would need to be a glider, and the distance that glider has to travel is linear in the overall width, which is itself linear in the desired period.

Those rectangles are "helix units" from previous posts. We can make them longer so the glider will need to travel less.

I understand. But their height defines the number of cells between vertically separated units. If you want to make them longer while keeping the number of vertical cells between horizontally separated units fixed, you need to build more columns. And to transfer the signal from the last column back to the first takes a glider traveling the width of the helix.

Everything except moving the signal back to the first column is now bounded only by c/2, which is why an oblique helix looks to be fine. But moving back to the first column sets a new restriction. Unless I'm wrong, in which case please feel free to show a 0.499c helix once it's worked out!

[simsim314]

back to the first takes a glider traveling the width of the helix.

Think of it this way: what percentile of the time, the glider phase takes for very very long helix units? infinitesimal.

But why then is there a limitation on the speed for say bundle of two units? Because when we increase the size of single unit by X, we moved the SL by factor of 2aX where a is the movement factor of SL for single helix (helix1 moves by aX and helix2 by aX), but the distance between units increased by the same X. 2a is still limited, but we increased the limitation now to be 0.5 - 1 / (1 + 2a) for this construction.

Now because we're allowed to use as many helices as we want - the general limitation would be: 0.5 - 1/(1 + ma), with m is the number of helix units in the construction. When m->infinity, the limitation speed->0.5.

EDIT Admittedly trickier than I expected.

EDIT2 Note that a factor for single helix can be made pretty large in around 20 (reaching the speed of 0.45c). But as closer we get to c/2 the more construction is required - special relativity effects in CGOL?

[biggiemac]

Hm. I think I see where I was hung up.

For one, we're talking about it differently. I prefer to think of the helix's limitation as the amount the front end has receded relative to c/2 motion in a single period. This has the advantage of defining the "epsilon" in "c/2-epsilon" very simply: it's the number of cells between vertically separated units, divided by the total period. You seem to prefer to talk about how far the SL is advanced each period, which I feel is more difficult to get a good intuition about because it spends some time traveling via a signal at 2c/3 and some time stationary.

The spacing between units is linear in the length L of the helix unit (for an orthogonal helix). Therefore to shrink epsilon, we need a period more than linear in L. We can do this by having a number of columns proportional to L, but the signal has to transfer between column to column. For more than two columns, there is the problem of the long journey back to the first column.

Now is where I was hung up. In your picture I had seen the top of the rightmost green box and the location of the topmost red box and thought "there's no way a glider makes it that far, the red box would have to be lower." Now I get that the angle is misleading.

Say you made a bunch of those green helix units all aligned horizontally, such that the bounding box is a square of side L. That accomplishes quadratic period delay. Now fast forward to right after the rightmost puffer has finished burning. To get a SL from here (the top right) to the start of the next (currently in the bottom left), it needs to travel left L and up (1/(2v) - 1)L where v is its horizontal speed. This works: a glider or horizontal *WSS can make it without hitting any of the other units on its way.

So a more clear design would have all the helices marked in green on the same horizontal. I am now convinced that it can make arbitrarily fast helices.

[Sphenocorona]

Another theoretical way to maybe get any sub c/2 speed would be to have the fuse laid down by a puffer get burned away multiple times before destroying the puffer, with each burn getting further before running into a ship next to the fuse and stopping. Something would need to follow and re ignite it each time. The time required to reach the puffer after first ignition this way should increase quadratically with increased length. The main concern I have is it might require more complicated components, but the benefit would be that you don't need to make as many of them, keeping the helix small.

Edit: There is the chance possibility however that the debris from each fuse stopping collision could be used to restart it with some passing flotilla, which would make this method very effective. There are some fuse stopping reactions which produce low amounts of debris:

Code: Select all

x = 13, y = 86, rule = B3/S23
2ob2o$b3o$2bo3$b3o$10b2o$10b3o$10b3o$b3o6b3o$9bob2o$9b3o$10bo$b3o4$b3o
4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o4$b3o
4$b3o4$b3o4$b3o!

I would look for a prototype, but I'm away from home right now and typing this entire message on a phone. Manual search is much more tedious with a tiny touch screen as the only interface.

[simsim314]

I am now convinced that it can make arbitrarily fast helices.

Cool! Here is something even more convincing: a script that generates the spoken helix design of arbitrary (valid) speed:

Code: Select all

import golly as g 

gld = g.parse("bo$o$3o!", 46, 90)
SL = g.parse("3o!", 40, 3)
reflectWS = g.parse("2b3o$bo2bo$4bo$o3bo$4bo$bobo!", -18, 119)
SLWss = g.parse("2b3o$bo2bo$4bo$o3bo$4bo$bobo!", 45, 177)
timingWSS = g.parse("2bo$b3o$2obo$3o$b2o!", -17, 123)

Head = g.parse("15bo4b3o$14b3o2bo2bo$7b3o4bob2o4bo$6bo2bo5b4o3bo$9bo5b3o4bo$5bo3bo4bobo2bobo$5bo3bo4b2o$9bo$6bobo10b3o$14bo3bo2bo$14bo6bo$14bo2bo3bo$17bo3bo$14bo6bo$14bo3bobo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo$23b3o$14bo7bo2bo$14bo10bo$14bo6bo3bo$21bo3bo$14bo10bo$14bo7bobo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo18b3o$32bo2bo$14bo20bo$14bo20bo$14bo17bobo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$14bo$14bo$14bo2$b3o10bo$o2bo10bo$3bo10bo$3bo$obo11bo$14bo$14bo2$14bo!")
Body = g.parse("$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo2$5bo$5bo$5bo!", 9, 72)
Tail = g.parse("15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo5bo$15bo4b3o$20bob2o$15bo5b3o$15bobo3b3o$15bobo3b3o$21b2o40$2b3o$bo2bo$4bo$o3bo$4bo$bobo!", -1, 113)
Tail1 = g.parse("15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo21b3o$15bo21bo2bo$15bo21bo$37bo3bo$15bo21bo$15bo22bobo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo15b3o$31bo2bo$15bo15bo$15bo15bo3bo$15bo15bo$32bobo$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo$15bo2$15bo$15bo5bo$15bo4b3o$20bob2o$15bo5b3o$15bobo3b3o$15bobo3b3o$21b2o40$2b3o$bo2bo$4bo$o3bo$4bo$bobo!", -1, 110)


def Place(d, dx, dy, isFirst, isLast, num):
	
	g.putcells(Head, dx, dy)
    
	for i in xrange(0, d * 12, 12):
		g.putcells(Body, dx, i + dy)
		
	g.putcells(Tail1, dx, d * 12 + dy)
	
	if isFirst:
		g.putcells(SLWss, dx, dy + (86 - d * 12) * (num - 1))
			
	if isLast:
		g.putcells(reflectWS, dx, dy)
	else:
		g.putcells(timingWSS, dx, dy)

	return d * 12
   
def PlaceHelix(x, y, step, num):

	dx = x
	dy = y 
	
	for i in xrange(num):
		Place(step, dx, dy, i == 0, i == num - 1, num)
		
		dx -= 57
		dy += 29 - 12 * step

g.new("")
g.putcells(SL)


#p = (96 * num + 24) * d + 1240 * num + 536
#step = 48 * num * d + 620 * num - 6 

#find num for asymptotic speed 
#find d 

speed = float(g.getstring("Please enter speed", "0.48"))
instances = int(g.getstring("How many instances", "30"))

if speed >= 0.5 or speed <= 0:
	g.exit("speed not supported")

num = 1 

while (48.0 * num) < (96.0 * num + 24.0) * speed:
	num += 1

d = 0 

while True:
	p = (96 * num + 24) * d + 1240 * num + 536
	step = 48 * num * d + 620 * num - 6 
	
	if float(step)  > speed  * float(p) - 5:
		realSpeed = float(step) / float(p)
		break
		
	d += 1
	
	if d > 1000:
		num += 1
		d = 0
		

g.show("The helix has " + str(num) + " steps, period = " + str(p) + ", step per cycle = " + str(step) + " real speed = " + str(realSpeed))

for i in xrange(instances):
	PlaceHelix(0, i * (274 + d * 12), d, num)

# d = 0, num = 1: p = 1776, step = 614
# d = 1, num = 1: p = 1896, step = 662
#num = 1, p = 120 * d + 1776, step = 48 * d + 614

#d = 0, num = 2: p = 3016, step = 1234
#d = 1, num = 2: p = 3232, step = 1330

#num = 2, p = 216 * d + 3016, step = 96 * d + 1234

#d = 10, num = 3: p = 7376, step = 3294
#d = 11, num = 3: p = 7688, step = 3438

#num = 3: p = 312 * d + 4256, step = 48 * 3 * d + 620 * num - 6 

#prediction:
#p = (120 * num - (num - 1) * 24) * d + 1240 * num + 536, step = 48 * num * d + 620 * num - 6 

I've also attached the script.

-------------

Anyway all this, is kinda fun but it doesn't look too much practical.

EDIT @biggiemac Sorry for confusing with the drawing... I'm glad you figured it out eventually.

EDIT2 Just attached 0.48c universal helix.

[simsim314]

@Sphenocorona - Very cool idea! And sounds more promising, as you don't need to create somethign so monstrous as helix stairs.

I was actually somewhat inspired by caterloopillar high velocities helix, that bends and prolongs very similarly to my stairs design of the universal helix. But your suggestion seems to be much more compact - and should solve the problem more elegantly.

Just a thought: maybe we can have there binary counter somehow? Having logarithmic design is always somewhat more efficient than root at least for very high velocities.

EDIT On the other hand, why complicating? This quadratic design seems to be elegant and simple enough to even be really practical.

EDIT2 There are plenty of simple variations there. Just by playing, I've found pretty clean destruction and ignition. The main property of this design is that we can just "bulk stalk" all the ignition *WSS at the end, and all the fuse destructors *WSS one after another in very repetitive pattern.

Code: Select all

x = 13, y = 201, rule = B3/S23
8b2o$8b3o$8b3o$7bob2o$7b3o$8bo65$2ob2o$o3bo$b3o2$2bo$2bo$2bo2$2bo6bobo
$2bo5bo$2bo5bo3bo$8bo3bo$2bo5bo$2bo5bo2bo$2bo5b3o2$2bo$2bo$2bo2$2bo$2b
o$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo
2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo
$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$
2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$
2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$2bo$2bo2$2bo$
2bo$2bo!

[simsim314]

Here is one with good repeat time:

Code: Select all

x = 13, y = 338, rule = B3/S23
o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$
o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$
o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$
o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$
o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$
o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$
o$o$o2$o5b3o$o5bo2bo$o5bo$6bo3bo$o5bo3bo$o5bo$o6bobo2$o$o$o2$o$o$o2$o$
o$o5$11bo$10bobo$9bo2bo$10b2o4$6bo$5b3o$4b2obo$4b3o$4b3o$5b2o20$2b3o$
2bo2bo$2bo$2bo$3bobo5$6bo$5b3o$4b2obo$4b3o$4b3o$5b2o20$2b3o$2bo2bo$2bo
$2bo$3bobo!

EDIT

Here is a modified prototype with N^2 internal clock:

Code: Select all

x = 63, y = 557, rule = B3/S23
16b2o$15bo2bo$15bobo$16bo6$41bo4b3o$40b3o3bo2bo$33b3o3b2obo3bo$33bo2bo
2b3o4bo3bo$33bo5b3o4bo$33bo3bob3o5bobo$33bo3bob2o$33bo6b2o$34bobo8b3o$
45bo2bo$40bo4bo$40bo4bo3bo$40bo4bo3bo$45bo$40bo5bobo$40bo$40bo2$40bo$
40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$
40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$
40bo$40bo$40bo8b3o$49bo2bo$40bo8bo$40bo8bo3bo$40bo8bo3bo$49bo$40bo9bob
o$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo
$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo18b3o$40bo18bo2bo$59bo
$40bo18bo$40bo19bobo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$
40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo$27b3o$27bo2bo9bo$
27bo12bo$27bo12bo$28bobo$7bo32bo$6b3o31bo$6bob2o30bo$7b3o$7b3o30bo$7b
2o31bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo
$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo
2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo
$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$
40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$
40bo$40bo$40bo2$40bo$40bo$40bo5b3o$46bo2bo$40bo5bo$40bo5bo3bo$40bo5bo
3bo$46bo$40bo6bobo$40bo$40bo2$40bo$40bo$40bo5b3o$46bo2bo$40bo5bo$40bo
5bo3bo$40bo5bo3bo$46bo$40bo6bobo$40bo$40bo2$40bo$40bo$40bo5b3o$46bo2bo
$40bo5bo$40bo5bo3bo$40bo5bo3bo$46bo$14bo25bo6bobo$13b3o24bo$12b2obo24b
o$12b3o$13b2o25bo$40bo$40bo5b3o$2b3o41bo2bo$bo2bo35bo5bo$4bo35bo5bo3bo
$o3bo35bo5bo3bo$o3bo41bo$4bo35bo6bobo$bobo36bo$40bo2$40bo$40bo$40bo$2b
3o$bo2bo35bo$4bo35bo$o3bo35bo$o3bo$4bo35bo$bobo36bo$40bo2$40bo$40bo$
40bo$2b3o$bo2bo35bo$4bo35bo$o3bo35bo$o3bo$4bo35bo$bobo36bo$40bo2$23b3o
14bo$23bo2bo13bo$23bo16bo$2b3o18bo3bo$bo2bo18bo16bo$4bo19bobo13bo$o3bo
35bo$o3bo$4bo35bo$bobo36bo$40bo2$40bo$40bo$40bo2$40bo$40bo$40bo2$34bo
5bo$33b3o4bo$33bob2o3bo$34b3o$34b3o$34b3o$34b2o40$51b3o$50bo2bo$53bo$
49bo3bo$53bo$50bobo45$46bo$45b3o$44b2obo$44b3o$44b3o$45b2o20$42b3o$42b
o2bo$42bo$42bo$43bobo7$46bo$45b3o$44b2obo$44b3o$44b3o$45b2o20$42b3o$
42bo2bo$42bo$42bo$43bobo7$46bo$45b3o$44b2obo$44b3o$44b3o$45b2o20$42b3o
$42bo2bo$42bo$42bo$43bobo7$46bo$45b3o$44b2obo$44b3o$44b3o$45b2o20$42b
3o$42bo2bo$42bo$42bo$43bobo!

Pretty surprising that it costs only 4 *WSS for single cycle.

[simsim314]

OK quadratic helix approach proposed by Sphenocorona is finished (thanks again). The quadratic helix is actually practical.

Here is a script that generates any valid speed helix (actually somewhat higher speed, but the distance between the helix units can be adjusted).

Just run in golly:

Code: Select all

import golly as g 

SL = g.parse("b2o$o2bo$obo$bo!", 9, 0)

Head = g.parse("9$35bo4b3o$34b3o3bo2bo$27b3o3b2obo3bo$27bo2bo2b3o4bo3bo$27bo5b3o4bo$27bo3bob3o5bobo$27bo3bob2o$27bo6b2o$28bobo8b3o$39bo2bo$34bo4bo$34bo4bo3bo$34bo4bo3bo$39bo$34bo5bobo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo8b3o$43bo2bo$34bo8bo$34bo8bo3bo$34bo8bo3bo$43bo$34bo9bobo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo18b3o$34bo18bo2bo$53bo$34bo18bo$34bo19bobo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo$21b3o$21bo2bo9bo$21bo12bo$21bo12bo$22bobo$bo32bo$3o31bo$ob2o30bo$b3o$b3o30bo$b2o31bo!")
Body = g.parse("o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o$o$o2$o!", 34, 107 + 12)
Tail = g.parse("34bo$34bo$8bo25bo$7b3o$6b2obo24bo$6b3o25bo$7b2o25bo2$34bo$34bo$34bo2$17b3o14bo$17bo2bo13bo$17bo16bo$17bo3bo$17bo16bo$18bobo13bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$28bo5bo$27b3o4bo$27bob2o3bo$28b3o$28b3o3bo$28b3o3bo$28b2o40$45b3o$44bo2bo$47bo$43bo3bo$47bo$44bobo!", 0, 147)

Eater1 = g.parse("3o$o2bo$o$o3bo$o3bo$o$bobo!", 40, 161)
Eater2 = g.parse("2b3o$bo2bo$4bo$o3bo$o3bo$4bo$bobo!",-16, 208)

Igniter = g.parse("$5bo$4b3o$3b2obo$3b3o$3b3o$4b2o20$b3o$bo2bo$bo$bo$2bobo!", 35, 274)

def PolyEstimate(x, xs, ys):
	
	result = 0.0 
	
	for i in xrange(len(ys)):
		product = ys[i]
		
		for j in xrange(len(xs)):
			if i == j:
				continue
				
			product *= (x - xs[j]) / (xs[j] - xs[i])
	
		result += product
		
	return result
		
def Place(dL, dx, dy):
	g.putcells(Head, dx, dy)
	
	for i in xrange(0, dL * 12 + 12, 12):
		g.putcells(Body, dx, i + dy)
		g.putcells(Eater1, dx, i + dy)
		g.putcells(Eater2, dx, i + dy)
		
	for i in xrange(0, dL * 36 + 36, 36):
		g.putcells(Igniter, dx, i + dy + dL * 12)
		
	g.putcells(Tail, dx, dL * 12 + dy)
	
	return dL * 48 + 362
	

#step:0 - dY:1134, iter:2992
#step:1 - dY:1898, iter:4616
#step:2 - dY:2854, iter:6624

xs = [0.0, 1.0, 2.0]
ys = [1134.0, 1898.0, 2854.0]
iters = [2992.0, 4616.0, 6624.0]

speed = float(g.getstring("Enter Speed", "0.48"))

if speed >= 0.5 or speed < 0: 
	g.exit("not valid speed")

step = 0.0

while True: 
	ny = PolyEstimate(step, xs, ys)
	np = PolyEstimate(step, xs, iters)
	
	if ny / np > speed:
		break
	else:
		step += 1.0

step = int(step)
g.show("number of cycles = " + str(step) + " , step = " + str(int(ny)) + " period = " + str(int(np)) + " , speed = " + str(ny / np))


g.new("")

g.putcells(SL)
dL = 0 

for i in xrange(30):
	dL += Place(step, 0, dL)

Also attached 0.49c example.

Any other ideas? Maybe logarithmic timer?

[Sphenocorona]

I think it's worth noting two ideas - one is that you can put a few of the fusestoppers up along with the cleanup *WSSes, which is beneficial since putting the *WSSes as close to the puffer as possible will yield the longest burn time.

Since the fuse-stopping reaction liberates a glider, that glider could be useful. This probably can't be easily used to produce a pseudo-period firing helix (though it'd be amazing if it can!), but it could act as a sort of built-in fan-out device, with each fusestopper producing its own separate high period stream. Thus you can get a fan-out reaction for the spaceship by simply not including a spaceship in the helix to catch that glider. You might also be able to cut down helix construction by killing/hitting them with glider streams from within the spaceship... and that could also be used to kick off the high-period loop in the spaceship that is necessary to produce the helix.

Logarithmic burn time would be wonderful, but a binary counter style method sounds like trying to find another G+half-bakery reaction, but with a 2c/3 fuse and a flotilla.

One thing I'm wondering is, are these new design methods more efficient for (13,1)c/31? It shouldn't be hard to get the sideways movement figured out I think, but would it make that spaceship plan practical?

[codeholic]

Congratulations!

I really hope there is further optimization possible, otherwise a spaceship built with this technology has good chances to outrun the caterpillar in the controversial nomination of an interesting pattern with the most active cells

[simsim314]

I think it's worth noting two ideas - one is that you can put a few of the fusestoppers up along with the cleanup *WSSes, which is beneficial since putting the *WSSes as close to the puffer as possible will yield the longest burn time.

It's definitely a good idea - I was concerned with "order of magnitude" effects, and less with optimizing it fully for the "best practice".

Since the fuse-stopping reaction liberates a glider, that glider could be useful.

There are plenty of gliders stopped with special *WSS made just for this purpose, you can just remove any of them, for example:

Code: Select all

x = 57, y = 305, rule = B3/S23
10b2o$9bo2bo$9bobo$10bo6$35bo4b3o$34b3o3bo2bo$27b3o3b2obo3bo$27bo2bo2b
3o4bo3bo$27bo5b3o4bo$27bo3bob3o5bobo$27bo3bob2o$27bo6b2o$28bobo8b3o$
39bo2bo$34bo4bo$34bo4bo3bo$34bo4bo3bo$39bo$34bo5bobo$34bo$34bo2$34bo$
34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$
34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$
34bo$34bo$34bo8b3o$43bo2bo$34bo8bo$34bo8bo3bo$34bo8bo3bo$43bo$34bo9bob
o$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo
$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo18b3o$34bo18bo2bo$53bo
$34bo18bo$34bo19bobo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$
34bo2$34bo$34bo$34bo2$34bo$34bo$34bo2$34bo$34bo$34bo$21b3o$21bo2bo9bo$
21bo12bo$21bo12bo$22bobo$bo32bo$3o31bo$ob2o30bo$b3o$b3o30bo$b2o31bo$
34bo2$34bo$34bo$34bo2$34bo$34bo$8bo25bo$7b3o$6b2obo24bo$6b3o25bo$7b2o
25bo2$34bo$34bo$34bo2$17b3o14bo$17bo2bo13bo$17bo16bo5b3o$17bo3bo18bo2b
o$17bo16bo5bo$18bobo13bo5bo3bo$34bo5bo3bo$40bo$34bo6bobo$34bo$34bo2$
34bo$34bo$34bo2$34bo$34bo$34bo2$28bo5bo$27b3o4bo$27bob2o3bo$28b3o$28b
3o3bo$28b3o3bo$28b2o40$45b3o$44bo2bo$47bo$43bo3bo$47bo$44bobo45$40bo$
39b3o$38b2obo$38b3o$38b3o$39b2o20$36b3o$36bo2bo$36bo$36bo$37bobo!

Logarithmic burn time would be wonderful

Thinking of it again - we don't need logarithmic design. We needed anything super-linear and simple. Unless someone will need a ship with 0.49999999 speed, there is no point in generating logarithmic design.

One thing I'm wondering is, are these new design methods more efficient for (13,1)c/31? It shouldn't be hard to get the sideways movement figured out I think, but would it make that spaceship plan practical?

I've an idea of adjustable high speed oblique ship of any slope, but it doesn't work for anything orthogonal. Check out this post.

I think it's worth noting two ideas

Another idea worth noting - is that fine tune of period and step is possible.

Increasing the period can be done by increasing the distance between the reading heads, and increasing the SL step can be done by delaying the glider conversion into SL.

[simsim314]

Congratulations!

Thanks! Do you think this worth an article in wiki? In wiki we don't have anything about helices at all. Helix and fuse are similar, and yet helix has specific context used in constructed spaceships.

I really hope there is further optimization possible, otherwise a spaceship built with this technology has good chances to outrun the caterpillar in the controversial nomination of an interesting pattern with the most active cells

You're probably referring to my first monster with stair design. The quadratic design is much more compact.

EDIT I would argue that the quadratic design has a chance to be even smaller than the caterpillar, as it has less *WSS in total. If we count the puffer as 4 *WSS - we have 15 *WSS per period. Also giving it some boost costs only extra 4*N *WSS, allowing high speeds at minimal cost.

[codeholic]

Do you think this worth an article in wiki? In wiki we don't have anything about helices at all.

Yes, I think it totally makes sense. Starting with a glossary article might be a good idea. Here is a good definition by Brett. It doesn't mention c/2 puffers, though...

You're probably referring to my first monster with stair design. The quadratic design is much more compact.

Sure, it is. But periods are still huge. And it means that tape reading operations will be very rare. In turn, that means that the partial helix being constructed will be extremely long. So unlike the caterpillar, the most population will be not in the spine, but in the helix.

[BlinkerSpawn]

I understand that the speed could be set arbitrarily close to c/2, but what's the lower bound on speeds for the caterpuffer?

[simsim314]

It doesn't mention c/2 puffers, though...

So you're suggesting a new topic? Or just an addition about helices in Brett's thread? I thought of something basic like the fact that such thing even exists.

But periods are still huge. And it means that tape reading operations will be very rare.

Caterloopillars don't work with any period under 900 ticks, and the highest period I'd built is about 10K (5c/21), and caterloopillars design is quadratic relative to the period.

While for this helix the minimal period is only 1776 (and step 614). Notice that speed 0.4c is already pretty high.

Obviously getting so close to 0.5c will force it to work with higher periods, but even speed like 0.48c is in 20K range - nothing too dramatic.

Is there any specific need to build examples of ships in extremely close proximity to 0.5c? There is no theoretical meaning in the difference between speed of 0.49c over 0.4999c... nothing special will be proven by some specific very high speed ship.

[simsim314]

I understand that the speed could be set arbitrarily close to c/2, but what's the lower bound on speeds for the caterpuffer?

None. You can increase the distance between the units as much as you want, this will decrease the speed. The problem is to reach high speeds, low speeds are pretty trivial (especially under c/4).