Solving Methods; A Primer

[mark49152]

You should read the paragraph I wrote before the one on multi-systems again.

That's a cop-out - a couple of posts ago you were trying to draw a line, now you're referring me back to your earlier comment that it's hard to draw a line

Anyway, I agree with that paragraph.

You didn't take the bait with CPLS in my "extensions" list. Obviously it changes the usual CFOP step order, meaning that by your definition using CPLS would be a different method not an extension.

 

[Kirjava]

Seems like you're trying to 'catch me out' or something. It's not always easy to fit things into the exact definitions I defined. Many things can fit into multiple ones.

CPLS is a different method because it has different steps. CPLS is an extension because it is a type of partial step concatenation.

Shades of grey exist in the world.

 

[mark49152]

Seems like you're trying to 'catch me out' or something.

Well not really - I was just challenging your earlier yes/no answers about COLL/EPLL and CLL/ELL. I agree that it's shades of grey, that's kind of my point.

The forking/multisystem thing is really interesting as a general concept, regardless of whether the different forked paths qualify as the same or different methods.

 

[elrog]

I don't see why everyone thinks forking is such a great idea. It wouldn't be good at all for speedsolving. You have to recognize 2 different approaches before you do eather one. Even if you get a better alg to preform, you used more time inspecting. Also, if a solve ends up having a really good case for the one path someone else does, you using a fork to check for that other path would slow you down. Also, having more algs means you won't get as proficient at preforming all of them, it's a pain to memorize extra algs, and it makes you have longer recall time.

I can see how learning an extra fork to a method would help in FMC, but I'm still not convinced that it is worth it. If your going to learn alot of algorithms for different forks, just learn ZBF2L/ZZLL or something like that.

 

[CubicNL]

Thank you for writing these things down in such an orderly fashion, finally a clear piece on this topic.
I agree with most of the things you brought forward. With regard to the intuitive/algorithmic part I think that the future of speedsolving lies in intuivity and that that ultimately will show up as the key to speed.
Lastly I'm not sure whether beginners in method developement should extensively study existing methods and ideas. I certainly think that it prevents you from making lots of mistakes, but it may just pigeonhole the person having the one innovative idea into the existing ideas. My call would be that we do indeed have powerful method structures (with my personal favourite being roux), but maybe that's just because I'm pigeonholed as well.

 

[Kirjava]

I don't see why everyone thinks forking is such a great idea. It wouldn't be good at all for speedsolving. You have to recognize 2 different approaches before you do eather one. Even if you get a better alg to preform, you used more time inspecting. Also, if a solve ends up having a really good case for the one path someone else does, you using a fork to check for that other path would slow you down. Also, having more algs means you won't get as proficient at preforming all of them, it's a pain to memorize extra algs, and it makes you have longer recall time.

All these things apply to OLLCP and CMLL+EO too, and people have no issue using these to improve their technique.

There are good arguments against forking to a different system, but you are not making them.

With regard to the intuitive/algorithmic part I think that the future of speedsolving lies in intuivity and that that ultimately will show up as the key to speed.

Really? I'm almost convinced that brainlessness is the key to speedsolving. Intuition will allow you to find good shortcuts, but that needs to be executed algorithmically when solving to achieve an advantage.

Lastly I'm not sure whether beginners in method developement should extensively study existing methods and ideas. I certainly think that it prevents you from making lots of mistakes, but it may just pigeonhole the person having the one innovative idea into the existing ideas.

I see what you're trying to say, but it's a bit silly. If people do not know what methods exist, they are doomed to rediscover them.

Surely having wider knowledge won't hamper your creativity?

 

[MaeLSTRoM]

Surely having wider knowledge won't hamper your creativity?

Potentially more to the point, if it does then you're not having original ideas :b

 

[CubicNL]

Really? I'm almost convinced that brainlessness is the key to speedsolving. Intuition will allow you to find good shortcuts, but that needs to be executed algorithmically when solving to achieve an advantage.

Yes, algorithmic execution is the fastest, but only if it comes from intuition. And I'm just doing a wild guess for the future, who knows what will be possible in 50 years..

I see what you're trying to say, but it's a bit silly. If people do not know what methods exist, they are doomed to rediscover them.

Surely having wider knowledge won't hamper your creativity?

If people continue to rediscover them then we probably have the best ideas already.
And I guess, or actually hope that you're right about more knowledge not hampering creativity. After all we can't really know the answer to that unless someone comes up with something.

 

[jayefbe]

Lastly I'm not sure whether beginners in method developement should extensively study existing methods and ideas. I certainly think that it prevents you from making lots of mistakes, but it may just pigeonhole the person having the one innovative idea into the existing ideas.

I call this the "I don't want to learn music theory because I won't be as creative" argument. Being a guy who used to play in bands through my teens and early twenties, I heard this argument many many times. Invariably it came from someone incredibly lazy, who had merely rationalized his laziness. I don't agree with it. A truly creative person is able to integrate what has been done before, and is then able to apply that knowledge in innovative ways.

And the "rediscovery" of the same methods over and over again doesn't necessarily mean that these are the "best" methods. More likely, they're the simplest and most obvious ones. Not necessarily mutually exclusive, but I wouldn't use that as an argument supporting how good an idea or method is.

 

[CubicNL]

I call this the "I don't want to learn music theory because I won't be as creative" argument. Being a guy who used to play in bands through my teens and early twenties, I heard this argument many many times. Invariably it came from someone incredibly lazy, who had merely rationalized his laziness. I don't agree with it. A truly creative person is able to integrate what has been done before, and is then able to apply that knowledge in innovative ways.

And the "rediscovery" of the same methods over and over again doesn't necessarily mean that these are the "best" methods. More likely, they're the simplest and most obvious ones. Not necessarily mutually exclusive, but I wouldn't use that as an argument supporting how good an idea or method is.

I think the comparison between music and cubing is not completely correct here. Finding a truly new concept for a speedsolving method could, if something like that is ever found, mean that that concept goes in against the established ideas. Being creative in music is usually only hailed if you are creative somewhat between the boundaries of the established genres/musical language. Also we're talking about someone who would be a pioneer in speedsolving and I don't think all music pioneers based themselves upon existing theory.
You must understand that I am not totally against exploring methods first, that seems like a completely logical thing to me, I just hope that some idea won't be held back.

About the rediscovery I must agree with you. But what I meant is that if a lot of people who think about the best ways to solve the cube can't come up with any better system and keep falling back on the existing ones, that those are probably pretty good. Of course not necessarily the best.

 

[elrog]

All these things apply to OLLCP and CMLL+EO too, and people have no issue using these to improve their technique.

There are good arguments against forking to a different system, but you are not making them.



Really? I'm almost convinced that brainlessness is the key to speedsolving. Intuition will allow you to find good shortcuts, but that needs to be executed algorithmically when solving to achieve an advantage.

Every arguement I made is a valid arguement. Is the arguement that you take 2 times the inspection time not a strong arguement?

I don't beleive that the furute to speedsolving lies in algorithms. Algorithms have basically been used to their maximum potential now and intuition still has room for improvement now matter how good you are. There is just so much more potential in intuitive solving.

If your thinking your going to somehow come up with better algorithms for a new, better step, I'm just telling you now that it probably won't happen. The only way to make an algorithmic solve better is if you couldsolve more with a single algorithm, but that requires alot of algorithms hindering you to master and recall every algorithm quickly.

 

[mark49152]

Intuitive solving reduces move count but also reduces tps. Looking at stats for CFOP solvers, F2L is always slower than LL. I would guess the same is true for Roux's steps.

Since solve time depends purely on move count and tps, logic suggests that a good method requires a mix of both algorithmic (to get big chunks of solving work done at high tps where intuition would reduce tps too much) and intuitive (to save moves where use of algorithms would push the move count too high or reduce overall tps through poor recognition or recall).

I believe the ideal method would find the sweet spot between the two. That's what today's methods look like too.

Forking is interesting because it might provide a way for algorithmic steps to become more efficient. For example, some OLL algs save significant move count over 2-look and are fast, but others save relatively few moves and of course receive much less practice than the 2-look algs. Therefore it doesn't make sense to think of full OLL as a monolithic set that must always be learned in its entirety. For some of those OLL cases, there might be an alternative solving route that is faster, and I don't see why recognising and recalling that step would require any more time than recalling the OLL alg for a case.

 

[Kirjava]

Every arguement I made is a valid arguement. Is the arguement that you take 2 times the inspection time not a strong arguement?

It would be if it was true.

Recognition is not even close to being the overhead that people assume it is. I simply can't accept this argument after going from recognising one step to recognising two in my main speedsolving method without any kind of issues at all.

I don't beleive that the furute to speedsolving lies in algorithms. Algorithms have basically been used to their maximum potential now and intuition still has room for improvement now matter how good you are. There is just so much more potential in intuitive solving.

2L1A step concat is an algorithmic improvement that hasn't been used yet. Others are sure to exist. Making assumptions about 'maximum potential' and what is possible is a bad idea.

I don't think there much substance to what you're saying. Intuitive solving is only as good as the human executing it. It needs to become brainless to reach any kind of decent speed.

This is not a 'algorithm' vs. 'intuition' argument. Obviously both have their places. Saying one is oh so much better than another is just silly.

a good method requires a mix of both algorithmic (to get big chunks of solving work done at high tps where intuition would reduce tps too much) and intuitive (to save moves where use of algorithms would push the move count too high or reduce overall tps through poor recognition or recall).

thumbs up

 

[elrog]

It would be if it was true.

Recognition is not even close to being the overhead that people assume it is. I simply can't accept this argument after going from recognising one step to recognising two in my main speedsolving method without any kind of issues at all.



2L1A step concat is an algorithmic improvement that hasn't been used yet. Others are sure to exist. Making assumptions about 'maximum potential' and what is possible is a bad idea.

I don't think there much substance to what you're saying. Intuitive solving is only as good as the human executing it. It needs to become brainless to reach any kind of decent speed.

This is not a 'algorithm' vs. 'intuition' argument. Obviously both have their places. Saying one is oh so much better than another is just silly.

I don't see how it is possible that you wouldn't take more recognition time to recognize 2 substeps rather than one. It is only possible that recognition time wouldn't matter if you recognize both before you even get to the step, which isn't always even done with only one substep.

I think you meant 1L2A rather than 2L1A. That is the system that you were working on. I think that you will have lowered recognition time due to the fact that you recognize both algorithms with 1 look, but it wont be cut in half. What has me thinking that this might not be the best idea is that you have to know every position the last layer can be in which I can see leading to major recall problems. This is the same reason that no extremely large algorithmic steps have been proven to be worth it yet.

It would also be possible to look at the last layer and predict the PLL after doing the OLL by learning each last layer case. I think it is pretty genius to use a set of unrelated algs that still is able to cover every case.

I also agree that you need the right balance of intuition and algorithms, but I think people are moving farther to the algorithmic side because its easier.

 

[BaMiao]

I don't see how it is possible that you wouldn't take more recognition time to recognize 2 substeps rather than one. It is only possible that recognition time wouldn't matter if you recognize both before you even get to the step, which isn't always even done with only one substep.

It's totally possible to use forking without sacrificing recognition time. I think it would be akin to when you spot two potential pairs during an f2l, and deciding which one to tackle first. It isn't that difficult.

For example, say you start with a 2x2x1 block, Petrus-style. The next thing you see determines whether to extend that to a 2x2x2 and continue with Petrus, or extend to 3x2x1 and continue with a Roux solve. Or, you can spot an opportunity to construct pseudo-blocks, etc.

The key is in going with what the cube gives you. You don't have to recognize every possibility, the same as how you don't have to look for every f2l pair after finishing the cross, and then deciding which one is most efficient.

 

[Kirjava]

I don't see how it is possible that you wouldn't take more recognition time to recognize 2 substeps rather than one. It is only possible that recognition time wouldn't matter if you recognize both before you even get to the step, which isn't always even done with only one substep.

I switched from recognising CMLL to recognising CMLL and EO a few years ago. I now recognise CMLL+EO faster than I ever did CMLL alone, so it has not become some kind of speed bottleneck that you seem to assume it would - and the recognition time has certainly not doubled.

I think you meant 1L2A rather than 2L1A. That is the system that you were working on. I think that you will have lowered recognition time due to the fact that you recognize both algorithms with 1 look, but it wont be cut in half.

If you think that you recognise both algs with one look in my system, you don't understand the method.

I also agree that you need the right balance of intuition and algorithms, but I think people are moving farther to the algorithmic side because its easier.

Can you explain why you think this is true or when people moved? Speedsolving method use has been mostly static in the last few years with the one exception being Roux, which itself is a shift towards intuitive based solving.

The key is in going with what the cube gives you. You don't have to recognize every possibility, the same as how you don't have to look for every f2l pair after finishing the cross, and then deciding which one is most efficient.

Your post sums it up quite nicely. It won't cause any problems if you're only doing it when you see it.

 

[Logiqx]

I wondered if I could draw a diagram showing the better known 3x3x3 methods, grouped into basic categories. The approach to categoristion is not directly related to the thought process during a solve and is simply based on whether there appears to be a bias towards solving edges or corners, blocks or layers.

This was just a little exercise for myself whilst reading about all of the methods listed in the wiki. Perhaps it is of no interest to anyone else but I enjoyed thinking it through with my limited knowledge of the methods!

The diagram below is without doubt an over-simplification of the many methods available but related methods have still been clustered together. On the flipside you may also see methods which don't seem particularly similar quite close together. I've shown some of the stronger links between methods with dotted lines.

The image itself - http://cubing.mikeg.me.uk/Methods.jpg

My approach to categorisation was done intuitively in most cases and consisted of 2 steps:

1) Choose the quartile - e.g. edge bias (edges solved when no more than half of corners solved) or corner bias (corners solved when no more than half of edges solved). If it's neither edge biased or corner biased then it is a simple call to whether it is primarily a block-building method or layer-by-layer / algorithmic method.

2) Choose one of 3 segments within the quartile. e.g. Block / Layer methods might solve all of the corners before finishing with edges. Corner / Edge methods might have a bias towards blocks or layers at the beginning of the solve.

Known variations of a given method will generally leave it in the same segment or move it into an adjact segment.

I said earlier that this was really just a little exercise for myself whilst reading about different methods. Thoughts / comments are welcome though!

 

[irontwig]

Made something similar way back when:

http://www.speedsolving.com/forum/attachment.php?attachmentid=1391&d=1292924809

 

[Cubenovice]

The image itself - Methods.jpg

Nice effort.

But in my humbl opinion Human Thistlethwaite and Human Kociemba are not block biased.
Perhaps you could move them to the empty slice below Edge Bias and label them as something "EO / Reduction / Separation"

 

[GaDiBo]

Why those pictures still don't have ECDU method?