CEOR-Zero - a new variant of CEOR that has even better ergonomics and lower movecount!

[Edde]

Hi everyone!

In this thread I'll present CEOR-Zero, a new variant of CEOR I came up with which achieves the following:
- Better ergonomics, it's possible to do at most only 1 S-move and 1 u-move, the rest is using U, r and R-moves.
- Fewer moves. The exact difference hasn't been calculated but it's certain to be lower. This is when comparing to CEOR using CPLine+extension to build CPFB.
- Fewer algorithms. No more algorithms needed for CPLine.
- Easier CPFB planning.
For the cost of having to do a z' rotation, slightly more advanced tracing and a more intuitive FB building step.

How is this achieved? The trick lies in replacing the CPLine+extension step with a new corner permutation step at the start called "0-move CP", together with intuitive FB. This works by reducing the corners into a state that can be solved by first doing <U, L> moves followed by <U, R>. Now here's the kicker: it's been shown to always be possible to find an orientation where this reduction is already solved (given that you are x2y color neutral or better), thus requiring 0 moves. If not found, only 1 move is needed at most. After this orientation is found, you solve FB using <L, l, U, u, S> moves, except you hold the cube so that these moves become <U, u, R, r, S> and build your FB in the U layer. After it's been built, you do a z'-rotation which places the FB in its usual position. The rest of the corners will now be correctly permuted due to our previous tracing step and you can continue the solve as with standard CEOR.

Yash Mehta has managed to find a tracing system for the 0-move CP step! It's a bit complicated, but works, it's included in the guide linked towards the end of this post. I've also made a small optional extension that one can use to further increase the likelihood of finding a 0-move solution.

In the first step during inspection, the corners are "solved" in what can be described as a "2-phase reduction", this image might help to show what it means.

Now as we can see, if we do a z rotation in the first phase, the <U, L> moves become <U, R>. So we can solve all the corners through doing <U, R> moves, a z' rotation, then <U, R> moves again. This therefor improves ergonomics a bit, avoiding F moves in particular.

Please check out this guide, it has some pictures to further explain how this variant works as well as a tutorial for the tracing system. Edit: and it has some example solves! There are more in the discord server as well.

The variant isn't fully developed, we now have to work on finding algs and techniques for solving the FB as optimally as possible during solves. For now, you'll have to do it intuitively, although there is a suspicion that solving square+pair is more efficient than line+extension (which would be similar to standard CEOR). Hopefully, more applications can be found for 0-move CP as this is possible to adapt for many methods and all N x N puzzles.

Feel free to ask any questions, I hope I explained things well enough. If you want to, you can contact me on discord: "edde_" and/or join the CEOR method discord server.

 

[Edde]

Here's a couple example solves made by Yash Mehta:

F2 U' F2 U F2 U2 L2 U L2 F' R' U2 R' D' U B L' D U
x z' // Inspection
1Swaps: 6-5, 5-2, 4-2
Case: C -> B -> D -> C
z' y2 // Inspection 2
z U' r' u2 r' U' u' R' U' z' // CPFB (8/8)
r2 R U' R r' U' r' U' r' U2 r' // EO-stripe (11/19, 18 with cancellation)
U2 R U R2 U R' U' z' // pF2L (7/26)
U' R2 U' R' U' R U R U R U' R r2 // 2GLL+fix (13/39)

L2 U2 B L2 B' D2 B2 U2 L2 F' D2 L D F R2 B D R2 B2 F2
z' // Inspection 1
Swaps: 6-5, 5-2, skip
Case: E -> A -> F
z y2 // Inspection 2
z u2 r u' R U' S u' R' U' z' // CPFB (9/9)
R2 U R' r U' r U2 r' U2 r' // EO-stripe (10/19)
U2 R U2 R U' R2 U2 R' U2 R' U2 R2 U2 z' // F2L (13/32)
U' R U R' U R U2 R' U R' U' R U' R' U2 R U' // 2GLL (17/49)

The signature aspect here is how CPFB is built completely without any F moves and ends with a z' rotation.

 

[edward_9x]

This is actually so cool
Bump

 

[Fred]

First block after zeroing! Very interesting. I also wonder if this would be useful for any Roux variants.

 

[Edde]

First block after zeroing! Very interesting. I also wonder if this would be useful for any Roux variants.

Yeah, being 0 moves makes it quite easy to adapt for other methods as well, and also for cubes other than 3x3. I actually came up with this idea when trying to implement CEOR for big cubes, as I realized it would be best to build first center in U layer and then do a z' rotation.

 

[Izzymizzymus]

what does ceor stand for :3 ?

 

[Edde]

what does ceor stand for :3 ?

It's a variant of LEOR where you solve corner permutation at the start of the solve, which leads to very good ergonomics. https://www.speedsolving.com/wiki/index.php?title=CEOR check out the wiki page!

 

[Edde]

Update!

After brainstorming and experimentation in the CEOR discord server, we found out that there are 7 options for where you can build FB while still getting solved CP afterwards, This not only makes it easier to build FB as optimally as possible, we will change the "standard" position to be that FB is built in the D layer, Dr, and the CPFB stage is therefor ended with a z rotation in this case.

It may also be that this means we can pick the opposite colors to use as our bottom and left side colors, as seen in the picture.

 

[Edde]

Alright, there's been some huge findings recently, we now have a tracing method that works by simply doing standard CP tracing followed by a choice of rotation and piece choice depending on the case. I discovered it last week and confirmed it just yesterday, Yash Mehta also has a tracing method in the works that also only needs standard tracing! I should also note that the opposite color choice isn't completely correct.

I will update the tutorial relatively soon, but for now, here's a quick explanation:

Quick terminology - a pair of adjacent corners are referred to by the shared layers, so "DR" means DBR+DFR. Furthermore, something like "DR corners" means the corners _meant_ to be in DBR+DFR while "pDR" refers to the position itself, irrespective of what corner is there.

1. Perform the imaginary F move as usual is necessary in order to form 2 adjacent corners, preferably hold the cube so that they will get solved into pDR. (We need to research this a bit so that it can hopefully be avoided)
2. Perform a standard CP tracing of your choice, YruRU and UCPT are the most popular. I believe UCPT might be better here as the intuitive aspect will make things easier afterwards.

Now you'll have two different cases depending on the trace:

• 0 or 3 good pairs: CP is solved for the section, which means we can directly use it as our first phase with the corners next to our DR corners in the solved state as the DL corners. For example if DR is white bottom, blue right, our DL corners are those with white and green, solving them into white bottom, green left. Furthermore, in this case we can choose any of the colors correlating to the 7 FB places for our choice of DL corners. We can also do a y2 rotation and use our previous CPline as our DL corners.
• 1 or 2 good pairs: CP is not solved, this results in a bit more of a restrictive case. Note the lone good/bad case, this will be our DL corners. Now do a "flip", x2 z rotation which swaps the bottom and right side colors, essentially swapping the DR corners. We can now solve the DL corners into pDL (note that we still keep white/yellow as our bottom color despite rotating the cube) and CP will be solved for second phase.

A short explanation how this works:
Let's imagine 4 corner pairs, DL, DR, UL, UR, for the solved state, they are all good, which means DL will have to become good after finishing the first phase. Doing 2gen-moves only affecting 3 pairs can either change them all from good to bad or vice versa, or permute them without changing their respective state. This means we can go from 3 good to 3 bad and 1 good to 2 good, but not between those two cases. The "flip" as described earlier, swaps all 4 pairs good<->bad while not only keeping the corners in the first phase, its case has also not been changed as UL moves can be used to undo the swaps. If we have 1 or 2 good pairs, we can thus do the flip to turn the DR pair into bad, then use <U, L>-moves to change DL+UL+UR into 1 good and 2 bad, place the good pair in pDL which leaves us with 3 bad pairs in UL+UR+DR, meaning second phase has solved CP.

This is an amazing step forward as the lines between the standard method and 0-move CP has been significantly blurred. We can now treat 0-move CP not as an alternative way to handle CP in general, but rather as an alternative to the (albeit short) algs used to solve CP in the traced section. I believe this also opens up the doors for a more "free-floating" way too handle CP where we can more easily pick promising pieces for FB and then adjust accordingly.

In the tutorial, I will most likely archive the info on the previous tracing methods as they're a bit obsolete now. Will mainly wait until Mehta publices an explanation on his tracing method. In the meanwhile, please try this out! I hope this makes more people interested in CP-first methods in general and that this sparks research into more techniques/methods that utilizes this.

 

[Edde]

I've realized my method isn't 100% based off of the standard way to do tracing, only that it uses standard tracing methods for identifying the CP state (which is still way better than previous tracing methods, as this means we know it's doable in inspection and requires very little new knowledge).

However, Yash Mehta's method is, which he calls YruRU-d since it's a bit reminiscent of a CP solving idea for zz-d. He posted the following on the CEOR discord:

Scramble to follow along: D2 L' D2 B' R D B' U L2 U2 B U2 F2 L2 F2 L2 B D2 R'​

Step 1: Find your DBL corner, and orient the cube so that the corner is in DBL and the correct orientation. [In the example scramble I will use the red-green-yellow corner.z y // solve DBL]​

Step 2: Make sure that your DFL corner is NOT in DFL already. If that is the case, find another corner to put in DBL. [In the example case the DFL corner (red-blue-yellow) is in DBR, so we are good to go. For x2y2 neutral solvers, a valid DBL corner will exist in about 99.9% of scrambles, and for x2y neutral solvers, such a corner will always exist except if all corners are already solved (in which case you do not care anyway)]​

Step 3: Now do your usual YruRU tracing to see which corner needs to be swapped with your DFL corner to solve CP. Let's call the location of this "swap corner" P. [In our example, the corner to swap with is orange-green-white, i.e. the corner currently sitting in UFR. Hence P = UFR. Notice that the inspection up to this point is identical to a normal YruRU solve.]​

Step 4: Now the idea is to reorient the cube using an x* or an x2y* such that P ends up in DBR. So if P=UBL, do x2y2; if P=UFL, do x2y; if P=UFR, do x2; if P=UBR, do x (or x2y'); and if P=DBR, do nothing; and if P=DFR, do x'. Your cube is now solvable using <L,U>,<R,U>​

​

Special case 1: If the YruRU tracing gave you a solved CP (i.e. you do not have a swap corner), then use <R,U> moves to either bring the DFL corner to UBL and do x'y2, or bring the DFL to DBR and do y' (requires 1 move to reduce to <L,U>,<R,U> once in every 9 scrambles).​

Special case 2: Sometimes when you bring P to DBR it will also bring your DFL corner to DFR, which means <L,U> moves will never affect it, making FB unsolvable using only <L,l,U,u>. In this case use <R,U> moves to move P to UBR where you will have 2 rotation choices, one of which will always work (requires 1 move to reduce to <L,U>,<R,U> in 13.9% of scrambles).​

[Our example is not a special case, just do x2, the cube is now solvable using LU->RU.]​

The special cases occur in 25% of the scrambles for a fixed valid DBL corner, thus averaging 0.25 moves to reduce the cubestate. Also, this tracing is basically YruRU followed by a rotation, and it has already been shown that doing such tracing in inspection is more than viable.​

​

 

[abunickabhi]

CEOR-Zero has a lot of potential. Thanks for developing it!

 

[sardien]

or join the CEOR method discord server.

Looks super cool! Discord link is unfortunately expired.

 

[Fred]

Looks super cool! Discord link is unfortunately expired.

Join the CEOR Method Server Discord Server!

Check out the CEOR Method Server community on Discord - hang out with 114 other members and enjoy free voice and text chat.

discord.gg

 

[Edde]

Looks super cool! Discord link is unfortunately expired.

Sorry! I didn't know it was possible for people to generate permanent invite links I've updated the original post and the link in the tutorial.

 

[Edde]

CEOR-Zero has a lot of potential. Thanks for developing it!

Thanks! You're welcome I hope people gives it a chance now that there's a much smaller "gap" between standard CP solving and 0-move CP. Before these new tracing methods, there were a strong argument that the complexity of the tracing would make it not worth it, as you'll need to not only do the tracing but at least have some time left. But now it's possible to do it much faster and, for those who already knows CEOR, you can start out with standard tracing then have the choice of solving CPline as usual or do 0-move. It should also be noted that mine and Mehta's tracing methods complement each other rather than "compete" as they handle two different kind of cases (his doesn't work when the choice of CPline corners are adjacent, which mine works the best for).

I also hope this sparks more development of CP-first methods. 0-move CP requires fairly strong blockbuilding skills to take full advantage of, so I believe people doing roux will have an easier time using it in their solves than those doing CEOR (as they've gotten used to CPline->extension). However, there's afaik only B2 that utilizes the solved CP to speed up the SB+CMLL part of the solve. I think it can be even better utilized so I'm trying to work something out but have yet to find anything worthy of making a thread about.

And at last, though this is a bit of an open question but I thought it would be suitable to include in this reply, should I write a wiki page about 0-move CP? There's already a page about CP First where I can obviously write a section about 0-move CP, but I believe this is different enough that a new page could be warranted. Furthermore, while my proposal is (afaik) the first well-defined which has also been made to work, there's a bit of history of similar proposals, mainly in the form of Zborowski's original idea for zz-d and the research put into trying to get it to work.

 

[sardien]

Yes! Descriptions about the method and history sections are more than some wiki pages have!

 

[Edde]

https://edde.github.io/CEORtrainer/

I have now made a trainer! The code for general CPFB exists but I want to test it more before "releasing" it, 0-move FB is also of higher priority. A bit crude and simple, but it works as intended. Takes a couple seconds to load at the start as the prune tables are loaded, but they don't take up that much memory (40 MB in total) and results in near instant scramble generation. Please try it out, tell me what you think of it and try to find bugs as well!

I'll make an analyzer later but it will end up on a separate webpage to make things easier. I also want to do more analysis now and perhaps go through every 0-move FB state (a bit more than 17 million) to get a perfect movecount estimate as well as a god's number.

 

[Edde]

I also want to do more analysis now and perhaps go through every 0-move FB state (a bit more than 17 million) to get a perfect movecount estimate as well as a god's number.

Aight, done this now. Unfortunately I set the search depth a bit low, only up to 11 moves but this resulted in 1604 states not having their solution found. Assuming they're solvable in 12 moves though, this gives an average of 9.306 using only <R, r, U, u, S> including the final z/z' rotation. The solver essentially solves into Dr or Ul and then do z/z' to finish the cpfb. In other words, 8.306 might be more accurate here, since rotations are not technically "turns" and after the cpfb you'll usually have to do some pause for recog. You can also relatively easily do the final move together with the rotation, U+z' and r'+z for example. What do you guys think? Should we say that average movecount is closer to 8.3 or 9.3? Note that this is for a fixed FB as well, so the equivalent for only FB would be 6.7 moves and somewhat generalized CPFB at 7.3 moves.