# Notation questions for megaminx solvers



## speedcubesite (Apr 22, 2019)

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.


----------



## xyzzy (Apr 22, 2019)

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 _n_Rw, _n_Rw2, _n_Rw2', _n_Rw', 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.)


----------



## rokicki (Apr 22, 2019)

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.)


----------



## Lucas Garron (Apr 22, 2019)

Yeah, I've been working with Tom on interoperable standards for puzzles/moves/algs.

I'd like to generalize SiGN notation, which has 

Pretty intuitive semantics for cubes: https://mzrg.com/rubik/nota.shtml
A syntax with a fairly nice (and generalizable) grammar: https://standards.cubing.net/notation/
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!


----------



## rokicki (Apr 23, 2019)

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.


----------



## xyzzy (Apr 23, 2019)

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.



Spoiler: crackpot idea



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.


----------



## speedcubesite (Apr 23, 2019)

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.


----------



## rokicki (Apr 23, 2019)

xyzzy said:


> 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.
> 
> ...



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.


----------



## xyzzy (Apr 24, 2019)

speedcubesite said:


> 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).


----------



## rokicki (Apr 24, 2019)

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++.


----------



## qwr (Jun 22, 2020)

I have always thought Pochmann notation was really unintuitive and another thread suggests it doesn't even scramble the cube fully. So I was thinking of a notation that is most intuitive for 3x3 solvers. 
Prefix-free doesn't seem too important for megaminx in particular.
If we use L/R for top layer front left and front right then we could just use it for bottom layer notation too. So the notation is DL, DR, DBL, DBR, DB, D. 
Or another silly idea: come up with two arbitrary letters for BL and BR. Then all moves would be at most two letters.


----------



## Sub1Hour (Jun 22, 2020)

qwr said:


> I have always thought Pochmann notation was really unintuitive and another thread suggests it doesn't even scramble the cube fully. So I was thinking of a notation that is most intuitive for 3x3 solvers.
> Prefix-free doesn't seem too important for megaminx in particular.
> If we use L/R for top layer front left and front right then we could just use it for bottom layer notation too. So the notation is DL, DR, DBL, DBR, DB, D.
> Or another silly idea: come up with two arbitrary letters for BL and BR. Then all moves would be at most two letters.


This was actually the old scramble system, and it absolutely sucks compared to pochmann style. There is a reason that we dont use this system anymore, not only does it take forever, but it also is very easy to mis-scramble, and megaminx is big enough that we dont need a random state scrambler, random move is just fine.


----------



## ProStar (Jun 22, 2020)

qwr said:


> I have always thought Pochmann notation was really unintuitive and another thread suggests it doesn't even scramble the cube fully. So I was thinking of a notation that is most intuitive for 3x3 solvers.
> Prefix-free doesn't seem too important for megaminx in particular.
> If we use L/R for top layer front left and front right then we could just use it for bottom layer notation too. So the notation is DL, DR, DBL, DBR, DB, D.
> Or another silly idea: come up with two arbitrary letters for BL and BR. Then all moves would be at most two letters.



This is what it used to be, but it takes way longer and is harder, plus I'm pretty sure that we can't make a random state scrambler yet(something I heard-not sure)


----------



## qwr (Jun 22, 2020)

the face notation is not meant for scrambles (though as I said the Pochmann method might not scramble fully), it's meant for algorithms


----------



## Sub1Hour (Jun 22, 2020)

qwr said:


> the face notation is not meant for scrambles (though as I said the Pochmann method might not scramble fully), it's meant for algorithms


People already use that notation for algorithms and has been used since people started solving megaminx.


----------



## GenTheThief (Jun 23, 2020)

qwr said:


> (though as I said the Pochmann method might not scramble fully)


It is known and was known that Pochmann scrambles do not even have the potential to reach all the states of a megaminx. However, it was proved that the scrambles reached enough states and without bias among different groups. It provided easier scrambles, so it was adopted over more traditional face-turning scramblers.



qwr said:


> I have always thought Pochmann notation was really unintuitive


It is also a super intuitive system/really really easy to learn, given that there are actually only two three six moves to do, and one of those sets is dependent on the previous move, so its more of a move group (the U at the end of each line has to follow the clockwise-ness of the previous D move).
But, if you meant that it was bad for algs, then of course it is-- but it's because it's designed for scrambling, not anything else.


----------



## qwr (Jun 25, 2020)

GenTheThief said:


> It is known and was known that Pochmann scrambles do not even have the potential to reach all the states of a megaminx. However, it was proved that the scrambles reached enough states and without bias among different groups. It provided easier scrambles, so it was adopted over more traditional face-turning scramblers.



Do you have a link to this? I'm interested in the mathematics of twisty puzzles.


----------



## GenTheThief (Jun 25, 2020)

qwr said:


> Do you have a link to this? I'm interested in the mathematics of twisty puzzles.



I'm recall reading through the forums and reading a thread where this was discussed. I did a quick google search and found a speedsolving thread and a wca thread on the topic from 2007:








New megaminx scramble notation


I invented and described a new megaminx scramble notation and suggested to use it in competitions: http://www.worldcubeassociation.org/forum/viewtopic.php?t=368 Feedback both from megaminx experts and novices is welcome, the latter are important because judges are often not the experts and...




www.speedsolving.com









World Cube Association


The World Cube Association governs competitions for mechanical puzzles that are operated by twisting groups of pieces, commonly known as 'twisty puzzles'. The most famous of these puzzles is the Rubik's Cube, invented by professor Rubik from Hungary. A selection of these puzzles are chosen as...




www.worldcubeassociation.org





Most of the insightful discussion comes from the WCA thread, which unfortunately has lost its formatting and is very hard to read, so I took the liberty of reformatting the important parts so it's readable. There's also a minimal discussion of actual math.
I don't really see anything about how it reached all states without bias, so that might have been a later discussion. I have a feeling that lucas garron said it, but I don't feel like searching for it since that sounds awful to actually find it.


Spoiler: words






Ron said:


> Hi Stefan, Thanks again for your input. I like your idea a lot! For me only 2 questions remain:
> 1) Can we say anything about the "scientific" state of the scrambling of Megaminx?
> To put it differently: if we would do 100 moves like this, would the Megaminx be thoroughly scrambled? Is there any guess about the maximum depth of Megaminx? How would the current scrambling and your proposed scrambling compare? Harder, easier, roughly the same?
> 2) ...
> Thanks, Ron





jaap said:


> I really like this idea, too. The only question that remains is whether the number of moves in the scramble has to be increased, and if so by how much. It is clear that the set of move sequences this new method generates is a subset of those of the old method, so the scramble length will need to be at least as much as before for an equally fair scramble.
> 
> I'll need to think about that length issue a bit further, though my gut instinct says it shouldn't make much difference. With this new method we can however use much longer scrambles without using more time. I think the 60 moves we do currently is a compromise - as short as we could get away with to get reasonable scrambles, but probably not quite enough to be really fair.
> 
> Here is a really simple scramble length estimation method. The Mexaminx has 120 corner-edge pairs. Assumption: A scramble should be at least long enough that every such pair is likely to be separated at some point. Every move splits 10 of the 120 pairs, or one twelfth. Assuming that during a scramble the corner-edge pairs that have not yet been separated are fairly evenly distributed over the puzzle, every move will split one twelfth of those, leaving 11/12 of the pairs untouched. The number of unsplit pairs after n moves is therefore about 120 * (11/12)^n and this falls below 1 after 56 moves. While 60 moves is likely to split all the pieces up at some point, they might not be separated as much as the average truly random position. This new method, using 90-100 moves or so, will certainly be better. Jaap





Stefan said:


> ron said:
> 
> 
> > 1) Can we say anything about the "scientific" state of the scrambling of Megaminx?
> ...





stefan said:


> jaap said:
> 
> 
> > It is clear that the set of move sequences this new method generates is a subset of those of the old method, so the scramble length will need to be at least as much as before for an equally fair scramble.
> ...





jaap said:


> stefan said:
> 
> 
> > jaap said:
> ...


----------



## xyzzy (Jun 25, 2020)

GenTheThief said:


> I don't really see anything about how it reached all states without bias, so that might have been a later discussion. I have a feeling that lucas garron said it, but I don't feel like searching for it since that sounds awful to actually find it.


Maybe this:








Randomness of altered scrambles


If you took a random state scrambler for 3x3 or 2x2, and then altered the scramble so that any 180 moves (F2, R2 etc.) were turned into 90 clockwise moves (F, R ...), how random would the altered scramble be? Could the scramble still be considered legitimate at all?




www.speedsolving.com


----------

