Blockish and Blockic or blockish and blockic?

[confocaloid]

The question is in the title. I'm normally changing 'blockic' to 'Blockic', but sometimes people change it back.

• The comments to the file 'blockish-and-blockic-seeds.rle' in Golly's pattern collection use 'Blockic' and 'Blockish'.
• The textbook uses 'blockic'.
• Actual people in actual forum discussions used both variants.
  search.php?keywords=Blockic
  search.php?keywords=Blockish

My vote is for 'Blockic' and 'Blockish'.

[HerscheltheHerschel]

Mine is for "blockic" and "blockish" (without capitalization).

[MEisSCAMMER]

Capitalization (Blockic, Blockish) would only make sense if it was a derivative, linguistically, of capital-B Block. Since we're aiming for "of or relating to a lowercase-b block" a lowercase-b "blockic/blockish" makes more sense in my opinion.

[hotdogPi]

No opinion on capitalization, but (B/b)lockic over (B/b)lockish. It's the much more established term. LifeWiki only lists the latter term as part of a file name and has no actual uses.

[haaaaaands]

i stand neutral. both seem good to me.

[dvgrn]

It was "Blockic" when I originally invented it, but I have a tendency to capitalize things that probably shouldn't be capitalized.

"Blockish" was a term I used in a Golly pattern filename as hotdogPi mentions, very early on in the development of slow-salvo construction when I was first inventing constellations made up of turners and splitters that were guaranteed to be buildable with unidirectional slow gliders. "Blockish" referred to the seed on the right side of that pattern, which was predominantly blocks but contained a few beehives also.

Long story short, I had worked out all the recipes for splitting one block into two, and for moving blocks to whatever location they were needed, and I knew how to string those recipes together to make a blockic 1G seed for something complicated like a loafer -- but I didn't have a complete solution for any objects other than blocks. So at the time it was useful to distinguish "Blockic" from "Blockish".

There's one other use of "Blockish" (capitalized), also by me, in the comments for the 1G seed for Riley's breeder.

"Blockish" is clearly not a particularly useful term at this point, with slmake able to build much more difficult constellations than just a few beehives mixed with blocks. Doesn't seem like "blockish" particularly needs a LifeWiki definition, or any particular attention paid to it at all -- maybe just a redirect to "blockic"?

My current opinion about capitalization in general* is that if usage starts out with a capitalized form but evolves to a lowercase form, probably that's a good sign that the term has made its way into common usage -- kind of like "Xerox" turning into "xerox". When "blockic" showed up in the Life textbook without capitalization, I didn't choose to argue for the capitalized form -- I think the term has successfully made that transition.

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

* As usual, there's an exception in my mind for "Snark", because Lewis Carroll always capitalized that. That's kind of inconsistent on my part, because "Boojum reflector" made the lowercase transition to "boojum reflector" vert early on, but Lewis Carroll also always capitalized "Boojum".

I know this is getting terribly off-topic, but here's a quote from a 2002 LifeCA posting with my thoughts at the time about "Boojum" vs. "boojum":

Nick Gotts wrote:

If it had been a boojum, you wouldn't be around to tell the tale!
...
So maybe there *is* a small stable reflector, but anyone who finds
it instantly vanishes! Has anyone known to be "hunting the snark"
disappeared from the Life list without explanation?

I do believe I detect a confusion of levels in the above statement -- so, in all mock seriousness, I feel I should justify my nomenclature. Lewis Carroll, the discoverer (in some sense) of the original Boojum, did not softly and suddenly vanish away, either.

However, as it happens, making things disappear is just about the only use I have found for the boojum reflector (besides glider-loop "timing belt" guns). -- A lowercase 'b' is, I think, appropriate when the word is used as an adjective; for some reason, "Boojum reflector" conjures up an image of something that reflects Boojums. Nonsensical, of course...

To generalize and clarify, then: a Boojum may cause the sudden vanishment of adjacent entities in the same Universe -- be they Bakers, or beehives, or blocks. In the Life universe, boojum reflectors turn out to be quite good at deleting unwanted pieces of nearby glider-emitting patterns (for anything above period 201, anyway).

[confocaloid]

Re: (B|b)lockish - "just a redirect" without explanation would be misleading, because it is not a synonym of (B|b)lockic. If it is not considered common enough to warrant a direct mention, I think it would be better to avoid having any page or redirect for it.

[Haycat2009]

A somewhat related question: Are beacons (which are basically block-ties) allowed as part of a blockic constellation?

[confocaloid]

A somewhat related question: Are beacons (which are basically block-ties) allowed as part of a blockic constellation?

Obviously not. A Blockic constellation is p1. A beacon is p2. No part of a p1 constellation can be p2.

Even bi-blocks or other rectangular block arrays are not Blockic (they are different pseudo still lives).

[Haycat2009]

A somewhat related question: Are beacons (which are basically block-ties) allowed as part of a blockic constellation?

Obviously not. A Blockic constellation is p1. A beacon is p2. No part of a p1 constellation can be p2.

Even bi-blocks or other rectangular block arrays are not Blockic (they are different pseudo still lives).

I understand the beacon part, but the lifewiki definition means that bi-blocks are blockic. Anyway, the block agar is also stated as blockic.

[Haycat2009]

Besides, blockic has been used for longer. It should not be capitalised, as it is an adjective, not a proper noun, and adjectives are never capitalised.

[confocaloid]

I understand the beacon part, but the lifewiki definition means that bi-blocks are blockic.

It does not require that you partition a p1 constellation into strict still lives. If you partition the constellation into pseudo still lives (which makes sense), then bi-blocks are not Blockic.

Anyway, the block agar is also stated as blockic.

Where exactly this is stated? Can you give a link?

[HerscheltheHerschel]

I understand the beacon part, but the lifewiki definition means that bi-blocks are blockic.

It does not require that you partition a p1 constellation into strict still lives. If you partition the constellation into pseudo still lives (which makes sense), then bi-blocks are not Blockic.

Anyway, the block agar is also stated as blockic.

Where exactly this is stated? Can you give a link?

I consider bi-blocks (and all other patches of block agar) as blockic pseudo still lives, so by my definition bi-blocks are allowed in a blockic constellation.

[Haycat2009]

I understand the beacon part, but the lifewiki definition means that bi-blocks are blockic.

It does not require that you partition a p1 constellation into strict still lives. If you partition the constellation into pseudo still lives (which makes sense), then bi-blocks are not Blockic.

Anyway, the block agar is also stated as blockic.

Where exactly this is stated? Can you give a link?

I consider bi-blocks (and all other patches of block agar) as blockic pseudo still lives, so by my definition bi-blocks are allowed in a blockic constellation.

I thought so too.

[confocaloid]

I consider bi-blocks (and all other patches of block agar) as blockic pseudo still lives, so by my definition bi-blocks are allowed in a blockic constellation.

It is clear that this is your definition. But the question is about the established meaning.

Blockic constellations appear in contexts where constructibility matters. The advantage of restricting to constellations that are entirely made out of blocks (i.e. without bi-blocks or other patches of block agar, and without other still lives) is that blocks are very common, and so there is a relatively straightforward way to construct them by a slow salvo aimed at a single initial block, by duplicating blocks and moving them around like this:

Code: Select all

x = 47, y = 22, rule = B3/S23
bo$2bo$3o7$41b2o$41b2o2b2o$45b2o2$24bo$25bo$23b3o5$34b2o$34b2o!

In contrast, constructing a bi-block in this way is harder. For example I just found (using the octo3obj database) this way to add a block near an existing block to make a bi-block, but it requires you to build two more bi-blocks before it will work --

Code: Select all

x = 13, y = 17, rule = B3/S23
3b2o$3b2o5$11b2o$2o8b2o$2o2b2ob2o3bo$4b2ob2o6$5b2ob2o$5b2ob2o!

Constructing larger rectangular patches of block agar would be significantly harder than that (and the general problem of constructing an arbitrary MxN block array is still unsolved).

This topic is covered in chapter 5.7 "Slow salvo synthesis" in the textbook.

[Haycat2009]

I consider bi-blocks (and all other patches of block agar) as blockic pseudo still lives, so by my definition bi-blocks are allowed in a blockic constellation.

It is clear that this is your definition. But the question is about the established meaning.

Blockic constellations appear in contexts where constructibility matters. The advantage of restricting to constellations that are entirely made out of blocks (i.e. without bi-blocks or other patches of block agar, and without other still lives) is that blocks are very common, and so there is a relatively straightforward way to construct them by a slow salvo aimed at a single initial block, by duplicating blocks and moving them around like this:

Code: Select all

x = 47, y = 22, rule = B3/S23
bo$2bo$3o7$41b2o$41b2o2b2o$45b2o2$24bo$25bo$23b3o5$34b2o$34b2o!

In contrast, constructing a bi-block in this way is harder. For example I just found (using the octo3obj database) this way to add a block near an existing block to make a bi-block, but it requires you to build two more bi-blocks before it will work --

Code: Select all

x = 13, y = 17, rule = B3/S23
3b2o$3b2o5$11b2o$2o8b2o$2o2b2ob2o3bo$4b2ob2o6$5b2ob2o$5b2ob2o!

Constructing larger rectangular patches of block agar would be significantly harder than that (and the general problem of constructing an arbitrary MxN block array is still unsolved).

This topic is covered in chapter 5.7 "Slow salvo synthesis" in the textbook.

Technically nobody cares about how constructable the constellation is when talking about blockic. You want constructable, you are in the wrong thread. Blockic is made out of blocks, full stop. And I am going to play your game: The example does not count as you could have picked one of the more complicated ways to add such a block. Anyways, you only need 2 gliders for a bi-block - same as a block.

[confocaloid]

Do you understand the difference between slow salvo construction and an arbitrary glider synthesis?

Anyways, you only need 2 gliders for a bi-block - same as a block.

This topic is covered in chapter 5.7 "Slow salvo synthesis" in the textbook.

[Haycat2009]

Do you understand the difference between slow salvo construction and an arbitrary glider synthesis?

Anyways, you only need 2 gliders for a bi-block - same as a block.

This topic is covered in chapter 5.7 "Slow salvo synthesis" in the textbook.

Constructablility is vague, so how am I supposed to know which context? Anyway, as I said, constructablility is not integral to blockicness.

[confocaloid]

Constructablility is vague, so how am I supposed to know which context? Anyway, as I said, constructablility is not integral to blockicness.

Constructibility is directly relevant to Blockicness, though --

Blockic constellations appear in contexts where constructibility matters. The advantage of restricting to constellations that are entirely made out of blocks (i.e. without bi-blocks or other patches of block agar, and without other still lives) is that blocks are very common, and so there is a relatively straightforward way to construct them by a slow salvo aimed at a single initial block, by duplicating blocks and moving them around like this:
[...]
This topic is covered in chapter 5.7 "Slow salvo synthesis" in the textbook.

[Haycat2009]

Constructablility is vague, so how am I supposed to know which context? Anyway, as I said, constructablility is not integral to blockicness.

Constructibility is directly relevant to Blockicness, though --

Blockic constellations appear in contexts where constructibility matters. The advantage of restricting to constellations that are entirely made out of blocks (i.e. without bi-blocks or other patches of block agar, and without other still lives) is that blocks are very common, and so there is a relatively straightforward way to construct them by a slow salvo aimed at a single initial block, by duplicating blocks and moving them around like this:

Code: Select all

x = 47, y = 22, rule = B3/S23
bo$2bo$3o7$41b2o$41b2o2b2o$45b2o2$24bo$25bo$23b3o5$34b2o$34b2o!

In contrast, constructing a bi-block in this way is harder. For example I just found (using the octo3obj database) this way to add a block near an existing block to make a bi-block, but it requires you to build two more bi-blocks before it will work --

Code: Select all

x = 13, y = 17, rule = B3/S23
3b2o$3b2o5$11b2o$2o8b2o$2o2b2ob2o3bo$4b2ob2o6$5b2ob2o$5b2ob2o!

Constructing larger rectangular patches of block agar would be significantly harder than that (and the general problem of constructing an arbitrary MxN block array is still unsolved).

This topic is covered in chapter 5.7 "Slow salvo synthesis" in the textbook.

Nah. There are easier places to find constructibility, like spartanism. I will not dip to far into that, but you are wrong.

[hotdogPi]

For once, I agree with confocaoid. Bi-blocks don't count as blockic. Removing one cell from a bi-block, hitting a bi-block with a glider, or trying to use the two-block edge of the bi-block as a catalyst doesn't do the same thing as a single block.

[dvgrn]

Constructibility is directly relevant to Blockicness, though ...

Nah. There are easier places to find constructibility, like spartanism. I will not dip to far into that, but you are wrong.

confocaloid is completely correct about the origin of the term. It came into general use because of getting used in contexts like the blockic 1G loafer seed, which was created specifically to be constructible with a limited set of block-splitting and block-moving slow-salvo recipes.

This was long before slmake came along; recipes for large constellations had to be built by hand or with custom-written helper scripts, so keeping things simple was important. Saying "Blockic" in that context was intended to evoke the idea of well-separated blocks in seed constellations. If a bi-block or beacon showed up in one of those constellations, it would have missed the whole purpose of building the seed out of nothing but well-separated blocks.

As usual, the story gets complicated. When the term was originally introduced on the LifeCA newsgroup in 2004, I also defined a whole pile of related terminology that Paul Chapman and I had developed to talk about things like the prototype Spartan universal constructor.

It looks like in 2004 I definitely thought that it was necessary to say "unclustered Blockic" to clarify that bi-blocks weren't allowed (though certainly beacons wouldn't have been relevant):

last night I threw together a decidedly non-minimal "unclustered Blockic 1G starseed". Terminology review:

"Blockic" means the patterns is made entirely of blocks.

"Unclustered" means there are no clusters of blocks, by Nick Gotts definition of 'cluster' from the Life Lexicon: "Any pattern in which each live cell is connected to every other live cell by a path that does not pass through two consecutive dead cells." Obviously every block is a cluster, but in an unclustered Blockic pattern there are no clusters of two or more blocks. [It's much easier to write a very simple and stupid compiler to produce a constructor-ready slow-salvo recipe for an arbitrary unclustered Blockic pattern. A compiler for Blockic patterns in general has to be a good bit cleverer...]

A "seed" is a pattern that, when "germinated" by a glider or a salvo of gliders, produces some target pattern -- in this case, the p3 star from Jason's latest set of syntheses.

And "1G" is a short way of saying that the seed can be germinated with just one glider. So in other words, here is a field of blocks with no shared neighbor cells, that can be converted into a p3 star (plus a few boats which I didn't bother to get rid of) with one glider:

Code: Select all

#C unclustered Blockic 1G starseed Dave Greene 24 Aug 2004
x = 275, y = 275, rule = B3/S23
147boo$147boo4$33boo$33boo113boo$78boo68boo$78boo$28boo23boo$28boo23b
oo$$87boo$51boo34boo53boo$51boo89boo108boo4boo$14boo236boo4boo$14boo$
50boo34boo$50boo34boo$82boo$82boo$14boo$14boo17boo$33boo214boo$23boo
224boo$23boo$84boo$84boo$134boo128boo$134boo128boo$138boo$138boobboo$
142boo95boo$52boo185boo10boo15boo$32boo3boo13boo197boo15boo$32boo3boo
42boo$81boo$239boo$239boo$119boo$50boo67boo$50boo63boo$111boobboo$111b
oo$$74boo$74boo$67boo$67boo14boo$53boo28boo$53boo178boo21boo$233boo21b
oobboo$240boo18boo$224boo14boo22boo$224boo38boo12$178boo$178boo46boo$
226boo$$82boo$82boo3$228boo$228boo3$174boo3boo85boo$174boo3boo85boo$$
191boo45boo$81boo3boo103boo10boo33boo14boo$81boo3boo115boo20boo27boo$
225boo20boo$247boo$169boo5boo13boo63boo$169boo5boo13boo63boo3boo$261b
oo$$120boo4boo$120boo4boo3$78boo$66boo10boo90boo$66boo33boo44boo10boo
9boo$101boo44boo10boo$176boo$78boo37boo57boo$78boo37boo$$101boo53boo$
101boo44boo7boo$147boo$110boo$110boo4$191boo$191boo38boo$231boo$$186b
oo$186boo44boo$232boo3$234boo$234boo5$6boo116boo$oo4boo116boo$oo166boo
$168boo$161boo$120boo39boo14boo$13boo16boo87boo55boo$13boo16boo$186boo
$186boo57boo$30boo147boo64boo$30boo147boo14boo$195boo$243boo$28boo213b
oo$28boo$$242boo16boo$242boo16boo4$273boo$267boo4boo$267boo$$194boo$
178boo14boo$178boo$39boo144boo$39boo144boo3$41boo$41boo$179boo$179boo$
42boo$42boo$157boo29boo$157boo29boo$180boo$180boo$$161boo$161boo25boo$
188boo$173boo$173boo$195boo$195boo$168boo$168boo$207boo$195boo10boo$
195boo$$158boo$158boo3$12boo149boo$12boo3boo63boo79boo$17boo63boo$26b
oo$26boo20boo$19boo27boo20boo115boo3boo$19boo14boo33boo10boo103boo3boo
$35boo45boo$$7boo85boo3boo$7boo85boo3boo$$111boo$45boo64boo$45boo3$
115boo74boo$115boo74boo$$47boo$47boo46boo$95boo4$133boo$133boo3$128boo
$128boo3$9boo38boo$9boo22boo14boo$13boo18boo$13boobboo21boo230b3o$17b
oo21boo178boo50bo$190boo28boo51bo$190boo14boo$206boo$199boo$199boo$$
162boo$158boobboo$158boo63boo$154boo67boo$154boo$34boo$34boo$192boo$
192boo42boo3boo$5boo15boo197boo13boo3boo$5boo15boo10boo185boo$34boo95b
oo$131boobboo$135boo$9boo128boo$9boo128boo$189boo$189boo$250boo$24boo
224boo$24boo214boo$240boo17boo$259boo$191boo$191boo$187boo34boo$187boo
34boo$259boo$15boo4boo236boo$15boo4boo108boo89boo$131boo53boo34boo$
186boo$$220boo23boo$220boo23boo$195boo$125boo68boo$125boo113boo$240boo
4$126boo$126boo!

There are fairly recent uses by other people like Goldtiger997 that seem to use the term with the intention of excluding bi-blocks -- but there again, they often seem to find the need to specifically say "(excluding bi-blocks)" ... as if they are suspicious that the term "blockic" by itself doesn't really sufficiently exclude bi-blocks.

The term that I suggested in ancient days for clarifying this, "unclustered", definitely never made it into common usage. The term I remember using more recently is "well-separated", but that's much less precise than "unclustered" -- in fact it's downright vague, so again it's only useful in context when the discussion involves universal construction.

I'm kind of surprised that one of those clarifying terms didn't make it into the Life Lexicon definition for "Blockic". I don't remember for sure now, but I suspect that in 2018 I still thought that the term didn't exclude bi-blocks without some kind of prefix qualifier like "unclustered". It could be assumed to exclude bi-blocks whenever it was used in the context of universal construction. I have a very vague memory that I might have experimented with nailing down the definition to specifically exclude bi-blocks, but found that any added wording just seemed to make things more confusing.

I was thinking maybe someone like knightlife, in the old "Blockic splitters" or "Blockic seeds" threads on the forums, might have appropriated the term and not really cared about excluding bi-blocks, but offhand I'm not seeing very many constellations in those threads that contain bi-blocks. I do have evidence that I thought of constellations containing bi-blocks as blockish but not blockic. The term I used there for excluding bi-blocks was "pure-Blockic".

-- That all probably just makes things more complicated without really solving the problem. My apologies. Etymology is tricky sometimes.

[confocaloid]

crosspost

• Edit https://conwaylife.com/w/index.php?diff ... did=142301 should be reverted. A block array larger than 1x1 is not Blockic (see viewtopic.php?p=172692#p172692 for context).
• Edit https://conwaylife.com/w/index.php?titl ... did=142300 should be reverted. A bi-block is not a Blockic constellation (see viewtopic.php?p=172692#p172692 for context).

[dvgrn]

... A block array larger than 1x1 is not Blockic (see viewtopic.php?p=172692#p172692 for context).
... A bi-block is not a Blockic constellation (see viewtopic.php?p=172692#p172692 for context).

This is one of the questions that this thread doesn't seem to have decided yet. That context link technically only proves that bi-blocks and such are not "unclustered Blockic" or "pure-Blockic" constellations.

The fact that those prefixes were needed might indicate that plain "Blockic" just means "made out of blocks" -- which is what the Life Lexicon and LifeWiki technically say.

On the other hand, hotdogPi and confocaloid agree that bi-blocks don't count as blockic (or Blockic). I was never sure about that, so I tended to use prefixes like "well-separated" to exclude pseudo-still lifes like bi-blocks. I'm still not sure -- on the fence for the moment, not leaning either way.

I wonder if we're ever going to use pure-blockic patterns to build anything, ever again, now that we have slsparse? Something entertaining like a self-constructing spaceship, maybe? That would be the design where a huge field of blocks gets read by a destructive reading mechanism and copied twice, once at full size (to make the next copy of the data) and once at reduced size (to make a blockic seed containing lots of OTTs and splitters, that gets triggered to build the next copy of the reading mechanism.)

-- Hm. I was thinking that if that existed, that would be a good use for the limited meaning of "blockic. But I guess we could call it just a "blockic spaceship", no matter which meaning of "blockic" is settled on. It would probably be an "unclustered blockic spaceship", because bi-blocks would be harder to make copies of than well-separated blocks -- but that would still be a type of blockic spaceship.

[confocaloid]

In the specific case of block arrays (= rectangular patches of the block agar), I think it is more natural to view the entire M-by-N array as a single (pseudo-)object, rather than as a constellation of objects.

If that is combined with my stance that block arrays (larger than a lone block) don't count as (B|b)lockic, then that means that for me it's much more natural to view block arrays as non-(B|b)lockic pseudo still lives, rather than as "(B|b)lockic constellations". Hence I think pages block array and bi-block should be removed from the category Category:Blockic constellations, because those pages do not belong to that category.

(Currently block array redirects to block agar; the latter is even less of a "constellation" than the former is, due to infiniteness.)