#### trangium

##### Member

Movecount Coefficient Calculator

The Movecount Coefficient Calculator takes an algorithm or a list of algorithms and outputs the movecount coefficient of each algorithm. The lower the movecount coefficient, the faster the algorithm. This calculator doesn't take how risky an algorithm is into account, only its top potential speed. Currently, the Movecount Coefficient Calculator doesn't support rotations. Wide moves need to be written as a lowercase letter (so r is permitted, but Rw doesn't work). There are options to sort the algorithms by their movecount coefficient, ignore unknown moves and to disregard AUFs.

Note that if "Ignore Unknown Moves" is checked, you can copy and paste output from Cube Explorer into the movecount coefficient calculator to find the best algorithms, a big improvement from scrolling through Cube Explorer's output and manually testing each algorithm.

The main OLLs and PLLs often end up at the top of the rankings (i.e. they have the lowest movecount coefficient). If they don't, they're usually still near the top. For example, the standard T perm ends up 7th on the list, with the highest rated alg being R' U' R U R B' R2 U R U R' U' R B, which avoids the overwork in the standard T perm but is considerably riskier.

Update 11/29/2020: Added the U' with middle finger trick. For example, R U' R' U' no longer has an overwork. The standard T perm now is deemed better than the RUB one listed above, and I think it ranks 1st now (although I haven't tested it yet.)

This could be used to help optimize less-developed algsets like TTLL or 1LLL and aid in generating new algorithm sets for new methods. I have already used this program to help generate TDR algorithms for the Mehta-TDR method, and the algorithms turned out great!

Spoiler: How it works

Spoiler: How I got the numbers used in the calculator

The Movecount Coefficient Calculator takes an algorithm or a list of algorithms and outputs the movecount coefficient of each algorithm. The lower the movecount coefficient, the faster the algorithm. This calculator doesn't take how risky an algorithm is into account, only its top potential speed. Currently, the Movecount Coefficient Calculator doesn't support rotations. Wide moves need to be written as a lowercase letter (so r is permitted, but Rw doesn't work). There are options to sort the algorithms by their movecount coefficient, ignore unknown moves and to disregard AUFs.

Note that if "Ignore Unknown Moves" is checked, you can copy and paste output from Cube Explorer into the movecount coefficient calculator to find the best algorithms, a big improvement from scrolling through Cube Explorer's output and manually testing each algorithm.

The main OLLs and PLLs often end up at the top of the rankings (i.e. they have the lowest movecount coefficient). If they don't, they're usually still near the top. For example, the standard T perm ends up 7th on the list, with the highest rated alg being R' U' R U R B' R2 U R U R' U' R B, which avoids the overwork in the standard T perm but is considerably riskier.

Update 11/29/2020: Added the U' with middle finger trick. For example, R U' R' U' no longer has an overwork. The standard T perm now is deemed better than the RUB one listed above, and I think it ranks 1st now (although I haven't tested it yet.)

This could be used to help optimize less-developed algsets like TTLL or 1LLL and aid in generating new algorithm sets for new methods. I have already used this program to help generate TDR algorithms for the Mehta-TDR method, and the algorithms turned out great!

Without taking regrips, overworks, simultaneous moves, or "ghost sequences" into account, the formula is (the number of moves)+0.65*(the number of half turns). It is based on Jperm's algometer, as well as some testing to fill in the gaps in his algometer.

Each regrip adds 2-(how long that hand has not been used for). So a hard regrip would add 2 to the result, a soft regrip with only one quarter turn of time to regrip would generally add 1 to the result, a soft regrip with only one half turn of time to regrip would generally add (2-1.65)=0.35 to the result, and a soft regrip with two or more turns of time to regrip generally wouldn't add any moves to the result. However, regrips at the start of an algorithm only add 0.35 to the result because you'll usually be able to do AUF or have to finish recognizing the case while regripping.

Most overworks add 2.25-(how long that finger has not been used for). For example, there is an overwork in M' U' M' because you only have the time it takes to do U' to reset your middle finger to do another M'. The U' would take 1 unit of time, so the overwork adds (2.25-1)=1.25 moves to the result. With some overworks, that number is different than 2.25 since it takes more time to reset your finger. There are also more subtle overworks. For example, if your right thumb is not on the front, U2 D2 contains a hidden overwork, because U2 requires using your middle finger, but D2 needs your middle finger gripping the cube, so the time it takes for your middle finger to reset needs to be accounted for.

U and D moves next to each other can be done simultaneously. However, in practice, the time it takes to do two simultaneous moves is usually slightly slower than the slower of the two moves, so a penalty of 0.5 is added. So a U D would add 1.5 to the total (still better than the usual 2 or more for any two non-simultaneous moves.)

There are four "Ghost sequences": R' U R', R U' R, R D' R, and R' D R'. These four sequences are almost as fast as an R2, since the central move corner cuts with both R moves and consequently takes very little time. The first two ghost sequences take off 0.5 from the total, and the last two take off 0.3, provided that there are no regrips within the sequence.

Every time you shift from R moves to L moves, you have to perform a grip shift. This also applies for switching from R moves to r moves, or in general switching from wither (R, l) to (r, L). Each grip shift adds 1 to the total.

There are a few exceptions to the procedure, which I have added through testing. One notable exception is that S, S', E, and E' add (at least) 1.25 to the total, and S2 and E2 add at least 2.05 to the total. Other exceptions involve certain ways to fingertrick a move taking longer than usual.

The Movecount Coefficient Calculator internally comes up with fingertricks for each algorithm to evaluate it. It tries to minimize mid-alg regrips, so it always goes with the fingertricks that go the most moves without regripping. It usually finds the fastest fingertricks, but not always.

Each regrip adds 2-(how long that hand has not been used for). So a hard regrip would add 2 to the result, a soft regrip with only one quarter turn of time to regrip would generally add 1 to the result, a soft regrip with only one half turn of time to regrip would generally add (2-1.65)=0.35 to the result, and a soft regrip with two or more turns of time to regrip generally wouldn't add any moves to the result. However, regrips at the start of an algorithm only add 0.35 to the result because you'll usually be able to do AUF or have to finish recognizing the case while regripping.

Most overworks add 2.25-(how long that finger has not been used for). For example, there is an overwork in M' U' M' because you only have the time it takes to do U' to reset your middle finger to do another M'. The U' would take 1 unit of time, so the overwork adds (2.25-1)=1.25 moves to the result. With some overworks, that number is different than 2.25 since it takes more time to reset your finger. There are also more subtle overworks. For example, if your right thumb is not on the front, U2 D2 contains a hidden overwork, because U2 requires using your middle finger, but D2 needs your middle finger gripping the cube, so the time it takes for your middle finger to reset needs to be accounted for.

U and D moves next to each other can be done simultaneously. However, in practice, the time it takes to do two simultaneous moves is usually slightly slower than the slower of the two moves, so a penalty of 0.5 is added. So a U D would add 1.5 to the total (still better than the usual 2 or more for any two non-simultaneous moves.)

There are four "Ghost sequences": R' U R', R U' R, R D' R, and R' D R'. These four sequences are almost as fast as an R2, since the central move corner cuts with both R moves and consequently takes very little time. The first two ghost sequences take off 0.5 from the total, and the last two take off 0.3, provided that there are no regrips within the sequence.

Every time you shift from R moves to L moves, you have to perform a grip shift. This also applies for switching from R moves to r moves, or in general switching from wither (R, l) to (r, L). Each grip shift adds 1 to the total.

There are a few exceptions to the procedure, which I have added through testing. One notable exception is that S, S', E, and E' add (at least) 1.25 to the total, and S2 and E2 add at least 2.05 to the total. Other exceptions involve certain ways to fingertrick a move taking longer than usual.

The Movecount Coefficient Calculator internally comes up with fingertricks for each algorithm to evaluate it. It tries to minimize mid-alg regrips, so it always goes with the fingertricks that go the most moves without regripping. It usually finds the fastest fingertricks, but not always.

For most of the parameters, I timed two sequences differing in only that attribute and did some math to logically and mathematically figure out the coefficients. For example, to find out the value of a grip shift, I timed (R U R' U')6 versus (R U r' U')6. For a few parameters where this was not possible, I made an educated guess based on how it fit Jperm's PLL times and Cubehead's PLL times.

Last edited: Dec 6, 2020