Depends on the method you're using, and also on what exactly you mean by "edge parity".I got into edge parity issue with 4x4 initially but I was able to avoid it totally by using a procedure and have been successful in avoiding edge parity.
Is it usual to not to get into 4x4 edge parity at all?
Depends on the method you're using, and also on what exactly you mean by "edge parity".
If you're using the cage method (solve all corners and edges first, then finish the centres), handling parity is often as simple as doing a single move, followed by a single commutator if necessary.
If you're using the reduction method, where you solve all the centres and pair up all the edges first, the probability of getting OLL parity (an odd number of bad/flipped edge pairs) is 50%, as is the probability of getting PLL parity (an odd number of swaps among the corners and edge pairs). If you're trying to do something fancy and you haven't seen OLL parity (or PLL parity) in a while, chances are that you just got lucky and you're not actually forcing OLL parity (or PLL parity) to not happen.
A 50% chance of getting OLL parity means that there's a 1/1024 chance of not getting OLL parity ten solves in a row. That's a low probability, but it's not negligible.
(Obviously, caveats apply; it is possible (albeit very difficult) to avoid OLL parity in speedsolves and a few people are good enough to do it consistently, but they also know exactly what they're doing and don't need to ask if what they're doing is sensible. My point is: if you have to ask, you're not doing it right.)
Can you supply a step by step method that does this? Or did you find an algorithm that will solve it?
I made a list of several topics which discuss this in detail here on the 4x4x4 parity algorithms page in the Wiki.
But it's not worth avoiding it (it takes more time than executing a parity alg for sure) unless you are doing FMC. But even then, there might be a special circumstance in which a short odd parity fix may make the overall solve shorter.
I found this OLL parity (specifically, a single edge flip + PLL parity) algorithm late last year which basically requires you to learn 6 moves. FYI....as I don't like to remember lengthy algorithms. So I studied the movement of the cubes and came up to this procedure.
I found this OLL parity (specifically, a single edge flip + PLL parity) algorithm late last year which basically requires you to learn 6 moves. FYI.
Rw' (F U' Lw' U)5 Rw
Yup, it was Cale:I've seen it done on video - I think it was Cale Schoon.
Is there a topic on this or where can we find out more info on this?OLL parity can be avoided by tracing wings 4BLD-style during inspection and solving centres using an odd or even number of quarter slices as appropriate. I've seen it done on video - I think it was Cale Schoon. Of course, tracing wings inside 15 seconds is not easy...
Incredible, is there more details on how he does it exactly?Yup, it was Cale:
Oliver Frost also mentioned being able to do this a while back.
(Can mods merge the posts from the three threads OP has posted in regarding this topic into a single thread?)
Incredible, is there more details on how he does it exactly?
OLL parity can be avoided by tracing wings 4BLD-style during inspection and solving centres using an odd or even number of quarter slices as appropriate. I've seen it done on video - I think it was Cale Schoon
That's a really long alg, probably would take too long in a speedsolve. I might try it though
Yeah, that one is complete bollocks. He mentions having a >97% success rate with his method, which is extremely strong evidence that he's a liar.I don't think the method exposed in this video actually works.
If – on a solved cube – I do:
1. slice - flip edge - slice; or:
2. OLL parity alg
...in both cases there are 2 edges with the wrong orientation.
So, I don't think the number of misoriented edges is a criterium.
I've tried to count the number of pairs with only 1 misoriented edge, and it doesn't seem to work either.
You'll still need some kind of long-ish alg to fix parity at that stage. Tim Koop's approach is to do it in a way such that most of the parity alg is "intuitive", but it doesn't circumvent the fact that it still takes a lot of moves to fix OLL parity.Maybe checking for parity before it gets to OLL/PLL stage
Tim Koop's website proposes counting dedges to see if even/odd in number to see if there will be a parity issue. This could open up solves at an earlier stage to not undo the work done if going by a reduction method. So maybe an algorithm that does not disturb the centres?