4x4x4 Conjecture Concerning Dedge-First Solving

[unsolved]

I am sure most readers are familiar with the Reduction Method for the 4x4x4 where the centers are solved first, the dedges next, and finally the corners.

Let me first state that I am not, and have never solved a 4x4x4 in this fashion.

I solve the 4x4x4 from the top down, resulting in those "last layer" conditions with the dedges everyone seems to loathe.

This brings me to the reason for the post.

Can the dedges always be solved without parity errors, and therefore with fewer moves on average, if they are attacked first?

I understand this may be awkward for a human, but I am writing C-code for a program to deal with it.

If those longer parity-correcting algs can be avoided altogether, it might be a worthwhile goal for a stage solver. If, however, there is no guarantee that a random scramble can bypass the parity en route to putting all 24-pair of dedges back together, it probably won't matter at what stage they are solved.

 

[shadowslice e]

So are you basically thinking of the cage method but without actually solving the dedges and corners?

I think it's technically possible to cancel parity during a solve while using reduction (or perhaps L2D algs) but this is a headache for a human but I might be worthwhile for a computer.

 

[unsolved]

Cage without dedges and corners leaves nothing, I believe

This would be cage minus corners = dedges, unless I am using the term dedges incorrectly.

The idea being, if I disregard centers and corners, maybe, just maybe, dedges become easier. Understandably "weird" for a human solve, but computers know when the edges have correct relative offsets with ease.

 

[mDiPalma]

the only case that we could come up with for parity to exist with the qty of bad edges not a multiple of 4 was the "twin" dedge case.

i think if you can avoid twin dedges and keep the number of bad edges a multiple of 4 throughout the solution, it's possible.

not sure tho

 

[unsolved]

You mean when two dedges on adjacent faces, like F and R, need to be swapped with one another? If so, my guess is that such a condition can be alleviated well before the final situation presents itself.

 

[cmhardw]

You mean when two dedges on adjacent faces, like F and R, need to be swapped with one another? If so, my guess is that such a condition can be alleviated well before the final situation presents itself.

Have the computer determine permutation parity of the wing edges before starting the solve. Then have it solve the wing edges using the correct number of inner slice quarter turns such that the final state is even permutation parity. This avoids "OLL parity".

To avoid the PLL parity, as you are pairing up your final dedges, or however the computer program is doing this, keeping in mind that it is still under the constraints of the point above, have it determine the permutation parity of the corners, and also of the dedges under all possible remaining options in your possible moves tree. Make sure to choose a path that still satisfies the first point, but also leaves the corners and dedges to have the same permutation parity.

So yes, it is possible to get a computer to solve via cage method and never encounter parity as long as you have it make take into account the permutation parities of the different piece types during the solution.

 

[unsolved]

Well before the computer does all of that, I'd better learn it myself

 

[cmhardw]

Let me know if you have any questions about it. I can tell you how a human would do those things, but I imagine a computer would be able to do the first condition by counting the number of inversions in a list of the pieces and their current locations.

Stefan Pochmann would be a wiz at this, but I'll try to help the best I can.

 

[unsolved]

The way my solver attacks the problem now involves 0-knowledge. It generates moves, counts the correctly positioned dedges, determines if it's possible to solve them all in the remaining depth, keeps trying if so, and prunes otherwise.

For example: there are 24 individual edges with a total of "48 stickers." My program can get a "correct sticker count" almost instantly by the way it was designed. If all 48 are correct, I know the dedges have been solved, and stage 1 is complete.

And, since no more than 8 stickers can be solved with one move, if I am on, say, move 9 of a 10-move sequence that is being built, if my sticker count is less than 40, I still can't solve it, no matter what move I make. No point in continuing. Likewise, if I generated 8 out 10 moves, or 9 of 11, or 10 of 12, if I have fewer than 32 correct edge stickers, no 2-move sequence exists to solve all dedges, so I need not bother generating them.

The program ends up "doing nothing" but getting to the proper minimum depth very quickly. Then, while it is slogging away, I have it spit out the cube positions with the greatest number of solved edges and the sequence that produced it. Ties are broken by positions with more correct centers, and then most correct corners in rare cases when both edge and center counts match.

So it's just a "fast and dumb" approach which lacks elegance, but it's what computers are good at.

 

[obelisk477]

How would a human do this? Is it written out somewhere already? For avoiding OLL parity I mean

 

[unsolved]

The approach I have outlined for the program is not advised for a human solve. Perhaps someone else can offer any applicable variant that might work.

 

[cmhardw]

The way my solver attacks the problem now involves 0-knowledge. It generates moves, counts the correctly positioned dedges, determines if it's possible to solve them all in the remaining depth, keeps trying if so, and prunes otherwise.

The approach I have outlined for the program is not advised for a human solve. Perhaps someone else can offer any applicable variant that might work.

Perhaps have the computer determine the permutation parity of the wing edges (likely by representing the wing state as a sequence and counting the number of inversions), then you have two cases:

Case 1: If wing parity begins as odd, then all solutions to wings must have an odd number of inner slice quarter turns. This will result in even parity and this no OLL parity. Basically prune out any solution that has an even number of inner slice quarter turns (these will result in OLL parity if you continue the solve)

Case 2: If wing parity begins as even, then all solutions to wings must have an even number of inner slice quarter turns. Prune out any solutions that have an odd number of inner slice quarter turns.

How would a human do this? Is it written out somewhere already? For avoiding OLL parity I mean

Yes, I've written up a guide for how to do this in one of the 4x4 FMC threads I believe, and I also wrote one in a speedsolving thread once.

Around 2005 I attempted to use this technique seriously in 4x4 speedsolving, but I was never able to determine wing parity in the 15 second inspection time allotted so I abandoned the idea.

 

[Christopher Mowla]

Yes, I've written up a guide for how to do this in one of the 4x4 FMC threads I believe, and I also wrote one in a speedsolving thread once.

Around 2005 I attempted to use this technique seriously in 4x4 speedsolving, but I was never able to determine wing parity in the 15 second inspection time allotted so I abandoned the idea.

About 2 months ago, I searched the web and found some "parity prevention" topics on speedsolving.com, yahoo groups, and twisty puzzles. I put all links under "Preventing/Avoiding Parity" external links at the very end of the 4x4x4 parity algorithms wiki page. Are these the topics you were referring to (besides the twistypuzzles one, of course)? (Just to save you time searching.)