Wiki Discussion Thread

**ThomasJE** · 06-05-2012

Wow, that looks good! That's how I kind of wanted the page to be like. Also, why do we need algorithms that don't preserve F2L? Parity is usually peformed after F2L, so algs that mess up F2L are useless really.

**cmowla** · 06-06-2012

Originally Posted by ThomasJE

Wow, that looks good! That's how I kind of wanted the page to be like.

Thanks.

Originally Posted by ThomasJE

Also, why do we need algorithms that don't preserve F2L? Parity is usually peformed after F2L, so algs that mess up F2L are useless really.

Well, I don't see any real use in algs that don't preserve F2L either, but the algorithms I found in the past like this (and even more importantly, cuBerBruce's algs which are currently posted on that page, well, except for three which I found) are, I guess, just interesting. I mean, the 15 BQTM algs of cuBerBruce's are pretty neat. Besides some individuals using, say, the second (17,13) algorithm for Petrus, I guess it's important to have these algorithms posted in the wiki because it gives everyone appreciation for the standard algorithms which preserve more and are only a few moves longer. I'm sure you have seen the parity threads that have gone on, at least in the time I've been a member. On more than one occasion, people were wondering if there is a possibility of shorter parity algorithms to exist. I mean, we don't have an official cube explorer for the 4x4x4. cuBerBruce has done some impressive work to get around this, and I of course have done so on many levels myself (which I feel privileged to do for my fellow cubers, and I'm sure cuBerBruce is very proud of the accomplishments of his brute force searches). I guess at the end of the day, we (and whoever does constructive writing and/or makes contributions which make it on this page in the wiki) should hope that we provide speed optimal and move optimal solutions of all kinds so that everyone's needs will be met, whether it is for practical use in solving, curiosity, a look into the theory, or just to have a deep appreciation for the parity algorithms we have.

And just as an example (not that you mentioned algorithms for the checkboard pattern 4-cycle), but...

Even an algorithm like [f2 u' r2 Uw2 S': r] has its purpose (besides being the optimal algorithm BHTM and BQTM, we can still learn from it). As I have posted on the comments of a youtube video, if anyone wants to argue that parity algorithms are unintuitive, they should study this algorithm[f2 u' r2 Uw2 S': r] and reconsider. It doesn't matter how many moves it takes you to get slice r to look like it does after f2 u' r2 Uw2 S', as long as you can make slice r look like that, then you're in business. Simply observing how same color centers swap with each other when the extra quarter turn is finally ready to be executed is such a simple concept, it's beautiful. When I started cubing, and even after I found optimal solutions to various cases in different move metrics, I was always thinking to myself, "there must be a simpler concept of how to handle parity, even more so than my methods." I didn't find this algorithm right away (heck, I just found that early this year!), but the idea behind the algorithm is so simple that, once a cuber sees it and understands its one message, then the fear of parity should vanish forever. Easy to understand parity algorithms for, the pure edge flip, for example, clearly do exist: [f2 u' r2 Uw2 S': r] [Rw: [U' f' U, B2] ]. Sure we can just do a quarter turn and then solve back everything, but that's not really looking at the problem head on (at least, not to me. That's just doing something to bypass the "big problem" of having deal with the consequences of an odd permutation in the inner layers. That approach is like saying, "since my computer program has a bug, I'm going to start over," instead of trying to debug the code and actually learn how to prevent mistakes like that from happening again).

**cmowla** · 06-07-2012

I did a major addition the the 4x4x4 Parity Algorithms page. I'm sure there are more algorithms (whether brief in btm or BQTM or fast) which can be added. Those who blindsolve can add any other parity algorithm categories (if there are any others).

**ThomasJE** · 06-08-2012

I've done an overhaul on the VOP Method page. I've made the page neater and added a lot more algs. I think all that needs adding is a link to Guimond OLL algs that DON'T affect the V. If there is anything else that needs to be added/changed, then feel free to edit, but please keep the general layout the same.

**Eazoon** · 06-08-2012

I just wanted to mention that you must not mix up fact and opinion. I saw on the v-cube 5 page somthing like
"the v-cube 5 is better than shoungshou 5x5 which has bad outer layers". I fixed it but I hope there aren't many more things like that.

**pjk** · 06-23-2012

Just wanted to update the guys working on the wiki: I'm trying to combat this spam anyway I can. I have a few ideas to try since they are clearly getting around the CAPTCHA, but I have a huge plate atm and it will take be a couple weeks to work on this. For now, blocking and deleting posts when they come up is the best that can be done. Thanks for working on this.

**pjk** · 07-13-2012

I just got rid of the CAPTCHA because bots are clearly getting around that, and implemented a more difficult one for new account creation (try to create an account to test it). We'll see if this helps. Thanks guys for moderating that and keeping it clean.

**cmowla** · 07-27-2012

After many hours of work, I have finished my edits for the 4x4x4 parity algorithms page, and the 3x3x3 PLL page.

The 4x4x4 parity algorithms page should be explanatory. Although I have added quite a few new categories of algorithms, I'm sure there are some more which people can add. More external links perhaps?

For the 3x3x3 PLL page (if you ever intend on editing the 2-cycle PLLs, please read...I spent a lot of time organizing the chaos from before!),

Spoiler:

I have sorted all previously existing 2-cycle algorithms in the following manner.

-I have numbered algorithms based on which algorithms were originally listed first. Their directly related algorithms (which might have been in the middle or even at the end of the list) have been grouped with them.

-If it wasn't in the wiki already, I have added versions of the previously existing algorithms which have no wide turns or cube rotations from every single algorithm listed in the wiki and made that the first version of related algorithms. That is, the algorithms are grouped into groups which shows which algorithms are directly related at some level or another. Advantages: Although not all of the first versions in the algorithm groups are fast, it is ideal to keep them so that people will not make the mistake of accidentally adding duplicates. In addition, people might like to add more versions to a group of algorithms from the first (non speed optimized version alg.). IN ADDITION, it's easy to link them to their decompositions.

-Speaking of decompositions, I have added commutator/conjugate decompositions of the first version alg in each group because they might give insight on how these parity algorithms can be constructed. For most even permutation algorithms, such decompositions might not be so straight forward (because it was actually easy for me to at least pinpoint --in the majority of the algorithms--where the extra quarter turn actually is executed). I will leave the decompositions of the rest of the PLL cases to others in the future.

-The first version of the algorithms is the only version which is guaranteed to solve a cube completely after executing the alg. to the corresponding case image (of course, the decompositions are decompositions of the first algorithms, so they too are guaranteed to completely solve the cube...). The rest of the versions (v2,v3,..etc.) may need U, U', U2, y, y', or y2 (or a combination of U and y) to restore the cube to the starting position and have the cube solved entirely. But I noticed this was done before for many of the algorithms, so I made an effort to omit all last U turns or y cube rotations to shorten the algs. Again, the first versions and their decompositions do not have the last U turns omitted (if the last turn involves U).

-For the symmetric J, N, and R Perms, all algorithms are now evenly distributed among each. If, for example, Ja had some additional algorithms (or additional forms of the same algorithms) which Jb didn't have, then I added those algorithms to Jb. In addition, the algorithms from Ja directly correspond to that of Jb, Na to Nb, and Ra to Rb.

How to keep these algorithms organized:
- If you add an algorithm to Ja, please add its mirror to Jb, even if you don't think it's as fast. (Same for Na and Nb). If you add an algorithm to Rb, please add its mirror + y2 cube rotation to Ra.
- If you add an entirely new algorithm to one of the 2-cycle PLL cases, do not put it in an existing group: make a separate group.

For those who wish to move algorithms around.
You may move the algorithms for a 2-cycle PLL case around in any order you wish. Just make sure that you do not exchange algorithms between groups! Keep all algorithms in their groups so that people in the future will be able to know which algorithms are directly related/only optimized differently. You may move the entire group around, though.

However, if you do move around algorithms or groups, renumber everything please. Also, if you affect Ja, Na, Ra, also affect Jb, Nb, and Ra in the same manner, so that the only main difference between algorithms in either symmetry is a mirror (mirror + y2 cube rotation for Ra between Rb...that is, unless the case image for Rb or Ra is rotated to be just the mirror of the other).

The main reasons I did this organization was to help reduce the amount of duplicate algorithms added in the future, show how few "unique" algorithms that are in the wiki for most of the 2-cycle PLLs (maybe someone can add more unique algorithms from other sources easier now and be sure that they are not duplicates of what's already in the wiki), illustrate how 3x3x3 parity algorithms can be represented using commutators and conjugates, and to make the number of algorithms under Ja equal the number of algorithms under Jb, Na to Nb, and Ra to Rb (in doing so, there is actually more variety for future cubers to try).

EDIT:

Also, I wasn't lazy. I double checked all links, algorithms, and decompositions, and all are correct. You can double check to see if the algorithms I claim to be directly related (I put them in the same group) if you wish. But I have double checked that as well.