Message #650

From: David Vanderschel <>
Subject: Re: [MC4D] Dimensionality Notation and Other Cubing Terminology
Date: Sun, 08 Feb 2009 00:13:56 -0600

On Saturday, February 07, "Roice Nelson" <> wrote:
>To poke and prod the suggested naming, I want to ask:
>is "4-edge" unambiguous? The dimensionality prefix
>clarifies that we are talking about an edge on a
>4-puzzle. Unfortunately, to me "edge" still has a
>great deal of ambiguity surrounding it. Is it a 2C

No. On a 4-puzzle an edge piece has 3 colors. My
proposal does not leave this ambiguous. See the first
table. It strikes me that this use of a
dimensionality prefix is not even all that useful
because it is likely that, in most contexts where we
want to talk about an edge cubie, we have already
established the dimension of the puzzle. When I have
applied dimensionality to "edge", it was being used as
an adjective in a context more like your use of
"edge-3" below and in which other dimension objects
existed to create the potential for confusion.

>(analogous to edges on the 3^3 because they share the
>same number of colors) Or is it a 3C piece?
>(analogous to edges on the 3^3 because they have n-1
>colors or because "they are in an edge-3 position
>relative to the 3-pile of stickers comprising a
>4-face" - tried to use the suggested terminology of
>the writeup there, not 100% sure I got it right).

Yeah, but you got complicated on what I regard as a
fairly straightforward issue.

>I think one could argue for both, hence I avoid using
>the term "edge" at all (except in the ubiquitous 3D

You could argue for both. However, I don’t like the
ambiguity, so I have chosen one. We can argue about
whether or not my choice was a good one. If folks can
agree about the choice, then the ambiguity disappears.
If you are arguing that the normal interpretation of
the words is at odds with the definition I gave, that
is an objection worth considering. However, I don’t
actually see that. When I elaborate on the sub-k
positions, it seems to me that I am using the term
"edge" in a consistent way across multiple dimensions.

>"Corners" are less ambiguous so I do indulge using
>that label, but I dislike using "face" pieces for
>similar reasons. Why should faces always be 2C
>pieces and edges (n-1)C pieces? Face pieces might
>well be (n-2)C pieces. (Another argument against
>"face" is to avoid it being overloaded, as it is
>already used in the context of puzzle faces.)

Again, use of dimensionality prefixes on cubie type
does not strike me as being a big help. It seems that
your issue has nothing to do with the dimensionality
prefixes or suffixes but with using words like "face"
and "edge" to describe cubie types. However, you are
picking this up in a context where I had not even
started talking about cubies yet. I was not talking
about puzzles. I was talking about an n-cube. I was
talking about naming positions relative to an n-cube.
I was not talking about naming cubie types. As a
matter of fact, looking over the document, I don’t see
anywhere where I was talking about cubie types.

>Yes, the ambiguity is resolved if we all agree an
>"n-edge" always has n-1 colors as in your tables.
>But the terminology is not self-descriptive enough to
>stand on its own, and so we’ll inevitably have to
>answer the question of meaning for new members who
>will ask the question "why ‘edge’?".

So we explain it. This is precisely the purpose of
having such a document to help out newcomers. If you
somehow fail to think this use of the words is
logical, then it is necessary to just take it as an
arbitrary definition. However, I don’t think it fails
to be logical, and I do think a newcomer would have no
difficulty adopting the view offered. It seems to me
that your concern for the newcomer is an argument for
the existence of such a document. If the document
only says what the newcomer could have surmised
without it, then we did not need it for that
particular purpose.

>This is why I have really liked the 1C, 2C, 3C,
>etc. piece type designations that have evolved. I
>find these identifiers extremely useful and clear.
>Bonus that they are short to write out.

Consider this paragraph from the document:

For an order-3 n-puzzle, all the n-cubies'<br>
locations are sub-k positions and there is a<br>
direct correspondence between the number of<br>
stickers on an n-cubie and the sub-level of its<br>
position. I.e., n-cubies in sub-k positions have k<br>
colors. However, for other orders besides 3, it is<br>
still useful to be able to refer to sub-k<br>
positions relative to the puzzle in spite of the<br>
fact that they no longer correspond to n-cubie<br>
positions. Eg., it does not make sense to refer to<br>
a 2-color position relative to an order-2<br>
5-puzzle, but you can refer to a sub-2 position<br>
relative to the 5-puzzle. (For orders other than<br>
3, the cube on which the sub-k positions lie is no<br>
longer of size 2, but this generalization is<br>

I pointed out the correspondence that exists in the
order-3 case. However, I was trying to emphasize that
the sub-k positions do not have to be regarded as
cubie positions. I did not mention "face" or "edge".
I did mention color counts.

I think you have gotten hung up on cubie type names
when what I was talking about was mostly positions
(points) relative to a single n-cube.

I like the "dC" way of speaking myself. ("d" is for
digit.) There is a problem with it, however: I
define the "type" for a cubie as being determined by
the set of locations in the puzzle to which it can be
transported. In this sense, the number of colors is
not sufficient to determine type. There is more to it
than that in higher order puzzles. There is an issue
here. If we use "type" to indicate only the sticker
count, then what should we call the more precise type
that depends on which set of locations the cubie can
occupy. "Subtype"? I would prefer to say that two
cubies are of the same "type" only if they can both
occupy the same position. I would suggest then that
we take the attitude that "dC" is identifying a _set_
of types, all of which have the same number of
stickers. I could also use the word "class" (of
types) in this context. E.g., one could refer to the
"2C class of cubie types" or "cubies with types in the
2C class". There are certainly contexts where the
number of colors is the only issue and subtype can be
ignored. Then "dC" is simply descriptive.

>It is often the case that interesting properties we
>want to observe tend to be associated with piece
>types irrespective of dimension, and these labels
>work well for that. So for example, we can make
>observations like David Smith did "concerning the
>permutations of 2C and 3C pieces on an odd cube".
>How would one say that with the terminology you’ve
>laid out?

As I mentioned, I have no objection to the "dC" way of
identifying sets of cubies. In this case, it is a
good way.

Since I agree that "dC" is an OK way of speaking, I
propose to add a paragraph to describe this

>Maybe with "face and hypoface pieces" (lacking
>dimension prefixes), but who wants to keep coming up
>with and remembering names for new piece types as we
>climb the dimension ladder? Admittedly, (n-1)C is a
>bit clunky compared to n-edge, but is unambiguous and
>the scheme is infinitely extensible.

Again you want to make this be about cubie type names
when, in fact, I was naming subcubes of an n-cube.

Yes, in the order-3 case it may be natural to borrow
those names for cubie types; but I would not
necessarily expect it.

I don’t think it is all that important to have a name
for a sub-2 cube or a sub-3 cube of a 5-cube. But
corner, edge, and face are all very useful. There
have been times when the hypoface concept would have
simplified what I was saying; but it is rare enough
that explaining around is probably OK. (Note that 2C
pieces for the order-3 4-puzzle are in hypoface

>Maybe a mix is in order? Your dimensional prefixes
>plus number of colors, e.g. a "4-2C piece"?

Absolutely. I would never have discouraged it in the
first place. But, again, this is not a very good
example. Well … maybe it is OK. E.g., you might be
comparing properties of 2C pieces in the 4D and 5D

>Also, for those that haven’t seen it, the Rubik
>2Cs "dyads", 3Cs "tryads", and 4Cs "tetrads".
>Thought that was a relevant bit of history here.

Yes. It might have been a good thing had the MC4D
folks picked up on the work of Kamack and Keane when
they started. The "__ads" terminology is not bad and
it is consistent with "dC". Going on to pentads and
hexads is not such a big leap.

That article is very profound. I wish I had read it
many years ago. I have spent a lot of time
rediscovering much of what they had worked out in
detail 27 years ago!

David V.