Wish Lin
Veteran
Wait, so what exactly are these moves’ notation? I am not catching up:
(Clockwise)
45
135
180
(Anti-clockwise)
45
135
Edit: Nevermind.
(Clockwise)
45
135
180
(Anti-clockwise)
45
135
Edit: Nevermind.
Last edited:
SALOW Notation for Curvy Copter.
- Thread starter Sion
- Start date
I'll be making new sheets tonight.
Also when I made the order of importance of sides, I meant for F/B to go in front of R/L 
It doesn't really matter and you can keep it how it is if you prefer though
It doesn't really matter and you can keep it how it is if you prefer though
The images make things a lot more clear, and I'm a fan of the first 
|The images make things a lot more clear, and I'm a fan of the first
Agreed, definitely.
OreKehStrah
Veteran
I think we can simplify scrambles even more if we use slightly different edge notation. We could use LU, LD, FU, FD, FL, FR, RU, and RD, and then just use y2s. Thoughts?
Jumbling would need to be in the scramble, or jumbling moves would be useless in a solve. It's best the cube comes scrambled outside of cubeshape.
I'm thinking 12 normal moves, 6 jumble-swaps, and 6 moves to get it out of cubeshape.
OreKehStrah
Veteran
I don’t think 12 is enough. I think 16-20 would be better. The reason I brought that notation up is that it would really be simple to just do a y2 instead of keeping track of back edges.
I'm with Ore - 12 isn't enough.
More importantly, 6 moves to get it out of cubeshape is not nearaly enough, isn't god's number for getting a position into cubeshape something like 24?
whatshisbucket
Regular
None of those are nearly enough to make the cube reasonably well scrambled. There's a reason this event does and always will take much longer to do than squan.
I think a random state scrambler for a cubeshape puzzle is probably feasible, although a megaminx-style scramble would work just fine as long as it is long enough (say 40-50 moves?) and has several jumble-swaps. At the very least the shape should be chosen at random, since it's quite easy to generate optimal scramble sequences for the entire shape space beforehand. As you can read here (anyone remotely curious about this puzzle should read everything this link has to offer), the farthest shape from cubeshape is 28 moves. which is not so much that it is unreasonable as an official event (although the jumbling is quite difficult).
WRT notation, I think using numbers (FR2 for a ~110 degree clockwise turn from solved) is definitely the most viable notation, since it should be quite obvious to anyone familiar with the puzzle what this notation describes, even without any further explanation.
OreKehStrah
Veteran
I just thought of a way to do that but it might not be the greatest system but it’s worth discussing I think.
Why not use a parenthesis style notation for jumbling? A simple example that picks up where the discussion has been would be at the FR edge. It could be (FR,FU) where the first edge is the partially turned edge, and the second edge is the edge that is turned 180 degrees.
Each edge has six states. If you examine the states on the solved puzzle, one is the solved state, and another is the 180 degree turn state. The other four states of the edge, let’s assume in this case the FR edge still, all have a unique jumble case with FU, FD, RU, or RD.
The first partial turn of FR can jumble turn FD and RU, and affects the left top or bottom right petals of the edge depending on which full turn is done( FD or RU)
The Second PT jumbles FU and RD and these would change the other two petals.
Therefore this notation should be able to cover the four different ways to jumble the edge without any + - / \ etc.
I just thought about this as I read WishLins post so there may be some flaws I haven’t thought of yet, but that’s why we discuss things!
whatshisbucket
Regular
Middle move should be FU.
Wish Lin
Veteran
I have an idea: Why not use 2s? This will distinguish the jumbling notation away from normal notation, thus solving @Sion ’s original concern.
Take UF edge as an example, The six possible positions counting clockwise will be:
UF+
UF++
UF2
UF- -
UF-
No moves
This is super intuitive even to people that haven’t see anything about this(@Sion ‘s version still need to explain the ‘ )
Take UF edge as an example, The six possible positions counting clockwise will be:
UF+
UF++
UF2
UF- -
UF-
No moves
This is super intuitive even to people that haven’t see anything about this(@Sion ‘s version still need to explain the ‘ )
One Wheel
Legend
This makes sense, except that if an edge is not turned it doesn’t need to be notated. So turning clockwise you would go through:
UF+
UF++
UF
UF - -
UF -
No turn (no notation)
whatshisbucket
Regular
Am currently working on a Curvy copter solver to be used in a random state scrambler. Thus far I have examined the scramble space when only the top 4 edges are twisted without jumbling. Average optimal solution is ~13.64 moves with longest being 20 moves from the superflip (only edges are unsolved). Will update as I continue.
EDIT: The above describes phase 4 of the solution, solving the cube once it can be done so with only U edge moves.
Phase 3 is reducing from U edge moves and FR, BL to just U edge moves. This takes ~13.92 moves on average and at most 19.
Phase 2 is reducing from non-D edges to the above listed state. This takes ~13.81 moves on average and at most 20.
The fact that these are all essentially the same is fairly satisfying.
Phase 1 is solving the D edges and centers. This takes ~8.18 moves on average and at most 12.
Thus this reduction solves the curvy copter once it can be done so without jumbling in an average of ~49.55 moves and at most 71 (hence 71 is an upper bound for God's number, which I suspect is between 30 and 40). For reference, the default length for random-move helicopter cube (non-jumbling) scrambles in cstimer is 40 moves.
Note: we can save more than one move on average by doing adjacent edges instead of opposite in phases 2 and 3, but this significantly increases the number of total cases for phase 2 and thus probably isn't worth the one move save (although it does reduce the bound for God's number to 70). In order to do better bounds for God's number doing 3 phases is feasible, but this is not helpful for generating scrambles quickly.
EDIT: The above describes phase 4 of the solution, solving the cube once it can be done so with only U edge moves.
Phase 3 is reducing from U edge moves and FR, BL to just U edge moves. This takes ~13.92 moves on average and at most 19.
Phase 2 is reducing from non-D edges to the above listed state. This takes ~13.81 moves on average and at most 20.
The fact that these are all essentially the same is fairly satisfying.
Phase 1 is solving the D edges and centers. This takes ~8.18 moves on average and at most 12.
Thus this reduction solves the curvy copter once it can be done so without jumbling in an average of ~49.55 moves and at most 71 (hence 71 is an upper bound for God's number, which I suspect is between 30 and 40). For reference, the default length for random-move helicopter cube (non-jumbling) scrambles in cstimer is 40 moves.
Note: we can save more than one move on average by doing adjacent edges instead of opposite in phases 2 and 3, but this significantly increases the number of total cases for phase 2 and thus probably isn't worth the one move save (although it does reduce the bound for God's number to 70). In order to do better bounds for God's number doing 3 phases is feasible, but this is not helpful for generating scrambles quickly.
Last edited:
