Elementary Conduit Repeat TimesA few elementary conduits, with the naming convention used in this thread, have started showing up on the LifeWiki, mostly due to imports from the Life Lexicon.

The LifeWiki has a place to put a repeat time for each elementary conduit -- and I've been meaning to collect that information for all known elementary conduits at some point anyway, with the idea of eventually producing some kind of Hersrch For The Modern Age.

Wishful Thinking about a New Hersrch-- It would sure be nice to be able to select an output and an input, and tell a search program "I want a stable mechanism to turn this output into that input in T ticks, and it should fit in the empty space in the current pattern, and the recovery time should be R ticks or less." The search should allow H-to-Gs and syringes, and tandem gliders (rarely useful these days but you never know) and G-to-MWSS-to-G conversions and every other reasonable-sized mechanism that we can throw into the library -- along with all the traditional Herschel conduits.

A Small Annoying Problem with StatisticsUnfortunately, the repeat time for converters turns out to not be a terribly easy thing to calculate. You can run a conduit with an R-pentomino input, for example, and then draw in another R-pentomino as soon as the sparks clear, and call that the repeat time -- but in a lot of cases there's not really any way to get an R-pentomino to that location that quickly in practice, because the just-faded sparks would have gotten in the way of the stages leading up to the R-pentomino.

The Same Thing for HerschelsCome to think of it, it really isn't easy for Herschel conduits either, in some cases, but we've gotten along with an approximation so far.

The approximation is that the input Herschel is considered to be "coming from infinity", meaning that the conduit is supposed to work if you prepend something standard to it -- usually a BFx59H. In other words, we're not doing the testing as if the Herschel just magically appears in the input position at T=0.

This really does make a difference a lot of times. If the first natural glider is going to be allowed to escape, especially, then the repeat time is higher because the usual way of evolving a Herschel will conflict with the previous outgoing glider. If it weren't for that detail, several Herschel conduits would have a lower repeat time.

Hypothetical HiccupsThis means that if a new conduit ever shows up that creates a Herschel really quickly, and/or from a different angle than the BFx59H, then we'll have to reduce the ratings of a bunch of existing conduits. Not that that would be so terrible, but -- ugh.

However, until a conduit like that actually shows up, mechanisms with a nominally faster recovery are really going to be useless almost all of the time if they can't recover that quickly when connected to BFx59H. So repeat times measured in a BFx59H context are really very usable in practice.

There's More Trouble If It Ain't A HerschelThe problem is a bit worse for converters in general, because nobody even really knows what the "default" conduit is for supplying, say, a B-heptomino to the BNE14T30, or (better example) an R-pentomino to the RF28B. Quite possibly future conduits will show up that will do a better job of making those deliveries quickly and staying out of the way.

"Instant Appearance" Recovery Time -- a lower boundSo... what should I put down for the recovery time of all these converters from the new Life Lexicon? What I've done so far is to record the IA "instant appearance" recovery time, as I mentioned above. The IA-recovery is the lowest N where an input X can magically appear at the input position at T=0 and then again at T=N ticks (or any number greater than N), and the conduit reliably will work and recover... twice.

I'm not entirely happy with this method, because it gives an unreasonably small number for the RF28B recovery time. If we use IA-recovery numbers everywhere, it seems like it will turn out sometimes that you'll combine two conduits X and Y, with recovery times rX and rY, and you'll find that the recovery time rZ of the combined mechanism will be *higher* than either rX or rY, instead of just trivially equal to max(rX, rY).

(Just like in the Herschel case, it will quite often happen that the slowest-recovering part of the mechanism is right at the connection point between the two joined conduits -- and the IA-recovery measurement doesn't test that connection point.)

I Can't Think of Anything Better -- Can You?But I don't see what to do about it. If I use the current "best known connection" to feed in a converter's input, and measure the recovery time based on that, then we'll likely end up with the opposite problem -- someone will come up with a new conduit X, and now the combination of X and Y will have a recovery rate *lower* than either rX or rY, because rY's recovery rating is outdated as soon as conduit X is invented.

We're safe from this second problem, as long as I use the "instant appearance" method to calculate recovery times. So I might just have to stick with that -- unless anyone has other suggestions. (?)

dvgrn wrote:I Can't Think of Anything Better -- Can You?But I don't see what to do about it. If I use the current "best known connection" to feed in a converter's input, and measure the recovery time based on that, then we'll likely end up with the opposite problem -- someone will come up with a new conduit X, and now the combination of X and Y will have a recovery rate *lower* than either rX or rY, because rY's recovery rating is outdated as soon as conduit X is invented.

We're safe from this second problem, as long as I use the "instant appearance" method to calculate recovery times. So I might just have to stick with that -- unless anyone has other suggestions. (?)

Although it would increase the amount of needed data from O(n) to O(n^2), perhaps we could label the conduit connections by recovery time, instead of the conduits themselves. Measurement of recovery time would start with instant appearance of the first input, proceed through the first output/second input, and end with instant disappearance (or perhaps just suitable eating) of the second output.

(I seem to have a thought process behind this, but I unfortunately can't put it into anything coherent right now.)

Well, I think single conduit requires annotations. Even if you move to n^2, there is still 2 ends to your conduits, so the other connection will also have variable recovery times. I dont think there is a simple solution, either we ignore the problem and define the recovery time as a lower bound, or we explicitly find the best legal connection, as drgrn suggested. My take is that we could acknowledge that defining such a number is arbitrary, and instead define a range (min-max) of recovery time for the best and worse links. This allows us to be reminded of the lack of guaranty on what recovery time of a finished track is by looking at its components alone. Even if we have a single number displayed, it does not tell us what is the optimal connection that allows it anyways. By defining a range instead, you gain a guaranty that any connection have a upper bound on the recovery time. Well, these require to generate *all* *valid* connections, as input and output, which are bound to change with new tracks, but I doubt the range will need to be updated often since the set of precursor for B or H are relatively limited.

Extrementhusiast wrote:Although it would increase the amount of needed data from O(n) to O(n^2), perhaps we could label the conduit connections by recovery time, instead of the conduits themselves.

Jormungant wrote:Well, I think single conduit requires annotations. Even if you move to n^2, there is still 2 ends to your conduits, so the other connection will also have variable recovery times.

Thanks -- this is good short feedback for a painfully long question.

These responses suggest to me that it might be time to put together a semi-automated tester script to build conduit connections. For each X-to-Y conduit, the script should attempt to place every known Y-to-Z conduit... and then drop in an X, simulate for the required length of time, and see if there's a Z in the output location.

So for each X-to-Y conduit, the script will be able to produce a list of all Y-to-Z conduits that trivially connect to it. It will be interesting to see if doing this turns up any useful connections that we haven't noticed.

Similar to Hersrch, we'll need a long list of special cases, where two conduits explode or are otherwise not functional if you naively drop them next to each other, but there's a weld or other adjustment that allows the connection to work after all. So probably the script should also produce a pile of RLE for each conduit, showing failed connections -- and anyone who combs through the failures and can find workable welds, can contribute those solutions to a "CustomConnections" folder.

Anyway, once we have a tester script, it probably makes sense to take the shortest recovery time for all connections starting with Conduit C, and the shortest recovery time for all connections ending with Conduit C. Whichever number is larger, call that the recovery time of Conduit C. There might still be a few weird cases, but they'll be so few and far between that they won't cause a lot of trouble.

-- See any problems with this plan, except for the obvious one where someone has to write the tester script?

I've updated the top of the thread with a fresh copy of the Elementary Conduits collection.

This 17 May 2018 update includes the update by calcyman, plus everything that I was able to go back and find since November that seems able to connect to anything. The conduit compiler script is now officially back in action. It's included in the ZIP file, and it rebuilds the stamp collection when you run it.

The largest number of new additions are in the H-to-G category, which was woefully incomplete. It's probably still woefully incomplete, but less so than before.

-- Anyone care to cross-check the actual H-to-G collection and other sources of H-to-Gs, and point out whatever is still missing? Pretty please with a knightship on top thanks in advance!

Added BFx59H with shillelagh (and hat, and two ways of using eater1s... didn't include aircraft carrier or a bajillion larger still lifes that would work -- one has to stop somewhere. These are all commonly used variants.)

Added H-to-G7 HSW5T105_SW-2T21

Added HNE15T22(90)

Added HF123B

Maybe the most controversial change is that I simplified the names of most of the G(n) input conduits. Without defining which of the two gliders is the "standard" glider that measurements are made from, it's hard to unambiguously define a relative output lane. Recording output timing is similarly difficult because the input is not fixed -- gliders in a tandem pair can come in at many different relative timings.

Even output orientation is hard to define, because gliders can usually come in in either order, and you add or remove the junk still life accordingly. You can mirror G(n)-to-X converters along the input diagonal to switch from one type to the other, and that will change the output orientation.

So for the collection to be complete with the 2016 naming, it would have been necessary to duplicate most of the converters -- original, and then mirror-image, with different names. It seemed simpler to just record the type of the output, and leave it at that. (Maybe we should go back and rethink pi-input conduit naming, along the same lines.)

Sphenocorona wrote:I have a different suggestion for conventions with symmetry-breaking conduits: Instead of naming it "PLxR196H" (ugly) or having both "PR196H" and "PLx196H" listed separately (space consuming and visibly redundant), we can do something else:

Let's refer to both of them as "PRv196H". I used "v" here as an example, it could be some other letter.

By the same logic, this "QL226H"/"QRx226H" would simply just be called "QLv226H" regardless of mirroring:

(By the way, that one wasn't quite shown right in the October 1st version of the collection, I don't know if it's fixed in the new version).

QF116B would have to then be QFv116B, and all symmetry breaking P->X and Q->X conduits would have a "v" in their names when referenced as a pair. Referring to an individual isomer would still be done as QF116B or QFx116B, as in that case the mirroring matters again.

For glider outputs, we could have the south lane forms used in the dual listing, as the FNG is a south glider.

2718281828 wrote:Sorry for posting a lot in this thread but I have no idea if these things are useful or not...

Probably nobody else knows for sure either. It will definitely be "useful" when you can start with a glider or a Herschel, attach various conduits and get to your newly discovered component, and then attach more conduits and get safely back to a glider or Herschel again. Until someone comes up with a complete set of conduits like that, doves and LOMs are both still kind of questionable... but still interesting.

2718281828 wrote:Dove to LOM, seem to be known... It allows for this LOM to LOM... this version might be more useful - it almost allows for a lom based oscillator...

Several versions of that LOM-to-LOM are in Dean Hickerson's oscillator stamp collection. (I didn't know about this ahead of time, just looked up the p124 oscillators because that's where this reaction would have to show up.)

chris_c wrote:Aha. When I see the need for a fast glider in the same direction as a Herschel I always think of this conduit. Hence I came up with this:

...Because it is a variant of F131 that liberates an extra glider, I didn't see it in the H-to-H collection (which only lists the standard F131). The variant should be added on the next update.

Speaking of conduits, Sokwe mentioned that F131 can be split into a H-to-R and R-to-H, but I don't see either of those components in the elementary conduits collection. These should also be added soon.

There are at least five of these H-to-G0 conduits known now -- three in the Elementary Conduits collection, with spacings between gliders of 119, 124, and 324, and the "SW-2T21_SW-2T103" one in this article, and one found by gmc_nxtman a couple of years ago, "NW31T120_NW31T378", with a glider spacing of 258. Neither of the last two have made it into the collection yet -- as usual the ECC is in need of an update.

I define repeat time as the smallest time after placing the initial object that I can place the same object in the same location and still leave the device functioning after both objects have completed their run through the conduit. I have put an X beside BRx161B because the passage of one B through it leaves internal junk, so it is not really a conduit at all.

Freywa wrote:Below I've tried to determine repeat times for the B-to-B conduits currently in the elementary collection...I define repeat time as the smallest time after placing the initial object that I can place the same object in the same location and still leave the device functioning after both objects have completed their run through the conduit.

Thanks! The definition looks reasonable. There are some situations where that method gives too low a number for the repeat time: the second copy works fine if it magically appears at the key location, but there's no possible way for an actual active reaction to place the object at that location without running into sparks.

If you run into that situation too often, it might be worth figuring out some kind of special-case way of rating conduits to not count these magical appearances. But in general if your estimate of repeat time is wrong, it will be on the low side, and that's much better than a wrong estimate on the high side.

Freywa wrote:I have put an X beside BRx161B because the passage of one B through it leaves internal junk, so it is not really a conduit at all.

Well... it's definitely on the awkward side, but it is actually a working extensible diagonal B conduit. The only junk that's left behind is a blinker, and that can get cleaned up by the following B-conduit's output: