K4

[Christopher Mowla]

My point was that no one really has "learned" the ELL algorithms. Thom just put those up so he wouldn't have to explain commutators, but in reality, they aren't a set number of algorithms. It would be similar to comparing OLL algorithms to intuitive f2l. Your method probably requires a learned set vs. a group of intuitive commutators.

I don't know exactly what I am dealing with yet, but when I finish the complete set of algs, I will post the document in this thread and comment on it.

As for the algs I learned, they include (by colloquial names) OLL parity, Double Parity, opp 2cycle, PLL parity, and the 2 checkerboard 4cycles (named from bigcubes.com 5x5). I actually didn't need to learn any of these for ELL specifically, as I had known of them previously from 5x5 solving.

You also conjugate each of those cases (except for the single dedge OLL Parity of course) to affect adjacent dedges too, right? Just asking so that I can see how this works.

EDIT:
Also, did you forget to mention 3x3x3 algs such as U-Perms (or other dedge preserving 2 3-cycles) or H or Z perms (or other dedge preserving 4 2-cycles)? I know it's not efficient to pair up the dedges first, but, if they happen to be paired up already it would be. The reason I ask is because you claim to be able to handle all 8! cases with just a maximum of 3 algs, using just the list of algorithms above. I just want to make sure I understand your method. Another reason I mention that is because two of the 32 PLLs are U-Perms, and obviously 4 of the 2 2-cycle algs are PLL parity or regular two dedge flips.

 

[vcuber13]

idk about dan but i would just do RUR'U' alg URU'R'

 

[Christopher Mowla]

I have completed the document. (It's attached at the bottom of this post).

Just to illustrate this approach, here is one route we can take using the algorithms provided in my document for Kirjava's previously mentioned case:

2 2-Cycle to solve the UF Dedge
[r2 U2 F' M' U': r2] (11)
y
2 2-Cycle Used for an OLL
[y' R' F': [l2 U' F2 U': l2]] (13)
y
A 1 3-cycle and 1 2-cycle Algorithm for an Odd Permutation PLL
M2 U' x' r2 U2 F2 r' F2 U2 Rw2 U2 r U2 Rw2 x U2 r U' M2 y2 (17)

Here's a link to this solution.

​

I have put bookmarks in the PDF for convenience.

Comments:
Also, I was one algorithm off. There's a total of 56 needed algorithms with this approach. The extra one was the mirror of the single dedge flip OLL. I needed to put it because any cycle besides a 2-cycle can mess up either side of the dedge. In order to not mess up the single solved dedge prior to OLL by accident, I had to include the mirror so that we have a choice of which side of the dedge we mess up.

As I estimated before, the total number of absolutely different algorithms needed to generate all 56 cases was a little more than 1/4 of the total, being 14-16 (depending on how you feel about what I mention on the last page of the document).

The majority of the algorithms in the document were created by me, so if anyone has questions regarding them, feel free to ask.

Lastly, I made the cube and permutation images in the document as the 5x5x5 cube so that it would be easier to see.

EDIT:
I just realized that this method requires more than 56 algorithms. If a wing is in the correct composite edge but is on the wrong side then, if no wings are solved even half way, the method has a problem.

We need 66 algorithms to be able to handle all 8! cases in 3 algorithms or less using this method.

Spoiler

If no wings are even half way solved, then there are two cases to consider:
1) Not all composite edges have one wing which corresponds to their two colors on the wrong side.
2) All composite edges have one wing which corresponds to their two colors on the wrong side.

For case 1, if we so happen to have the composite edge that has one correct wing in the composite edge, but on the wrong side, we can simply choose another dedge to solve that isn't like that. No additional algorithms are required for this case.

For case 2, there are a total of 32 cases which are not possible to solve in 3 algorithms or less using the method, unless more algorithms are added.
If we let A = r' U2 r2 U2 r U2 r' U2 r U2 r2 U2 r' and A = r U2 r l' U2 r2 U2 r' U2 r U2 r' U2 r' U2 l U2 r' into the formulas A y A y', A y A' y', A' y A y', and A' y' A' y', we obtain 16 of them.

Similarly,
If we let A = Lw' U2 M'2 U x' l' U2 l' U2 l2 U2 l' U2 x U' M'2 U2 Lw and A = Lw' U2 M'2 U' x r' U2 r' U2 r2 U2 r' U2 x' U M'2 U2 Lw into the formulas A y2 A y2, A y2 A' y2, A' y2 A y2, and A' y2 A' y2, we obtain the other 16 cases.

Hence, it looks like we need to add all 12 3-cycles which are contained in two composite edges to be able to tackle all 8! cases in 3 algorithms or less. I already have two of them for the "single dedge flip" OLL cases, and thus we need to add 10 algorithms to our list for a total of 66 algorithms.

I have edited the document again (hopefully the last time).

 

[vcuber13]

why didnt you solve another dedge with the second alg?

 

[masterofthebass]

You also conjugate each of those cases (except for the single dedge OLL Parity of course) to affect adjacent dedges too, right? Just asking so that I can see how this works.

EDIT:
Also, did you forget to mention 3x3x3 algs such as U-Perms (or other dedge preserving 2 3-cycles) or H or Z perms (or other dedge preserving 4 2-cycles)? I know it's not efficient to pair up the dedges first, but, if they happen to be paired up already it would be. The reason I ask is because you claim to be able to handle all 8! cases with just a maximum of 3 algs, using just the list of algorithms above. I just want to make sure I understand your method. Another reason I mention that is because two of the 32 PLLs are U-Perms, and obviously 4 of the 2 2-cycle algs are PLL parity or regular two dedge flips.

Yes, when I solve ELL, I usually leave 2 adj edges to be solved. Depending on the case, I can either do a RB or RUR'U' conjugation to give me one of the cases I mentioned.

I did forget to mention Uperms, but they can be seen as a fairly intuitive 3x3 ELL if you would like. Obviously with my knowledge from other puzzles, using EPLLs helps with the amount of looks, but I am still absolutely sure that it only takes 3 algorithms to solve ELL, even if you follow Thom and I's outline for solving.

why didnt you solve another dedge with the second alg?

that's not the method he's proposing.

 

[Christopher Mowla]

F(n-1)L

I have been interested in solving a dedge (or one orbit of the composite edge, when referring to the nxnxn) in one algorithm instead of two.

I know that for the 4x4x4, if F2L algorithms are used, this isn't necessary. However, on larger cubes, if we can solve both wings in each orbit of the F(n-1)L composite edges in one algorithm, the move count during the F(n-1) phase will certainly be less and, if one has fast algorithms and a determination to learn a bunch of algorithms, be faster as well.

I was wondering which cases are the "worst" for solving a dedge in one algorithm, as far as btm move count is concerned. (What's the upperbound?)

Note: I am talking about big cube sizes in general, not just the 4x4x4!

First off, if I didn't miss any, there are 211 cases with respect to one, say, the FR F(n-1) slot. Of those, there are 107 cases, excluding mirrors.

As everyone knows, if we want to place two wings correctly into an F(n-1) slot, there are three different categories of where those two wings may be.
1) Both wings are in the U-Layer
2) Both wings are in the E-Layer
3) One wing is in the U-Layer and the other is in the E-Layer.

I have found many algorithms (most of them being 2 2-cycles, but also some 2 3-cycles too) to prove the upperbound of 13 btm for any given case. 13 btm being the total move count, including U, U', or U2 premoves, etc.

Here are my results:

​

Spoiler

In detail,
​

The only cases which may require 13 btm (again, for all size cubes) is the following: RF'Ulr'U'FR'UF'l'rF.


Maybe some people are wondering, but yes, I have been creating a document about this. I'm almost finished, as it includes all case images and corresponding algorithms.

The case images are different than Kirjava's. I did use visualcube as well, but I used the transparent setting and then modified it in Paint to my liking.

This is the url I used to generate the initial image.

This is the image I ended with.

​

I have actually made the cases images transparent, as to accompany any color background to ultimately change the color of the cube. My document has a black background (not good for printing, but good to have on the computer) and all case images inside have a transparent fill. For example, here is the case image for the only case which I cannot handle in less than 13 btm (on all size cubes).

​

EDIT:
Now I have proven that only one case requires 13 btm for all cube sizes. I have updated my results.
​

 

[Christopher Mowla]

I have finally finished the document for F3L.

Just in case people haven't read my previous post a day or so after I originally posted it, now only one case might require 13 btm.

As I was finishing the document, I noticed that I had the wrong algorithms for some cases, and for others, I lowered the move count. My final data is also in the document (not much different than what was in the previous post, but the overall algorithm length average is less now).

To save ink (whether printing in color or black and white), I have made all case images lighter.
F3L_Light

But for those who like the colors of the case images on Kirjava's web-pages,
F3L_Dark

I originally began making this document just for my curiosity for what the upper bound is for solving a dedge in one algorithm. However, this might have potential to be put into practice. Although there are 211 cases (or 99 not including mirrors, inverses, or cube rotations), I show rigorously at the end of the document that only 14 base algorithms are needed to generate all 211 cases. Using those 14 base algorithms make solutions that are no more than 12 btm, except for the single case which is 13 btm. I have more details on this as well as how I classify each case.


Lastly, I stated in my previous post that I couldn't get less than 15 btm for one 2 2-cycle case for the last layer. A few days later, I tried again and got a 13 btm: [r2 U F' R F' U: r2]. I have added that algorithm to the document and have updated the averages presented on the first page.

 

[Kirjava]

@Kirjava,

I have a few questions regarding solving the last layer wings.

First of all, I counted 54 cases on your ELL page, excluding the first section on "First/Second Edge Tricks," which may also include algorithms from the other 54 (I haven't compared the two to know).

[1] I recall that you said that you can solve any LL case in 3 algorithms, right?
[2] If [1] is true, are all of the algorithms on your ELL page sufficient to do this? I mean what IS there, not any algs for cases not on there which are mirrors, inverses, etc.
[3] If [2] is not true, then what's the minimum number of algorithms one needs to know to solve all LL cases in 3 or less algorithms?

1- ELL. Yap.
2- No idea. Maybe?
3- No idea.

The 'algs' listed there are just examples. I don't advise anyone to just learn them all. I think some first/second edge stuff is required for 3 looks.

The reason I ask is because I am currently putting together an alternate approach which requires the solver to know algorithms for 55 cases (55 algorithms total). That includes mirrors and inverses.

What kind of algs, comms? Do I already know most of them?

The Process:
[1] If one dedge is completely solved, skip this step. Otherwise, one dedge can be solved with one of 29 2 2-cycle algorithms (out of the 58 possible 2 2-cycle cases for the last layer).
[2] OLL. There are a total of 13 OLL cases (including mirros) when restricted to 3 unsolved dedges. Of those 13 OLLs, 11 of them can be done with 2 2-cycle algorithms from the selection of 29 used in step 1. The two new algorithms to be learned are to orient one dedge (a 3-cycle is probably best for this) and orient 3 dedges (a 3 2-cycle is probably best for this).
[3] PLL. There are a total of 32 PLL cases (including mirrors and inverses) when restricted to 3 unsolved dedges. Of those 32 PLLs, 8 of them can be solved with 8 of the 29 2 2-cycles used in step 1.

Hence,
Step 1 requires 29 algs
Step 2 requires 2 additional algorithms
Step 3 requires 24 additional algorithms

For a grand total of 55 algorithms. Again, that includes mirrors and inverses.

Another way to look at this is that
PLL (Step 2) requires 32 algorithms (including mirrors, inverses, etc.)
OLL (Step 3) requires 13 algorithms (including mirros, inverses, etc.)
and Step 1 therefore requires 10 additional 2 2-cycle algorithms to what can already be used in PLL and OLL.

Of those 55 algorithms, only 4 + 12 + 1 = 17 algorithms need to be odd permutations.
4 for the oriented 2-cycle cases, 12 for the oriented 1 2-cycle and 1 3-cycle cases, and 1 for the 3 dedge flip restricted to affecting the wings in those 3 dedges only.

I have algorithms for most of these cases, but I'll be trying to find the rest, as well as find faster ones for some of the longer ones that I have.

EDIT:
Well I guess only 16 odd permutation algorithms are required, as the 1 for the 3 dedge flip can be a specific 1 4-cycle and 1 2-cycle alg and possibly another cycle composition that I cannot think of right now. However, I think 3 2-cycle algorithms are more efficient anyway.

Ok, that's cool. You should post the method as algs so people can look and see if they like it.

Recognition sounds fine but the algs don't sound very fast.

Regardless of how the 54 cases can be handled, they are still algorithms. I'm not talking about "intuition" or conjugation of other algs. In fact, many of the algorithms I have found for the 55 cases I mentioned can be handled much easier than conjugation (if that's what you mean by intuition).

Are they fast?

Also, which 2-3 algs did you memorize that you can manage to solve all 8 wings for all 8! cases with 3 algs or less? I'm curious.

Not sure this is possible.

The total number of absolutely distinct algorithms required to handle all 55 cases is significantly reduced if we take into account inverses, mirrors, and minor modifications of other algorithms. I can't say exactly by how much as of yet (I haven't finished finding all 55 algs yet), but probably between about 1/4 and 1/3 of 55.

Inverses/mirrors seems to be taken for granted on 4x4x4 with these types of methods

I don't know exactly what I am dealing with yet, but when I finish the complete set of algs, I will post the document in this thread and comment on it.

You also conjugate each of those cases (except for the single dedge OLL Parity of course) to affect adjacent dedges too, right? Just asking so that I can see how this works.

EDIT:
Also, did you forget to mention 3x3x3 algs such as U-Perms (or other dedge preserving 2 3-cycles) or H or Z perms (or other dedge preserving 4 2-cycles)? I know it's not efficient to pair up the dedges first, but, if they happen to be paired up already it would be. The reason I ask is because you claim to be able to handle all 8! cases with just a maximum of 3 algs, using just the list of algorithms above. I just want to make sure I understand your method. Another reason I mention that is because two of the 32 PLLs are U-Perms, and obviously 4 of the 2 2-cycle algs are PLL parity or regular two dedge flips.

Nah, the algs listed are just examples. I didn't forget to mention 3x3x3 algs, this is taken from the site - "algorithms that work on the 3x3x3 apply here aswell". I just listed some of the stuff I know to give people a starting point.

I have completed the document. (It's attached at the bottom of this post).

Just to illustrate this approach, here is one route we can take using the algorithms provided in my document for Kirjava's previously mentioned case:

2 2-Cycle to solve the UF Dedge
[r2 U2 F' M' U': r2] (11)
y
2 2-Cycle Used for an OLL
[y' R' F': [l2 U' F2 U': l2]] (13)
y
A 1 3-cycle and 1 2-cycle Algorithm for an Odd Permutation PLL
M2 U' x' r2 U2 F2 r' F2 U2 Rw2 U2 r U2 Rw2 x U2 r U' M2 y2 (17)

Here's a link to this solution.

​

I have put bookmarks in the PDF for convenience.

Comments:
I had a lot of trouble with the 2 2-cycle case which can be generated by the following algorithm: [F2 U l' r' U F2 U: r2], using the conjugation method I did for the rest of the 2 2-cycles (which gave pretty nice results). It was indeed my longest 2 2-cycle algorithm, being 15 btm. Perhaps someone could help me shorten it?[FONT=&quot]

[/FONT]Also, I was one algorithm off. There's a total of 56 needed algorithms with this approach. The extra one was the mirror of the single dedge flip OLL. I needed to put it because any cycle besides a 2-cycle can mess up either side of the dedge. In order to not mess up the single solved dedge prior to OLL by accident, I had to include the mirror so that we have a choice of which side of the dedge we mess up.

As I estimated before, the total number of absolutely different algorithms needed to generate all 56 cases was a little more than 1/4 of the total, being 14-16 (depending on how you feel about what I mention on the last page of the document).

The majority of the algorithms in the document were created by me, so if anyone has questions regarding them, feel free to ask.

Lastly, I made the cube and permutation images in the document as the 5x5x5 cube so that it would be easier to see.

I have to say that recog looks like it could be fast. However, the algs don't seem like they would be that fast in practise. Like, lots of PLL algs suck.

I have been interested in solving a dedge (or one orbit of the composite edge, when referring to the nxnxn) in one algorithm instead of two.

Hehe. Solving multiple edges during F3L has been considered and tried over and over and over. The issue is (if you can call it that) that the lookahead and 'algorithms' for the current F3L technique is /so/ good it's very hard to beat. There's no point recognising and working out the alg solve two edges in one when you can execute two fast comms with no pauses faster. (Of course, I'd love you to prove me wrong)

I know that for the 4x4x4, if F2L algorithms are used, this isn't necessary. However, on larger cubes, if we can solve both wings in each orbit of the F(n-1)L composite edges in one algorithm, the move count during the F(n-1) phase will certainly be less and, if one has fast algorithms and a determination to learn a bunch of algorithms, be faster as well.

The cool thing about n>5 cubes is that during FN-1L there are often oppertunities to solve three or more edges at a time already with a few tricks. With smart edge group selection, you can even force these cases.

I was wondering which cases are the "worst" for solving a dedge in one algorithm, as far as btm move count is concerned. (What's the upperbound?)

Note: I am talking about big cube sizes in general, not just the 4x4x4!

No idea.

First off, if I didn't miss any, there are 211 cases with respect to one, say, the FR F(n-1) slot. Of those, there are 107 cases, excluding mirrors.

This seems... unfriendly as a speedsolving approach.

As everyone knows, if we want to place two wings correctly into an F(n-1) slot, there are three different categories of where those two wings may be.
1) Both wings are in the U-Layer
2) Both wings are in the E-Layer
3) One wing is in the U-Layer and the other is in the E-Layer.

I have found many algorithms (most of them being 2 2-cycles, but also some 2 3-cycles too) to prove the upperbound of 13 btm for any given case. 13 btm being the total move count, including U, U', or U2 premoves, etc.

Honestly, I don't really care about gods alg or upper bounds. Don't let me stop you from doing this though - your work is useful for method development.

Here are my results:
​

*insert graphs and *****

cool

I have finally finished the document for F3L.

Just in case people haven't read my previous post a day or so after I originally posted it, now only one case might require 13 btm.

As I was finishing the document, I noticed that I had the wrong algorithms for some cases, and for others, I lowered the move count. My final data is also in the document (not much different than what was in the previous post, but the overall algorithm length average is less now).

To save ink (whether printing in color or black and white), I have made all case images lighter.
F3L_Light

But for those who like the colors of the case images on Kirjava's web-pages,
F3L_Dark

I originally began making this document just for my curiosity for what the upper bound is for solving a dedge in one algorithm. However, this might have potential to be put into practice. Although there are 211 cases (or 99 not including mirrors, inverses, or cube rotations), I show rigorously at the end of the document that only 14 base algorithms are needed to generate all 211 cases. Using those 14 base algorithms make solutions that are no more than 12 btm, except for the single case which is 13 btm. I have more details on this as well as how I classify each case.


Lastly, I stated in my previous post that I couldn't get less than 15 btm for one 2 2-cycle case for the last layer. A few days later, I tried again and got a 13 btm: [r2 U F' R F' U: r2]. I have added that algorithm to the document and have updated the averages presented on the first page.

Your download links are broken.

Either way, maybe I'll learn this one day, maybe not. I still doubt that it could be useful for speedsolving.

Lastly, it's exhausting replying to all this. Can you condense your posts a little in future? Maybe you can come on IRC, I'm more talkative there.

 

[Christopher Mowla]

Lastly, it's exhausting replying to all this. Can you condense your posts a little in future?

Sorry. I try very hard to not write so much, but the large amount of text just reflects how much I have to share (honestly). I always try to be as concise as I can. Even then, there is at least 2 times as much that I can also mention, but I don't.

Your download links are broken.

I just clicked them and it worked. It's weird, but after a few seconds, the download links appear. For some reason, you have to wait longer for the dark color version than the light color version. So try again, and let me know if you can access them after waiting a little longer.

What kind of algs, comms? Do I already know most of them?
...
Recognition sounds fine but the algs don't sound very fast.
...
Are they fast?
...
Like, lots of PLL algs suck

See the document attached to this post (if you haven't already by now). As you will see, most of the 2 2-cycles are just conjugations of r2 (or l2). I have cleverly made all twelve 1 2-cycle and 1 3-cycle algorithms (on page 14 of the document) from one base alg, so I believe I at least took care of the ugliest PLL cases. I have recently edited the document again because I realized that 66 algs are needed, not 56. But the new algs I just added are 3-cycles which you already know.

And, the algorithms I placed in that document aren't the fastest for all of the cases presented. For the 2 2-cycle algs, I tried to focus on using only 8 base algorithms to handle all 29 cases.

Since for the largest group of 2 2-cycles I used the alg [l2 U' F2 U': l2](9), if you don't find that very fast, here are two alternatives:
[Lw2 F2 U L2 U: l2] (11)
[Rw2 F2 L U' L' U': r2](13)
(You can alter these in the same manner that I did with the 9 mover and still get algs for all cases in that group).

Also, note that the other case formed from these algorithms by inverting the single quarter turn faces of U has a fast form for the 9 mover [Lw2 U F2 U: l2](9).

With the exception of most 13 btm and all 15 btm algs that cancel to 11 btm and 13 btm, respectively, due to (L R') and (L' R), I believe I have exhaustively searched all possible algorithms of length (7-13 btm) of the form [A:B] generated by <L,R,U,F,l2,r2,Rw2,Lw2>, and I have to say that the algorithms I have provided in the document for the 2 2-cycles are unique. I grabbed all solutions that begin and end with wide turns, if they had single inner layer turns as equivalents. Hence, they are as good as they get for speed. (This holds true for probably most of the F3L algs too, as many algs in the text document below were used for them).

In fact, I have attached a text document which shows 2,472 algs.
View attachment 2_2-Cycles.txt

If you're overwhelmed, don't worry. I had to sort out the algorithms to be able to use them for F3L. (Sadly I ended up not using most, and I had already found most of the ones I used before I did this exhaustive search).
View attachment Algs_Sorted.pdf
Note that for the group of 2,416 algorithms, I only bothered to sort most of the algorithms that began with either r2 or Rw2 and that conjugated r2 (only 1/4 of 2,416). I also eliminated petty equivalents for the 7 and 9 btm move algs.

All in all, many of the algorithms give the same result on the cube, whether they are mirrors, or if they affect pieces in different faces. In addition, a big chunk of the algorithms cannot be used for F3L or ELL, as they affect wings on opposite faces or in positions which require additional conjugation to be useful (more moves).

There's no point recognizing and working out the alg solve two edges in one when you can execute two fast comms with no pauses faster. (Of course, I'd love you to prove me wrong)

I agree with you for a portion of the cases. However, cases that require 9-10 moves are definitely more debatable. Probably if both wings are in the U-Layer, it's not worth memorizing (for speed purposes, but definitely for move count), but if both wings are in the E-Layer or one wing is in the U-Layer and the other is in the E-Layer, it definitely becomes more tempting (to me at least).

For example, here are a few of the cases that I highly doubt can be handled faster with two algs.
Case 16-6
[z'Lw2U'F2U':l2]
Case 9-15
[z'Rw2U'F2U':r2]
Case 11-8
[x:U'l'r'UR'U'lrUR]
Case 4-13
[x':R2U'l2rUR'U'l2r'UR']
etc.

This seems... unfriendly as a speedsolving approach.

Maybe so, but I mention in the document that 14 base algs are used to form algs for all 211 cases. (Note also that the number of cases we really can say are distinct is 99.) For the cases in the U-Layer and cases in the U-Layer and E-Layer, only 1/4 of the algs need to be memorized because we use the trivial U, U' and U2 conjugations which still keep the move count <=12 btm.

EDIT:
And if you don't count cases which can be achieved with trivial conjugations of U, U' and U2 as well as reflections, inverses and cube rotations, there are 39 distinct algs. (And of course these algs are interrelated as well due to my statement about the fact that 14 base algs are used to make all 211 cases).

 

[Guilherme Barro]

I want to lern but,is too hard.

 

[Christopher Mowla]

I put together a document showing my current best (briefest mainly, but some are okay for execution speed) collection of algorithms for all 58 K4LL 2 2-cycles. I probably explain more than anyone wants to know on the first page. I know that it's possible that I did not arrange the cases the way most prefer, but I tried my best...

I just deleted that post ^ because I updated the document. I went here and looked at the first 82 "seed algorithms" listed (12 moves max) and found briefer algorithms for 14 of the 58 cases.

Here's the updated document:

View attachment 2 2-cycles.pdf
​

I credited this source as "AF" (Algorithm Finder) followed by :S_ _. . The number following the S is the seed algorithm number (the seed algorithms first listed on that page I just provided a link for).

Note that several algorithms that existed prior to generation date of these "seed algorithms" can be made from these seed algorithms, but I did not credit that source for algorithms which I definitely knew existed before. If someone has created one of the algorithms I credited to AF's seeds (prior to December 14, 2011), let me know.

I found multiple solution's from AF for the cases I added algorithms from it to, but many of the solutions were similar (even though 82 seed algorithms are listed, I can definitely say that more than half were closely related), and I chose the best solutions with speed in mind. However, some cases from AF didn't have fast solutions.

All cases now have pure solutions.

In addition, all cases can be handled in 15 btm or less! Here is the btm move distribution (of the shortest algorithms for all size cubes) in the collection provided in my document.

7 (1)
9 (4)
11 (10)
12 (6)
13 (23)
14 (8)
15 (6)

Average: 12.52 btm/case.​

 

[MalusDB]

Sorry for bumping an old thread, but I've followed the link in Kir's OP and its to a dead site pretty much, just ads and stuff. Does anybody know of a new site where Kir has the same info from this site? Was gonna PM him but thought this would suffice, plus this way other people can see. Also since this link is the one in the wiki, it probably should be ammended (assuming I'm not just being a complete tosser and doing something wrong here).

 

[MostEd]

http://snk.digibase.ca/k4/index.htm

 

[MalusDB]

http://snk.digibase.ca/k4/index.htm

Does that link work for you? Thats the one I tried a few times, from different sources and most of them didnt work, with one of them eventually bringing me to a domain that is clearly not kirs page.

 

[MaeLSTRoM]

Does that link work for you? Thats the one I tried a few times, from different sources and most of them didnt work, with one of them eventually bringing me to a domain that is clearly not kirs page.

That is the right link. here's a link to one of the subpages incase its just being odd. http://snk.digibase.ca/k4/1.htm

 

[MostEd]

Ofcourse the link works, its the only link i know of.

 

[Georgeanderre]

Does that link work for you? Thats the one I tried a few times, from different sources and most of them didnt work, with one of them eventually bringing me to a domain that is clearly not kirs page.

That link can be a bit 'iffy' for me, 8/10 days it works fine and loads instantly, the other 2/10 days it either won't load at all or takes forever to open and is just a black page... this used to annoy me a lot but since I printed the pages off I just refer to my notes if I forget anything or need to top up on something

 

[Dav]

Hey!
You've now talked very much about LL, but what about F3L?
I haven't thougt about it in detail, but I think what I would do is more efficient - EDIT: No, it is not, I were just too stupid too read the whole document.
My idea is solving F3L with a kind of keyhole technique.
Because of some reason the explanation isn't displayed the right way here, so I put it into the text file.

Keep in mind that this explanation isn't there to learn it by heart, but only to understand the idea.
Also, this is just an idea and I don't say it's perfect in any way. You may also use only parts of it.

Sorry if my explanation is a bit hard to understand, it isn't easy to explain it without being able to show the cube, and I'm still learning english in school.

EDIT: As I just said, DON'T USE THIS! I don't want to delete this, because there is a reply to this, but don't use this method!

 

[Christopher Mowla]

Hey!
You've now talked very much about LL, but what about F3L?
I haven't thougt about it in detail, but I think what I would do is more efficient (would because until now I'm still stuck with Yau).
My idea is solving F3L with a kind of keyhole technique.
Because of some reason the explanation isn't displayed the right way here, so I put it into the text file.

Keep in mind that this explanation isn't there to learn it by heart, but only to understand the idea.
Also, this is just an idea and I don't say it's perfect in any way. You may also use only parts of it.

Sorry if my explanation is a bit hard to understand, it isn't easy to explain it without being able to show the cube, and I'm still learning english in school.

You didn't see my post? (That when you solve both wings in a F3L slot simultaneously (with the same alg -- which would never need to be more than 12 moves (with the exception of one case's alg which is 13 moves.)

(If you're waiting for Thom (Kirjava) to reply, he did make a special section for handling one wing edge at a time (and two at a time if they are both in the E-layer) on his method's website.)

And how many moves would your keyhole approach complete one wing at a time if they are done individually (which seems to be what you're approach is). Because it only takes 7 to 8 moves to solve one if the wing is in the U layer (just a modification of Niklas).

 

[Dav]

Oh, I'm really sorry, I didn't see your post.
I just looked at this link and didn't read everything, because it first looked similar to what I did when I figured out a LBL method myself.
I won't delete the comment but edit it, so it's safe that nobody uses that.
Thanks for showing me the right way.
Sorry for that, Dav