• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 35,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Notation questions for megaminx solvers

Joined
Mar 4, 2019
Messages
7
Likes
5
Thread starter #1
I'm trying to formalize a notation for N-minx style puzzles (kilo, mega, giga...) so I can add them to the speedcube site. I've looked around a bit, and I'm not sure if existing notation systems will fit my needs. Rather than try to solve this problem myself, I figured I'd post here to see if anyone knows of a spec that might work, or maybe help me come up with one.

I see that the WCA uses Pochmann's notation system, which seems sufficient for scrambling, but I don't think it will be a good fit for scs because players need to be able to set up keybindings that feel like the finger tricks they're already use. With that said, here are (I think) all of the requirements...

1. It needs to be able to turn all 12 faces. I don't want users limited to what key bindings they can set up, I want there to be nothing in the way of performing an algorithm exactly the way that feels best.
2. Control turning depth and allow for both "slice" and "wide" style turns. I hope to support everything from kilominx to teraminx, so turns will have to be able to rotate any specified layer depth.
6. Rotate the entire puzzle along any of the 6 axes.

I think something like cube notation might work, but I hit a wall when trying to think of letters to represent the faces. You can see some of my ideas on what that might look like here, but I'm not satisfied with it. It would result in turns that looks relatively normal like "R+", to something that looks ridiculous like "2DBRw++".

Sorry if this was a rambling post, I'd really appreciate any help coming up with a notation system to use.
 
Joined
Dec 24, 2015
Messages
1,500
Likes
959
#2
Why not just adapt SiGN/WCA notation? You have a list of face names already (I think "B" is better called "DB", just so all the faces on the bottom hemisphere are D-prefixed, but that's subjective), and you can just call the moves nRw, nRw2, nRw2', nRw', etc.

The only drawback of a SiGN-like notation is that there's no "obvious" way of notating the extra-wide moves as used in Pochmann scrambles, but I don't imagine those are especially useful outside of scrambling. Whole-puzzle rotations are also kinda annoying; the notation I used was the WCA-style [r] to represent turning clockwise along the R-DBL axis, etc. (Note that whole-cube rotations on n×n×n aren't even fully covered by notation either; a rotation around a corner or an edge (these show up a lot when you look at fast big cube people) can't be represented by a single token, but need at least two.)
 
Joined
Oct 31, 2008
Messages
269
Likes
14
#3
I'm also interested in this. For twizzle (see https://twizzle.cubing.net?puzzle=megaminx) I tried to find reasonably standard face names (U F L R BL BR) but for the other six faces I just had to make things up. Other than this, I believe that code is SiGN-standard and should support layered turns and rotations. (You can see the face names I picked by hovering over a face; you may have to wait a second for the hover title to show.)

I also have some thoughts on rotations around corners and edges. I plan to use edge and vertex names followed by "p" (suggested as a possibility by Lucas Garron). So UFp would be a minimal (180 degrees in this case) rotation around the UF edge. The corner names can get a little unwieldy (UBLBRp' for a full-puzzle negative rotation around the U-BL-BR corner). Twizzle does not yet support these style rotations (though you can do full-puzzle rotations with, for instance, 3u for the megaminx.)
 
Last edited:

Lucas Garron

Moderator
Staff member
Joined
Jul 6, 2007
Messages
3,556
Likes
91
Location
California
WCA
2006GARR01
YouTube
LucasGarron
#4
Yeah, I've been working with Tom on interoperable standards for puzzles/moves/algs.

I'd like to generalize SiGN notation, which has
However, it's not obvious what is the best way to generalize to puzzles that have a lot of face, or need combinations of faces to name edge/corner moves. (Or turn corners instead of faces! e.g. Pyraminx, Skewb, octahedral puzzles.) Pochmann notation also doesn't naturally fit with it.

I've given rotations a lot of thought, and the "best" I've found so far is to us suffixes as Tom mentions above.

Overall, I don't care so much about the details, but I'd love to have a de facto standard that is compatible with most use cases!
 
Joined
Oct 31, 2008
Messages
269
Likes
14
#5
To continue this discussion: In twizzle, face names are sequences of uppercase letters that must be prefix free. (That is, no face name is a prefix of another face name.) This allows face names to be concatenated without ambiguity (you can always decompose appended face names uniquely.) Edges are then a pair of face names; corners are a clockwise concatenation of face names. This, along with SiGN notation (and now p) gives us a relatively clean notation for moves and rotations, for many types of puzzles. [Alternatively, separate face names with an underscore when naming edges and corners.]

Coming up with face names that make sense might be tough; the icosahedron has 20 faces, so I doubt there are simple single-character face names that are easy to memorize and use. And, keybindings for UIs might not reflect face names at all but instead correlate with finger movements and/or spatial layout, with perhaps a mapping layer to convert from keys to notation.

As the original poster says, perhaps the key issue is assigning face names. Would anyone be willing to propose a strawman naming for dodecahedron faces that is prefix-free? I'm not proud of the bottom half face names I'm using in twizzle.
 
Joined
Dec 24, 2015
Messages
1,500
Likes
959
#6
Wanting prefix-freeness certainly makes this a much harder problem…

U / L / F / R / BR / BL are pretty much standard. This rules out any of U, L, F, and R as prefixes, and we can't use a standalone "B" either.

D / DFL / DFR / DBR / DB / DBL are my preferred names for the bottom faces, but this won't work by itself. We could rename "D" to "DD" and "DB" to "DBB" (or "BD"), which isn't especially intuitive.

Alternatively, rather than focusing on a top-bottom split (all the bottom-half faces have a "D" prefix in the above naming scheme), we could also use a front-back split: FF, FU, FR, FDR, FDL, FL / BB, BD, BR, BUR, BUL, BL.

Rotate the dodecahedron so that we have an edge on the top and an edge in the front. (E.g. for a standard colour scheme megaminx, starting from white-top-green-front, rotate it so that the white-green edge is on top, and the light blue-cream edge is in front.) Then we can pair up adjacent faces, so there are two faces on "U", two faces on "D", two faces on "L", etc.; these can be distinguished by using the axis they differ on. With the standard colour scheme, these are the names of the faces and their colours:

UB: white
UF: dark green
DF: grey
DB: light green
LU: purple
LD: orange
RD: pink
RU: red
FL: light blue
FR: cream
BR: dark blue
BL: yellow

Very consistent and logical, but has little in common with how we normally call the faces.
 
Joined
Mar 4, 2019
Messages
7
Likes
5
Thread starter #7
Why don't your preferred names for bottom faces work by itself? I'm not sure I follow a reason to use "DD" instead of "D". I'd be curious to hear more of your reasoning on this, because I like where you're going. The syntax would still be easily human-readable and terse. Also, I like the convention of using "2" and "2'" to indicate double turns vs "++" and "--". It looks much more natural in my opinion.
 
Last edited:
Joined
Oct 31, 2008
Messages
269
Likes
14
#8
Wanting prefix-freeness certainly makes this a much harder problem…

U / L / F / R / BR / BL are pretty much standard. This rules out any of U, L, F, and R as prefixes, and we can't use a standalone "B" either.

D / DFL / DFR / DBR / DB / DBL are my preferred names for the bottom faces, but this won't work by itself. We could rename "D" to "DD" and "DB" to "DBB" (or "BD"), which isn't especially intuitive.
[/spoiler]
I do like the names; as you say only D and DB cause issues. If we drop the prefix-free requirement we can use underscores for edge and vertices.

I have to admit my bias: I want something that works for most puzzles, even those that are edge-turning and vertex-turning, and I want a simple consistent naming scheme for moves and rotations that derives only from face names. It doesn't have to necessarily be keyboard friendly (that is, it might not map directly to a keyboard-based UI) but it should be reasonably concise and readable.

The harder cases are things like edge and vertex turning puzzles, especially in dodecahedron or icosahedron forms. But even the Skewb is somewhat problematic.
 
Joined
Dec 24, 2015
Messages
1,500
Likes
959
#9
Why don't your preferred names for bottom faces work by itself? I'm not sure I follow a reason to use "DD" instead of "D". I'd be curious to hear more of your reasoning on this, because I like where you're going.
The set of names wouldn't be prefix-free, since "D" is a prefix of the other bottom-half faces' names. As rokicki said, being prefix-free is a nice property to have, but it's not really essential (we could use hyphens, underscores, commas, or whatever as delimiters instead of directly concatenating face names).
 
Joined
Oct 31, 2008
Messages
269
Likes
14
#10
We could support both; in puzzles where the face names are prefix-free (like the cube), direct concatenation could be used (so the helicopter cube would be reasonable) but in puzzles where the face names are not prefix-free (like here) underscores could separate face names. Some of the full-cube-rotations around corners would be long but absolutely decipherable. And, underscores might always be legal for
clarity if desired.

If we go this direction I think the proposed face names for megaminx are reasonable and usable. We still need to resolve the current WCA scramble notation vs these face names, though. The 'normal' name for "R++" would be 2dfr2, I believe, but people are used to R++.
 
Top