Fixing 4x4 edge flip parity after redux - fastest/shortest alg

[Cride5]

As a ZZ user looking to get into 4x4, I've been trying to find a nice way to solve the 4x4 by doing EO after reduction. The idea would be to do just EO inspection, and solve the line after EO (and/or EO parity). My inspecction time for EO (without the line) is probably quick enough for this approach to be practical.

So what I'm looking for is the shortest sequence of moves which change an odd-number of flipped dedges into an even number, while maintaining the edge pairs and centres. The alg must not permute the centres (relative to each other), but may permute the dedges and corners in any way.

I'm not sure if this is the best way, but my preferred system for measuring 4x4 movecounts from a speedsolving perspective is block turn metric.

I'm aware of (and have had a good read of) these threads:
http://www.speedsolving.com/forum/showthread.php?t=17839
http://www.speedsolving.com/forum/showthread.php?t=15614

.. and so far the shortest sequence appears to be:
r U2 r' U2 r' D2 r D2 r' B2 r B2 r' (13 btm)

Along with its derivatives:
r U2 r' F2 l' B2 l B2 l' D2 l D2 l'
r U2 l' U2 r' B2 l B2 r' B2 l B2 l'
r U2 l' U2 x' r' U2 l U2 r' U2 l U2 l'

Found here:
http://www.speedsolving.com/forum/showthread.php?p=303819#post303819
http://www.speedsolving.com/forum/showthread.php?p=309415#post309415

 

[riffz]

So once you inspect for EO and determine that there is an odd number of flipped edges, you're going to perform an alg to fix it and then inspect AGAIN find the flipped edges again before orienting? Or am I reading this wrong?

Wouldn't you want to fix all the bad edges except for one, and then perform an alg that flips that one edge but ignores the position of the dedges? That way you wouldn't have to inspect EO twice if there's parity.

 

[Cride5]

The method I was thinking about would be to inspect EO, and for the odd cases, single out an edge which will remain flipped. Solving EO would end with the remaining flipped edge being positioned ready for the parity alg. Instead of EOLine, I would be solving EOParity followed by line.

However, if a significantly shorter 3 or 5 edge flipper were available I would considering modifying the approach. For example, purposefully setting aside and pre-positioning 3/5 flipped edges during EO.

 

[FatBoyXPC]

How might I go about figuring out which edges are good/bad after reduction?

Cride: You might find the common alg for 4x4 OLL parity faster than the one you posted. Unless you are good at inner slice turns on 4x4 (I have to do Rr r' to do r so it's not too fast for me). Rr2 B2 U2 Ll U2 Rr' U2 Rr U2 F2 Rr F2 Ll' B2 Rr2

 

[riffz]

The method I was thinking about would be to inspect EO, and for the odd cases, single out an edge which will remain flipped. Solving EO would end with the remaining flipped edge being positioned ready for the parity alg. Instead of EOLine, I would be solving EOParity followed by line.

However, if a significantly shorter 3 or 5 edge flipper were available I would considering modifying the approach. For example, purposefully setting aside and pre-positioning 3/5 flipped edges during EO.

Okay, I figured that's what you meant but I couldn't tell.

Out of curiousity: How fast can you inspect and solve EO without inspection? I realize I'm not really helping but at least I'm bumping.

 

[CubesOfTheWorld]

I use a double parity algorithm for OLL parity: Rw U2 Rw' U2 Rw U2 Rw U2 Lw' U2 Rw U2 Rw' x' U2 Rw2 (U2 AUF)

 

[Cride5]

How might I go about figuring out which edges are good/bad after reduction?

http://cube.crider.co.uk/zz.php?p=eoline#eo_detection

Cride: You might find the common alg for 4x4 OLL parity faster than the one you posted. Unless you are good at inner slice turns on 4x4 (I have to do Rr r' to do r so it's not too fast for me). Rr2 B2 U2 Ll U2 Rr' U2 Rr U2 F2 Rr F2 Ll' B2 Rr2

Sorry, I should have stated, the algs I posted are in SiGN notation, which means r represents a double layer turn. The alg also works with inner slice turns, and preserves everything apart from the M-slice dedges if exec'd this way.

Out of curiousity: How fast can you inspect and solve EO without inspection?

I'm estimating about 2 sec for inspection, and about 2-4 sec for planning/solving. I'm not in a situation to test it just now, but I'll get back to you with some figures when I can..

 

[reThinking the Cube]

So what I'm looking for is the shortest sequence of moves which change an odd-number of flipped dedges into an even number, while maintaining the edge pairs and centres. The alg must not permute the centres (relative to each other), but may permute the dedges and corners in any way.
<snip>
.. and so far the shortest sequence appears to be:
r U2 r' U2 r' D2 r D2 r' B2 r B2 r' (13 btm)

Along with its derivatives:
r U2 r' F2 l' B2 l B2 l' D2 l D2 l'
r U2 l' U2 r' B2 l B2 r' B2 l B2 l'
r U2 l' U2 x' r' U2 l U2 r' U2 l U2 l'

if you make that all wide turns, and add (U2 S2) to the end,
you will get reParity™ =r U2 l' U2 x' r' U2 l U2 r' U2 l U2 l' U2 2s2 y2 (15 btm)

With this 1 wide turn alg (rotated z), you can solve it down to the last slot(FR), easily identify that an edge(oll) parity exists (flipped dedge in the last slot), and then ALSO see the corner/dedge(pll) parity (not too hard if 3 bottom corners already solved), then if needed, add appropriate AUF (so that DRF<->UFR makes corner+dedge permutation even), and have both parity problems corrected at the same time.

 

[Christopher Mowla]

So what I'm looking for is the shortest sequence of moves which change an odd-number of flipped dedges into an even number, while maintaining the edge pairs and centres. The alg must not permute the centres (relative to each other), but may permute the dedges and corners in any way.

You already have access to the shortest sequences in btm to accomplish what you want. 13 btm is the minimum to flip an edge (and induce PLL parity). 15 btm is the minimum to flip an edge (without inducing PLL parity).

(If you are looking for optimal algorithms in block half turns to preserve both centers and dedges, it's from algorithms in the conventional move set.)

The only algorithms I have come across which "flip" an edge on the 4X4X4 (or any other big cube size) and preserve all other edges in less moves than 13 btm are ones which do not preserve the centers.

These algorithms (both double-parity and solely OLL parity) are 11-12 btm (11 btm is optimal to "flip" a single edge, preserving the other edges, but messes up the centers).

Some have believed even when messing up the centers that 13 btm is the absolute minimum, but I have found a way to do it in fewer moves.

 

[Cride5]

Out of curiousity: How fast can you inspect and solve EO without inspection?

I'm estimating about 2 sec for inspection, and about 2-4 sec for planning/solving. I'm not in a situation to test it just now, but I'll get back to you with some figures when I can..

OK, so I just did an average. The times are for inspecting and solving just EO on a 3x3. The average of 12 came out at 6.26, so maybe a little more than I expected, but not drastic. On a 4x4, the possibility of having an odd number of bad edges may make inspection a bit longer, but then having lookahead may contribute to reducing the time for EO inspection.

I may well look into being more systematic with my edge pairing method. Currently it involves rotating the cube around, and storing solved dedges in no particular location. There may be some potential in choosing a fixed cube orientation during edge pairing and orienting 'on the fly'. I'll look into this a little further...

The data:

Spoiler

Current Average of 12: 6.26
Best Time: 4.07
Worst Time: 11.95
Standard Deviation: 1.3 (21.2%)

1. (4.07) R2 D2 R2 U' R2 U F2 R2 U B' D' B U B R' D' B' U R U2
2. 5.45 B2 D' B2 L2 U2 F2 R2 D L2 D' B' L F' L2 B2 F2 R' U' F' D2 U2
3. 6.76 F2 L2 F2 D2 F2 D2 R2 U' R2 U2 L D B' U F' U L' U' F R2 D U
4. 5.26 U2 B2 L2 B2 D B2 U' L2 D' U F D' U B R' F U' B U2 F2 R'
5. 8.17 U R2 F2 R2 F2 U' B2 D' R2 U' B U2 R' F L U2 B' U' F2 D' R2 U'
6. 8.88 B2 L2 D' F2 U' F2 U B2 D' B2 F R U L' R2 B2 D2 L2 U F' D'
7. 5.24 R2 B2 U2 L2 U' L2 U' B2 R2 F2 R' F L2 U' B L2 B2 L U R'
8. (11.95) U B2 F2 D' L2 D' B2 D L2 F' R2 D' F2 U2 R2 U R D2 B F' U'
9. 6.98 R2 U' L2 D B2 D' R2 D L2 D' L D2 F R' D' U2 B' R U L' R
10. 4.59 U B2 F2 U B2 U' R2 U' B2 F2 L' F' R' U F2 D2 L2 B U' B F
11. 5.41 U' L2 U' L2 F2 L2 R2 U2 R2 U' B R' F' D' R F2 R2 F2 L' F' U2
12. 5.85 D2 B2 R2 D F2 R2 D2 U B2 L2 B' R' F U2 L B' U' F2 L' D'

With this 1 wide turn alg (rotated z), you can solve it down to the last slot(FR), easily identify that an edge(oll) parity exists (flipped dedge in the last slot)...

Cheers, but I wasn't interested in solving F2L with even one disoriented edge, as it leads to quite a lookahead disadvantage, and means I need to use CFOP/rotations. The idea was to use ZZ for the 3x3 phase, so that I could benefit from all the advantages ZZ brings. Thanks anyway.

You already have access to the shortest sequences in btm to accomplish what you want. 13 btm is the minimum to flip an edge (and induce PLL parity). 15 btm is the minimum to flip an edge (without inducing PLL parity).

Thanks for your info. How did you establish that 13 btm is optimal?

 

[Christopher Mowla]

Thanks for your info. How did you establish that 13 btm is optimal?

I didn't technically "establish" that, but from my experience with forming algorithms in the conventional move set, algorithms in "cmowlaparity's" move set, and "the Holy Grail's" move set, conventional algorithms are king for btm for the single edge flip. The other move sets come at minimum between the 16-17 move range for the 4X4X4 (I have never found an algorithm which can accomplish this task in 15 btm--not to mention less than 13 btm--outside of the conventional move set). These alternate move sets promote optimality in BQTM only.

Hence, it's based off of "brute force". I am sure Kenneth, Lucas Garron, qqwref, Stefan Pochmann, and others can give you information on btm optimality from optimal 3X3X3 cube solvers.

 

[riffz]

I may well look into being more systematic with my edge pairing method. Currently it involves rotating the cube around, and storing solved dedges in no particular location. There may be some potential in choosing a fixed cube orientation during edge pairing and orienting 'on the fly'. I'll look into this a little further...

If you used 3-2-2-2-3 (Feliks and Syuhei use it, I believe), you could hold the cube in your ZZ orientation at the start of edge pairing and maintain that orientation throughout.

 

[qqwref]

Yeah, using 3-2-2-... or 6-2-2-... edge pairing pretty much ensures that you keep the cube in a fixed orientation during that step. After the first pairs BL and BR are solved, so you only need to look on U and D, which makes it good for speed as well.

I'm quite interested to see how ZZ-redux develops. I'm not too good at EO recognition, but this could be a really cool method for an experienced ZZ user.

 

[Cride5]

@riffz & qq, these sound like interesting approaches .. I'll have a play around with them..

I've also been looking into possibility of doing EO during edge pairing, and I think I've found something which might work.

The general idea is to do pairing using something like Robert Yau's method, only solving the two line dedges first and then doing the rest using only R,r,L,l and U. Pairing will usually take place one dedge at a time, but will also solve most of EOLine, so that after edge pairing 0, 1 or 2 edges need flipped and line is already solved.

It works like so:

The move used to pair these edges would be l U' R U l'

Looking at what happens during these moves, the blue-reds have their orientation preserved, the yellow-orange in B is flipped, and connected with the other yellow-orange, and the white-green in F is flipped and connected with the other white-green. So each time the pairing move is made, 2 edges are flipped. The idea is to ensure that unoriented edges are flipped to oriented as far as possible.

To do this, during edge pairing, I'm only looking to connect pairs of edges where at least one is oriented. If only one is oriented I'll move them into the position of the orange-yellows in the diagram, while also placing a flipped edge in the green-white position in F. If both are oriented I'll pair them in the blue-red positions, while also placing a flipped edge in the orange-yellow position in the B layer. Doing this should guarantee that there are always edge pairs available where at least one is oriented.

So anyway, this deffo looks like a feasible way to flip edges, but I'm not sure how quick it will be. Does it look worth it?

 

[riffz]

I don't have time to try out your example as I'm heading to my cottage for the weekend, but I must say that incorporating elements of Yau to at least solve the EOLine sounds like a great idea. That would probably save a lot of time later.

I'm going to experiment with some edge pairing while orienting stuff this weekend. For some reason, I have a feeling there must be a a decent system for orienting edges during 32223 pairing.

I probably won't find much, but at least it'll give me something to experiment with this weekend.

 

[Cride5]

The more I look at this method, the more viable it's starting to look. The move count doesn't seem to be much worse than the standard Yau method. It turns out that it is quite often possible to pair and orient 2 edges at a time. This is because each time 1 edge is paired to orient, there are 2 possible alternatives to choose from, for orienting a second one.

I've created a new thread to discuss this idea in more detail here:
http://www.speedsolving.com/forum/showthread.php?t=23617