• 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

speedcubesite

Member
Joined
Mar 4, 2019
Messages
14
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

Member
Joined
Dec 24, 2015
Messages
1,916
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.)
 

rokicki

Member
Joined
Oct 31, 2008
Messages
270
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

Member
Joined
Jul 6, 2007
Messages
3,557
Location
California
WCA
2006GARR01
YouTube
Visit Channel
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!
 

rokicki

Member
Joined
Oct 31, 2008
Messages
270
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

Member
Joined
Dec 24, 2015
Messages
1,916
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.
 

speedcubesite

Member
Joined
Mar 4, 2019
Messages
14
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:

rokicki

Member
Joined
Oct 31, 2008
Messages
270
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.
 

xyzzy

Member
Joined
Dec 24, 2015
Messages
1,916
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

Member
Joined
Oct 31, 2008
Messages
270
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

Member
Joined
Jul 24, 2019
Messages
129
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

Member
Joined
Jun 4, 2018
Messages
1,320
Location
*Insert Comical Location or Coordinates"
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

Member
Joined
Oct 27, 2019
Messages
4,174
Location
An uncolonized sector of the planet Mars
WCA
2020MAHO01
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

Member
Joined
Jul 24, 2019
Messages
129
the face notation is not meant for scrambles (though as I said the Pochmann method might not scramble fully), it's meant for algorithms
 

GenTheThief

Member
Joined
Mar 18, 2016
Messages
1,658
Location
Illinois, U.S.A.
WCA
2016GEEN01
YouTube
Visit Channel
(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.

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

Member
Joined
Jul 24, 2019
Messages
129
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

Member
Joined
Mar 18, 2016
Messages
1,658
Location
Illinois, U.S.A.
WCA
2016GEEN01
YouTube
Visit Channel
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:

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.
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?
I don't know of any analyses, but here are a few ideas that could be analyzed by looking at the effects of many scrambles: - Number of unbroken CE pairs after N moves, for N up to let's say 200. This should stabilize after a while, and we should find out when it does, and do a few more moves than that. - Average distance to home position for each corner or edge after N moves. This should also stabilize at some point, and the expected value should be easier to compute than the unbroken pairs value.

ron said:
To put it differently: if we would do 100 moves like this, would the Megaminx be thoroughly scrambled?
It looks good to me. I have solved the above scramble a few times, with different solution paths, and it felt normal.

ron said:
Is there any guess about the maximum depth of Megaminx?
I never heard of one.

ron said:
How would the current scrambling and your proposed scrambling compare? Harder, easier, roughly the same?
I think the same or very similar. The above two statistics could help determine which is better (i.e., stabilizes the values earlier).

Now an improvement... I thought I use many more "two fifth" turns than "one fifth" turns when I scramble for practice, and I just checked it and it turns out I do 2/5 turns *exclusively*. And they look better, too.
Try just the first line of the above scramble: R- D- R++ D+ R+ D- R- D- R+ D-
It leaves a large part of the megaminx untouched.

Now undo that and instead do: R-- D-- R++ D++ R++ D-- R-- D-- R++ D--
That's the same but all 1/5 turns turned into 2/5 turns. It has effects all around the megaminx.

I then tried this scramble:
R++ D++ R-- D++ R++ D-- R++ D-- R-- D++
R++ D++ R++ D-- R++ D++ R-- D-- R-- D--
R++ D-- R++ D++ R++ D++ R-- D-- R-- D++
R-- D++ R++ D++ R++ D++ R-- D-- R++ D--
R-- D-- R-- D-- R++ D-- R-- D++ R-- D--
R-- D++ R++ D-- R++ D++ R-- D++ R++ D++
R++ D++ R++ D-- R++ D++ R-- D++ R-- D++
R++ D-- R-- D-- R++ D-- R-- D-- R-- D--
R++ D++ R++ D++ R-- D++ R++ D-- R++ D--
R-- D-- R++ D++ R++ D-- R++ D++ R++ D++
After the first sixty moves, there was not a single unbroken pair left.
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.
Not necessarily. Think about the 3x3 and our usual 25 move scrambles, forbidding parts like LR'L2R. They're a subset of the set of all 25 move algorithms, but their quality is *better*.
jaap said:
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.
Not necessarily. Think about the 3x3 and our usual 25 move scrambles, forbidding parts like LR'L2R. They're a subset of the set of all 25 move algorithms, but their quality is *better*.
I see what you mean. I did indeed skip a few steps between "the set of move sequences this new method generates is a subset of those of the old method" and my conclusion "the scramble length will need to be at least as much as before", and those steps are far from watertight proof. Even so, I don't think it would be reasonable to claim that conclusion was not true.
 
Last edited:

xyzzy

Member
Joined
Dec 24, 2015
Messages
1,916
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:
 
Top