Low move count speedsolving method idea

[elrog]

I have already made the algs findertricky as I go. I think it would be perfectly possible to get 45 average moves while speedsolving with this method as I have already taken into consideration fingertrickiness and turns between steps and algorithms. Also, next time someone has the ability to learn 300 algorithms, let alone recognize it quickly, give me a call. This isn't a belt method as you first solve orientation, not a belt. After solving orientation, you seperate the top and bottom corners to do an algorithm that creates columns. Not a belt method.

 

[qqwref]

IMO any method that very quickly solves the middle edges is of the belt type. As I understand it yours solves orientation and then immediately solves the middle edges.

Also, please please please please please use more line breaks in your posts. When it's just a single unbroken stream-of-consciousness wall of text (e.g. post 14-15) it's really hard to follow. At least make a visual break when you go from one idea to a totally different one. Plus, I think you'd become more organized in your thoughts if you put more organization into your writing.

 

[somerandomkidmike]

The second thing you do in this method is solve the "belt" or middle layer. That's why I said that it seems like another Belt variation.

By the way, I agree with qqwref that you need to organize your ideas a little bit better on here. If you want anybody to take this method seriously, you should at least organize your ideas in a way that's easy to follow. If you want an example of a well-constructed tutorial on this site, have a look at Waffle's Roux tutorial.

( http://www.speedsolving.com/forum/showthread.php?11506-Waffle-s-Roux-Tutorial )

 

[elrog]

Sorry. I will try to organize myself better in the future. Yes, this method does solve the belt, but it solve all the corners at the same time, so would it not be considered a columns first method also? If you really want to get technical, it is an orient first method because you orient first. This method needs a more distinct name than a mix of a belt, columns, and orient first method. By name I do not mean the name of the method, though if you have suggestions that'd be nice.

Is this too much text in one place? It sort of switches topic, but it is only a few lines.

 

[qqwref]

would it not be considered a columns first method also?

I don't think this is really a designation people use. Also, columns in the way you're using them are already more than half of the puzzle, so it's kind of silly to say you do that "first"

If you really want to get technical, it is an orient first method because you orient first.

That's not being technical, it's just putting this method in another class. There are many possible classes each method falls into, which is why we usually only refer to things by a class (e.g. "corners first methods") when that is the main feature of the method. Making a belt first is a pretty big deal in terms of restricting freedom, so it makes sense to talk about belt methods as a whole group.

This method needs a more distinct name than a mix of a belt, columns, and orient first method. By name I do not mean the name of the method, though if you have suggestions that'd be nice.

Then what do you mean? And if you want a name, you'd probably be best making one - see if you can think of some kind of memorable thing that makes this method distinct.

 

[redbeat0222]

Well if you looking to not speedsolve then learn it. If you want a speedsolving method with FMC learn Roux or ZZ

 

[elrog]

Thanks for your reasoning qqwerf. Redbeat, I dislike ZZ F2L as it doesn't seem worth it sacrificing move count almost entirely for the sake of turn speed whilst quick turn speed can be accomplished without sacrificing move count. Just to make a point, look at Feliks Zemdegs. Regular F2l is just as good, if not better than ZZ F2L. I also prefer ccolumns first over roux as I've already stated before. I'd appreciate it if someone would make a comment besides telling me to use some other method.

I have been thinking about the best way to get everything oriented. It seems that algorithms would be the fastest for recognition. If you were to orientate all the edges and place all of the E edges in the E layer, it would require 81 algorithms to permute all of the corners in 1 step. I found two different solutions to this problem.

This could be reduced down to 37 if you got two adjacent corners orientated correctly after all the egdes are oriented and the E edges are in the E layer. Orientating 2 corners could be done while placing the E edges in the E layer just incase you have no corners orientated afterwards.

I have also found that 2/3rds of the times you are going to solve all 8 corners, you will have a case that has an uneven number of corner flips in the top and bottom layer assuming you look at them seperately. Because the total cubes number of corner flips has to be 0 after opposite direction corner flips are cancelled out, you must have a case on bottom with the total number of corner flips be the opposite number of the ones on top, meaning that you can do a x2 or z2 move to cut the number of algs in half, so this would require only 25 algorithms. If you did get a case with an even number of flips, you will have to do a R2 move or the like to make it odd. I did take into consideration the cutting the number of algs in half for uneven cases when I stated that it would take 81 algs to solve all 8 corners in 1 step.

If I chose to do the 37, this would bring the total alg count up to 84 up until the last 8 edges. If I used the 25 algorithms, it would take 72 algorithms. I have also nearly completed the algorithms to get 4 columns completely in 1 step after orientation is complete. I have also found that these can be recognized quickly from looking at only 2 sides except for 2 cases for the middle layer. One ase is it being hard to distinguish between its own inverse.

 

[qqwref]

How do you get the numbers 81/37/25? I ask because I'm not getting the same numbers.

 

[elrog]

The 37 is wrong. My mistake. It should be 40.

I figured the 81 by first finding the cases that include the 7 corner OLLs. There are 8 cases including solved. 8 possibilities for top and bottom means 64 possibilities. You will have 8 cases for the bottom solved and the top not, and 8 for the top solved and the bottom not, which are the same thing if you use cube rotations giving you minus 8 algs or 56.

I got the 25 by finding that there are 5 possible cases that the top or bottom can be put in to have the total number of corner rotations plus 1, and 5 for minus one. Any time a plus one case is present on the top, a minus one case is on the bottom and vice versa. If you were to use cube rotations to always have the plus/minus 1 on top, you would have 5 possibilites for the top and bottom giving you 25 total cases. If you add these you get 81.

I also found the 37 in a similar fashion. I found that if you have the BDL and FDL corners correctly orientated, and you have a case with even permutation for the top/bottom layers, you have 3 possibilites including solved. You have 7 OLL possibilites for the top. Multiply and get 21. Subtract the solved case and get 20. For cases with an odd permutation, there are 2 cases for the bottom to have a overall plus 1 orientatin and two for it to have a overall minus 1 orientation. Therefor there are 10 cases with a plus 1 orientation on top, and 10 with a minus 1 orientation on top. 10 plus 10 plus 20 gives you 40.

If I am wrong about these, please tell me, tell why, and if you can, tell how many algs it actually should be. Thank you.

EDIT: You may also get 3 middle edges and 3 corners on bottom and solve the last 5 corners while insterting the last middle edge with 28 algorithms from WV/F2LL.

 

[qqwref]

OK, so here's how I'd reason it. We want to figure out the number of possible cases, assuming we are allowed to do U/y/x2 moves to set up to our case. Allowing mirrors/inverses would decrease the number more, of course.

Two possibilities:
- Total of 0 corner twist on both the top and the bottom. There are 8 possibilities for a single layer, including solved. If we number the cases 1-8 we could rotate so that the bottom case is always <= the top case. This gives 1+2+3+4+5+6+7+8 = 36 possibilities, including solved.
- Total of +1 corner twist on one side and -1 on the other. We can always rotate so that the top case is +1. There are in fact 8 cases for each type (see http://cube.garron.us/MGLS/I.htm), so there are 8*8 = 64 possibilities overall.

Not including the solved case there should be 35+64 = 99 total cases, if I counted right.

 

[cuBerBruce]

OK, so here's how I'd reason it. We want to figure out the number of possible cases, assuming we are allowed to do U/y/x2 moves to set up to our case. Allowing mirrors/inverses would decrease the number more, of course.

Well, you can certainly reduce by mirrors. I assume maneuvers can arbitrarily permute the corners, so inverse cases are not well-defined. For a given maneuver you choose to use in solving some case, you could see what case its inverse solves and eliminate that case (if you haven't already chosen a maneuver for that case).

 

[qqwref]

Good point about inverses. I suppose depending on whether we sort before or after this step we may not even be sure if the inverse will have the same total orientation on each layer (e.g. R2 U' L2 U R2 U' L U R U' L U R').

 

[elrog]

Hmm. I see where I went wrong. I was counting a case with headlights on top and T on bottom seperate from T on top and headlights on bottom. Not just with that case of crouse, but with all situations like that. I redid my math the way I did before counting that and got 35 cases for even permutation cases. I did find though that there are not many inverses that can be taken advantage of because most of the 7 OLL cases don't have inverses. I came up with 27 cases not counting inverses.

I also recalculated the alg number for already having 2 corners solved keeping the fact in mind that there are 8 possibilites for uneven cases and I got 53. There is also a 2x2 method that orients all the corners as long as 2 are correct and are adjacent, and it said it uses 53 algs, so I assume this is correct. So now I can eaither do what I did before to get all uneven cases, and use 64 algs, I can use 53 algs after 2 corners are correct, I can try to get the top/bottom layer in even orientation and use 35, or I can use 28 while inserting the last edge.

In reply to what cuBerBruce wrote, with some uneven cases, there may be a case thats moves to solve are the inverse of anothers, but you still have to memorise the case, unlike if you were reflecting a case to the left/right side. I count left/right side as the same when not counting inverses, but I don't count the inverse set of moves.

EDIT: I meant orientation not permutation as you pointed out cuBer Bruce. I just typed the wrong word. I did not mean that any orientated pieces would be misoriented in the same direction. I was actually saying that the type of case you just pointed out, truely is an inverse case, but I don't consider it one while learning the cases because they are different enough that you have to learn both cases, whereas you can do an algorithm on the right side and left side by only knowing one side.

To clarify, you wouldn't be able to know how to solve a case that is the inverse moves of another case without knowing that case. Using inverse to mean this situation often makes the number of algs less than it actually is for a human learner to memorise. This is why I consider the G perm, 2 seperate cases. The left and right side are the same, the inverse is another case.

Yes you did have my interpretation of uneven cases correct.

 

[cuBerBruce]

elrog, you seem to misuse the word permutation. Permutation has to do with the way in which pieces have been moved around with respect to where they are when solved (or with respect to some previous point in time), ignoring orientation. It seems like you are using permutation to mean the net twist of a set of corner pieces.

My point about inverses is that the cases do NOT have well-defined inverse cases. For example, two ways you could solve headlights on top and bottom are:

(1) R U R2 D R U2 R U R'
(2) R U' L2 U2 L U' R' U L

The inverses of these maneuvers,

(3) R U' R' U2 R' D' R2 U' R'
(4) L' U' R U L' U2 L2 U R'

do not solve the same case. Just do maneuvers (1) and (2) on a solved cube to see what cases are solved by (3) and (4), respectively.

I think you are using "inverse cases" to mean that any misoriented pieces would be misoriented in the opposite direction. This would be equivalent to what you would have for inverse cases if you assume maneuvers are only allowed to twist the corners in place. However, you need to be aware that inverses of maneuvers will not (in general) solve the "inverse case" if you define "inverse case" in this way.

By "uneven cases" I think you mean the cases such that the net twist in the top layer is not 0 (mod 3), and thus, the same is true of the bottom layer. (In other word, the cases other than the "OLL cases" and the solved case.)