Kirjava
Colourful
This thread will attempt to give an extensive introduction to
properties different methods have. I will also give my thoughts on
each.
As well as people developing methods or considering new techniques, I
hope this may help the way you perform or think about regular
speedsolving.
Basics
Solving methods consist of any number of steps which contain
instructions detailing how to bring the cube from one state to
another. In 'good' methods, each step will attempt to take maximum
advantage of the state of the cube. This makes analysis of first steps
quite interesting - with so much freedom it makes sense that no
specific step seems to be much more useful than alternatives. A step
may accomplish more than one thing at once.
Method definitions often break up one step into many smaller,
systematic, and human sized chunks. These chunks are essentially part
of the same step. "blockbuild stuff" then "blockbuild more stuff"
becomes "blockbuild a lot of stuff". It can be advantageous for a
human to be aware of these abstractions and ignore them.
On the point of steps starting to blend into each other, it's worth
noting that it's difficult to exactly define the term 'method'. Minor
variations give rise to different, yet closely related systems.
Classifying these systems as completely new methods feels needless,
yet it is difficult to draw a line.
Something that seems unpopular these days is a 'multi-system' (as
described by Singmaster). This is where a method will 'fork' at a
certain step and finish in different ways depending on the direction
forked. The direction chosen to fork in is based on which can take the
best advantage of the current situation, but either can be chosen if
desired. Examples of this technique can be demonstrated by creating
hybrid methods which will allow forking between the two at certain
stages. Multiple forks in the same method are not feasible/sensible
imo. This idea can be seen when using separate algs for special cases
to achieve more than the original intention of the step.
This is closely related to being 'method neutral' - being closely
proficient enough at multiple methods to allow you to choose the
method when starting the solve based on the scramble. The difficulty
in obtaining this skill for the solver requires either to initially
learn two methods at once and practise both, or to practise one method
and at a later date attempt to practise another and bring it up to the
proficiency of the first. The problems with the latter technique are
similar to that of switching to colour neutral.
Step method order may not be fixed. Methods designed for blindsolving
can have this attribute - because of the nature of the method, where
each algorithm (mostly) leaves the rest of the cube alone, the order
is less important and changing it can be trivial.
Solving Types
In this section, I will analyse the types of technique used to
complete a step. This can mean two different things (that have their
own categories) - the human approach to completing the step and what
type of state change has taken place during the step.
There are a few systems that humans use to accomplish steps. The most
apparent one being the algorithmic approach to something. Called "the
worst thing in speedcubing" by Gilles Roux, this system enumerates the
cases in a given step and lists solutions for each. The solver will
then learn a solution for each case so that when it appears in a solve
they can recognise and recall the solution from memory.
An algorithmic approach can be used in steps that are traditionally
seen as intuitive based, but this is not generally advised - it
usually entails using some basic tricks or rules to reach a state that
you have an algorithm for. This is seen to generally lead to longer
solutions, but that does not make it worse.
An intuitive approach to solving a case is arrived at by logic and
reasoning that has been generated by experimentation. I think the
ability to use intuition to generate solutions for something is
important - it demonstrates awareness of the effect caused by applying
moves which is an important trait in understanding the cube and
shortcuts available. In comparison to algorithmic approaches, a
solution for each case is discovered by the user using logic or trial
and error. Cases may be improved over time as the solver's ability to
intuit more efficient solutions improves.
Many steps can be approached in either an algorithmic or intuitive
way, but some may require either one of the other to be used.
Something of note is that after a while, whichever approach you take
appears to converge towards the other. That is to say that intuitive
approaches to cases begin to become second nature and are executed in
the same manner as algorithms, while the solver can gather an
understanding of how an algorithm works the more familiar he is with
it. In situations where either approach can be used, the labels
intuitive/algorithmic describe the learning process - as the end
result is essentially the same.
A learning system that doesn't quite fit into either category is a
rule based one. This consists of specific things to perform for one
of many cases. There will be different groups of cases that require
the same thing to be performed to advance to the next part - which
will either be another case from a category, or completion of the
step. Examples of this are the edge orientation step from the Roux
method, dual alg single step systems for LL (Petrus 270, OLLCP hax),
or some cubeshape systems for Square-1. I like to call these systems
'flowcharting systems' as the data can be expressed as a flowchart.
Another rule based system involves using a formula to generate move
sequences. The only examples I can think of that do this are
commutators and conjugates. This involves using a formula to create an
algorithm to perform a certain task. While intuition is required to
create the different parts of the formula, the structure of the
algorithm created is predefined. This appears to result in a system
that allows creation of predictable results that can be used
'on the fly' without premeditative learning.
As with other systems, these will eventually become algorithmic *and*
intuitive.
There are two different state changes that a step can accomplish.
Direct solving is the most prevalent and *has* to feature in a method
at some point for a cube to be solved. With this technique, pieces
dictated by the step are fully permuted and oriented. With respect to
a given reference. This does not have to be an external reference
point, and does neither have to be the same reference point as in
previous steps (pseudoblocks).
Quoting Quadrescence: "I think if you are directly solving, you have
an absolute reference point throughout the process". While this
contradicts what I am saying, I see it as a perfectly valid view on
what constitutes direct solving. This is a good example of the grey
area seen when describing these concepts, which I have had trouble
with when writing this article.
Reduction is not a requirement for a method, but can be a powerful way
to bring a cube closer to solved. When a step involves a reduction,
there is a subset of states that the cube is required to be in for
completion of the step. The step after will only deal with solving
those states, so removal of others facilitates completion of the step.
This also further reduces the number of states a cube can be in,
bringing it closer to solved. While this is also true for direct
solving, the required states do not require pieces to be permuted or
oriented correctly. Certain attributes can instead be enforced that
involve *only* permutation or orientation, or pieces to be grouped in
certain ways.
Some steps contain a mixture of both types, like direct solving some
pieces and reducing others.
Pseudo solving is an interesting quirk. This entails solving to a
state whereupon after normal conclusion of the method, extra moves
will be required to resolve the pseudo creation. So instead of solving
to a solved cube state, you are solving to the state of one (or more)
moves away and then adding those moves at the end. This can be
advantageous because pseudoblocks may be easier to create than the
normal blocks required.
A pseudo move can be applied over the course of a few steps and can be
used with either direct solving or reduction.
Method Feasibility
Unfortunately, most metrics for measuring method feasibility cannot be
quantified easily. Along with personal preference, this makes
comparing different systems a mostly subjective ordeal.
A major aspect of what constitutes a good method is the movecount.
While this is not the quintessential element in deciding how well a
method will perform, it is a purely quantifiable attribute that gives
a good indication. All major speedcubing methods in use have a similar
movecount, with ones giving a higher movecount providing advantages in
other areas.
Because of the human element to speedsolving, ease of use is another
key factor. Methods that are without complication tend to fare better
as they are more attractive to learn and receive more testing. While
more complicated methods may perform better in the long run,
demonstrating this fact proves difficult when no one desires to try.
Methods with complicated steps also require extra thinking time, which
should not be present when speedsolving. A disadvantage in many
methods with low movecounts is the thinking time required to execute
certain steps.
Another ease of use issue is the required learning overhead. This
usually means the quantity of algorithms required to be learnt in
order to fully utilise a method. Methods with less algorithms tend to
rely on using more steps and intuition, leaving a less efficient
overall solve, while methods with algorithms numbering into the
hundreds give a steep learning curve and difficult implementation.
After initial learning of a large algorithm set, this difficulty
results from the trouble caused by attempting to recall an algorithm
from such a large subset without thinking time. While recognition of a
case from a large subset is also an issue, it is not as significant as
recall. So far, no one has been able to show proficiency with an
algorithm set numbering in the hundreds matching that of lower sizes.
As for the algorithms themselves, subsets requiring algorithms do not
usually restrict to a certain movegroup - so users can find different
to suit their preferences as they please. However, more intuition
based steps tend to lend themselves to being executed with certain
movegroups. Steps with fingertrick friendly movegroups generally fare
better than others - but this aspect is largely affected by personal
preference.
Extensions & Variations
Each base method can have countless variations and extensions.
Usually, a step or group of steps can be accomplished with multiple
systems that are of seemingly near equal feasibility. There are almost
endless combinations of alternative approaches to things.
Forced step concatenation is a popular idea for extending a method.
This involves learning how to solve two steps at once, usually
resulting in a huge increase of things to learn. When creating a
method, this should be performed on each couple of steps to ensure
maximum efficiency is produced. However, this is not always humanly
feasible to do.
A similar idea is to solve only part of the next step instead. This
gives you a subset of cases for the next step. The intention would be
to make this subset of cases be nicer than the larger set is. It's
debatable if the time saved by having better cases is negated by
getting to that subset in the first place.
Another use for partial concatenation is to reduce the number of cases
enough so that full step concatenation can take place with the reduced
step and the step after that.
Alongside different variations, systems exist that only apply in
certain situations. While these systems provide advantages in these
situations, they are not useful for every cube configuration and are
not considered complete systems. While learning tricks for magical
special cases will usually be advantagous, implementing them in solves
can introduce recognition or recall issues. Tricks like these usually
entail forcing skips of some kind.
New Method Development
People creating methods solely for entertainment purposes can skip
this section (and indeed the entire thread).
Researching existing methods is extremely important to the development
of your own. Not only will this cause you not to regurgitate methods
that we have seen over and over again, it will give you ideas of your
own. You will be able to see what works and what does not work as you
can see what is popular and used to attain good results already.
Most techniques have remained largely unexplored due to the difficulty
of testing new ideas. Do not discount them simply because they are not
popular - there are good examples of systems with low usage going to
achieve better results than their popular counterparts. Bearing this
in mind however, you should learn to be able to judge if a system has
outright bad attributes that make it undesireable for use. Bearing
that in mind, consider that your judgement may be wrong
Alternatives to existing steps are a good place to start, as these
currently have the highest opportunity for producting completely
viable results. This doesn't give a very interesting outcome though as
the alternative will often be similar results wise as the existing
system, with less documentation and use.
These days it seems that most trivial and obvious full methods for
well known puzzles have been completely covered. Creating brand new
ideas or improving existing ones seems to have to rely on really
abstract concepts.
You should be aware that most of your ideas will not work or will be
unsuitable for speedsolving. Be prepared to let go of an idea if it is
bad - remaining objective is key.
TL;DR METHODS!!!!!!11
properties different methods have. I will also give my thoughts on
each.
As well as people developing methods or considering new techniques, I
hope this may help the way you perform or think about regular
speedsolving.
Basics
Solving methods consist of any number of steps which contain
instructions detailing how to bring the cube from one state to
another. In 'good' methods, each step will attempt to take maximum
advantage of the state of the cube. This makes analysis of first steps
quite interesting - with so much freedom it makes sense that no
specific step seems to be much more useful than alternatives. A step
may accomplish more than one thing at once.
Method definitions often break up one step into many smaller,
systematic, and human sized chunks. These chunks are essentially part
of the same step. "blockbuild stuff" then "blockbuild more stuff"
becomes "blockbuild a lot of stuff". It can be advantageous for a
human to be aware of these abstractions and ignore them.
On the point of steps starting to blend into each other, it's worth
noting that it's difficult to exactly define the term 'method'. Minor
variations give rise to different, yet closely related systems.
Classifying these systems as completely new methods feels needless,
yet it is difficult to draw a line.
Something that seems unpopular these days is a 'multi-system' (as
described by Singmaster). This is where a method will 'fork' at a
certain step and finish in different ways depending on the direction
forked. The direction chosen to fork in is based on which can take the
best advantage of the current situation, but either can be chosen if
desired. Examples of this technique can be demonstrated by creating
hybrid methods which will allow forking between the two at certain
stages. Multiple forks in the same method are not feasible/sensible
imo. This idea can be seen when using separate algs for special cases
to achieve more than the original intention of the step.
This is closely related to being 'method neutral' - being closely
proficient enough at multiple methods to allow you to choose the
method when starting the solve based on the scramble. The difficulty
in obtaining this skill for the solver requires either to initially
learn two methods at once and practise both, or to practise one method
and at a later date attempt to practise another and bring it up to the
proficiency of the first. The problems with the latter technique are
similar to that of switching to colour neutral.
Step method order may not be fixed. Methods designed for blindsolving
can have this attribute - because of the nature of the method, where
each algorithm (mostly) leaves the rest of the cube alone, the order
is less important and changing it can be trivial.
Solving Types
In this section, I will analyse the types of technique used to
complete a step. This can mean two different things (that have their
own categories) - the human approach to completing the step and what
type of state change has taken place during the step.
There are a few systems that humans use to accomplish steps. The most
apparent one being the algorithmic approach to something. Called "the
worst thing in speedcubing" by Gilles Roux, this system enumerates the
cases in a given step and lists solutions for each. The solver will
then learn a solution for each case so that when it appears in a solve
they can recognise and recall the solution from memory.
An algorithmic approach can be used in steps that are traditionally
seen as intuitive based, but this is not generally advised - it
usually entails using some basic tricks or rules to reach a state that
you have an algorithm for. This is seen to generally lead to longer
solutions, but that does not make it worse.
An intuitive approach to solving a case is arrived at by logic and
reasoning that has been generated by experimentation. I think the
ability to use intuition to generate solutions for something is
important - it demonstrates awareness of the effect caused by applying
moves which is an important trait in understanding the cube and
shortcuts available. In comparison to algorithmic approaches, a
solution for each case is discovered by the user using logic or trial
and error. Cases may be improved over time as the solver's ability to
intuit more efficient solutions improves.
Many steps can be approached in either an algorithmic or intuitive
way, but some may require either one of the other to be used.
Something of note is that after a while, whichever approach you take
appears to converge towards the other. That is to say that intuitive
approaches to cases begin to become second nature and are executed in
the same manner as algorithms, while the solver can gather an
understanding of how an algorithm works the more familiar he is with
it. In situations where either approach can be used, the labels
intuitive/algorithmic describe the learning process - as the end
result is essentially the same.
A learning system that doesn't quite fit into either category is a
rule based one. This consists of specific things to perform for one
of many cases. There will be different groups of cases that require
the same thing to be performed to advance to the next part - which
will either be another case from a category, or completion of the
step. Examples of this are the edge orientation step from the Roux
method, dual alg single step systems for LL (Petrus 270, OLLCP hax),
or some cubeshape systems for Square-1. I like to call these systems
'flowcharting systems' as the data can be expressed as a flowchart.
Another rule based system involves using a formula to generate move
sequences. The only examples I can think of that do this are
commutators and conjugates. This involves using a formula to create an
algorithm to perform a certain task. While intuition is required to
create the different parts of the formula, the structure of the
algorithm created is predefined. This appears to result in a system
that allows creation of predictable results that can be used
'on the fly' without premeditative learning.
As with other systems, these will eventually become algorithmic *and*
intuitive.
There are two different state changes that a step can accomplish.
Direct solving is the most prevalent and *has* to feature in a method
at some point for a cube to be solved. With this technique, pieces
dictated by the step are fully permuted and oriented. With respect to
a given reference. This does not have to be an external reference
point, and does neither have to be the same reference point as in
previous steps (pseudoblocks).
Quoting Quadrescence: "I think if you are directly solving, you have
an absolute reference point throughout the process". While this
contradicts what I am saying, I see it as a perfectly valid view on
what constitutes direct solving. This is a good example of the grey
area seen when describing these concepts, which I have had trouble
with when writing this article.
Reduction is not a requirement for a method, but can be a powerful way
to bring a cube closer to solved. When a step involves a reduction,
there is a subset of states that the cube is required to be in for
completion of the step. The step after will only deal with solving
those states, so removal of others facilitates completion of the step.
This also further reduces the number of states a cube can be in,
bringing it closer to solved. While this is also true for direct
solving, the required states do not require pieces to be permuted or
oriented correctly. Certain attributes can instead be enforced that
involve *only* permutation or orientation, or pieces to be grouped in
certain ways.
Some steps contain a mixture of both types, like direct solving some
pieces and reducing others.
Pseudo solving is an interesting quirk. This entails solving to a
state whereupon after normal conclusion of the method, extra moves
will be required to resolve the pseudo creation. So instead of solving
to a solved cube state, you are solving to the state of one (or more)
moves away and then adding those moves at the end. This can be
advantageous because pseudoblocks may be easier to create than the
normal blocks required.
A pseudo move can be applied over the course of a few steps and can be
used with either direct solving or reduction.
Method Feasibility
Unfortunately, most metrics for measuring method feasibility cannot be
quantified easily. Along with personal preference, this makes
comparing different systems a mostly subjective ordeal.
A major aspect of what constitutes a good method is the movecount.
While this is not the quintessential element in deciding how well a
method will perform, it is a purely quantifiable attribute that gives
a good indication. All major speedcubing methods in use have a similar
movecount, with ones giving a higher movecount providing advantages in
other areas.
Because of the human element to speedsolving, ease of use is another
key factor. Methods that are without complication tend to fare better
as they are more attractive to learn and receive more testing. While
more complicated methods may perform better in the long run,
demonstrating this fact proves difficult when no one desires to try.
Methods with complicated steps also require extra thinking time, which
should not be present when speedsolving. A disadvantage in many
methods with low movecounts is the thinking time required to execute
certain steps.
Another ease of use issue is the required learning overhead. This
usually means the quantity of algorithms required to be learnt in
order to fully utilise a method. Methods with less algorithms tend to
rely on using more steps and intuition, leaving a less efficient
overall solve, while methods with algorithms numbering into the
hundreds give a steep learning curve and difficult implementation.
After initial learning of a large algorithm set, this difficulty
results from the trouble caused by attempting to recall an algorithm
from such a large subset without thinking time. While recognition of a
case from a large subset is also an issue, it is not as significant as
recall. So far, no one has been able to show proficiency with an
algorithm set numbering in the hundreds matching that of lower sizes.
As for the algorithms themselves, subsets requiring algorithms do not
usually restrict to a certain movegroup - so users can find different
to suit their preferences as they please. However, more intuition
based steps tend to lend themselves to being executed with certain
movegroups. Steps with fingertrick friendly movegroups generally fare
better than others - but this aspect is largely affected by personal
preference.
Extensions & Variations
Each base method can have countless variations and extensions.
Usually, a step or group of steps can be accomplished with multiple
systems that are of seemingly near equal feasibility. There are almost
endless combinations of alternative approaches to things.
Forced step concatenation is a popular idea for extending a method.
This involves learning how to solve two steps at once, usually
resulting in a huge increase of things to learn. When creating a
method, this should be performed on each couple of steps to ensure
maximum efficiency is produced. However, this is not always humanly
feasible to do.
A similar idea is to solve only part of the next step instead. This
gives you a subset of cases for the next step. The intention would be
to make this subset of cases be nicer than the larger set is. It's
debatable if the time saved by having better cases is negated by
getting to that subset in the first place.
Another use for partial concatenation is to reduce the number of cases
enough so that full step concatenation can take place with the reduced
step and the step after that.
Alongside different variations, systems exist that only apply in
certain situations. While these systems provide advantages in these
situations, they are not useful for every cube configuration and are
not considered complete systems. While learning tricks for magical
special cases will usually be advantagous, implementing them in solves
can introduce recognition or recall issues. Tricks like these usually
entail forcing skips of some kind.
New Method Development
People creating methods solely for entertainment purposes can skip
this section (and indeed the entire thread).
Researching existing methods is extremely important to the development
of your own. Not only will this cause you not to regurgitate methods
that we have seen over and over again, it will give you ideas of your
own. You will be able to see what works and what does not work as you
can see what is popular and used to attain good results already.
Most techniques have remained largely unexplored due to the difficulty
of testing new ideas. Do not discount them simply because they are not
popular - there are good examples of systems with low usage going to
achieve better results than their popular counterparts. Bearing this
in mind however, you should learn to be able to judge if a system has
outright bad attributes that make it undesireable for use. Bearing
that in mind, consider that your judgement may be wrong
Alternatives to existing steps are a good place to start, as these
currently have the highest opportunity for producting completely
viable results. This doesn't give a very interesting outcome though as
the alternative will often be similar results wise as the existing
system, with less documentation and use.
These days it seems that most trivial and obvious full methods for
well known puzzles have been completely covered. Creating brand new
ideas or improving existing ones seems to have to rely on really
abstract concepts.
You should be aware that most of your ideas will not work or will be
unsuitable for speedsolving. Be prepared to let go of an idea if it is
bad - remaining objective is key.
TL;DR METHODS!!!!!!11
