• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 35,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Movecount Coefficient Calculator: Online Tool To Evaluate The Speed Of 3x3 Algorithms

trangium

Member
Joined
Jul 24, 2019
Messages
64
WCA
2019TRAN10
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!

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.

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:

SpeedCMOS

Member
Joined
Feb 6, 2020
Messages
5
This will need a bit more tuning before it can be used to find the best algs reliably.

For example, consider
(1) 6.5: F R U' R U R2(')
(2) 6.25: R' F R F' U R

The first alg is not worse than the second, I would even say it's faster. The last U R of the second one is really bad to execute, and while not really requiring a regrip you need to change your hand position a bit. Generally sequences with R moves and alternatinv U and U' without regrips are often very fast, just like in the first algorithm. I timed both and was able to execute the first one .12 faster, which is a lot for such short algorithms. [Edit: I was wrong here]

(3) R2 U' R U R2 U' R U' R is evaluated as 12.75, even though it has 9 HTM and 11 QTM and is regripless and overworkless. Not the easiest fingertricks as you have to do the last two U' as a double flick U2', but very possible and risk isn't a factor here.

The execution speed is not linear to the score you give. I can execute the third example of this post in .48 and the second in .41, but the rating difference is about a factor 2. If they would solve the same case (they're just random moves I made up to test) I would probably even choose the third one for speedsolving. I think this can be partially solved by giving the moves a little less weight.
 
Last edited:

trangium

Member
Joined
Jul 24, 2019
Messages
64
WCA
2019TRAN10
This will need a bit more tuning before it can be used to find the best algs reliably.

For example, consider
(1) 6.5: F R U' R U R2(')
(2) 6.25: R' F R F' U R

The first alg is not worse than the second, I would even say it's faster. The last U R of the second one is really bad to execute, and while not really requiring a regrip you need to change your hand position a bit. Generally sequences with R moves and alternatinv U and U' without regrips are often very fast, just like in the first algorithm. I timed both and was able to execute the first one .12 faster, which is a lot for such short algorithms.

(3) R2 U' R U R2 U' R U' R is evaluated as 12.75, even though it has 9 HTM and 11 QTM and is regripless and overworkless. Not the easiest fingertricks as you have to do the last two U' as a double flick U2', but very possible and risk isn't a factor here.

The execution speed is not linear to the score you give. I can execute the third example of this post in .48 and the second in .41, but the rating difference is about a factor 2. If they would solve the same case (they're just random moves I made up to test) I would probably even choose the third one for speedsolving. I think this can be partially solved by giving the moves a little less weight.
My best times for these algorithms, excluding initial regrips;
F R U' R U R2: 0.30
R' F R F' U R: 0.39
R2 U' R U R2 U' R U' R: 0.57

1. The F' in the second alg can be done with your left index, putting your left pinky under the S slice to keep it from moving. This prevents the U R being really bad to execute. Note that I'm not used to that finger trick, which is reflected in my slower time for that algorithm.
2. Algorithms (1) and (3) require a regrip to start, while (2) does not. 3/4 of the time, this doesn't matter because you can pre-AUF while regripping, but 1/4 of the time the regrip costs time. So, I assigned a 0.35-point penalty for starting regrips. I don't know if you took the starting regrips into account, but I know that the movecount coefficient calculator did.
3. The movecount coefficient calculator doesn't account for the U' with middle finger trick yet. I might add that in future iterations.
4. This brings up an interesting point: I mainly optimized the movecount coefficient calculator for my own times, so other people might disagree with the weights I placed on certain parameters. This could be remedied by asking a large sample of top cubers to do certain algorithms, and using that data to adjust the weights used in the movecount coefficient calculator.
5. Nonetheless, I agree that this will need a bit more tuning before it can be used to find the best algs reliably, However, this is still a massive improvement over scrolling through Cube Explorer algorithm outputs, which sort by STM.
 

SpeedCMOS

Member
Joined
Feb 6, 2020
Messages
5
I didn't think about that F' fingertrick, using that makes (1) and (2) about the same speed, with (2) slightly slower but without start regrip. Makes sense, I was wrong there. As finding finger and regrip combinations is much easier for a program than for a human, is it possible to print how to fingertrick the cases next to them? That way it's much easier to understand the rating and profit from what the program found.

Double and triple flicks will change the rating significantly in some cases, the difference can be as large as a regrip + slightly more than 1 move (as U' R U' is almost as fast as U2' and could be treated as a ghost sequence), so that would improve your program a lot.

Everyone has different turning, so some of the weights might not be a universal constant. A solution could be to make a person using the program execute a few algorithms, enter their times and calculating the values from it. That way fingertricks you're not good at will get a larger cost and the algorithms will fit your turning better. Hardcoding this for your own turning might not give the objectively best algorithms the program could come up with.
The problem in using the weights on the execution of many people is that perfectly usable but unconventional fingertricks will get larger weights than necessary, as many cubers aren't as fast with them as they could be with practise (just like your F' in (2)).
 

trangium

Member
Joined
Jul 24, 2019
Messages
64
WCA
2019TRAN10
Why does it show the old school G Perms with rotations more effiecient than the RUD ones. They're definitely slower than the RUD ones lol
The movecount coefficient calculator currently doesn't support rotations. So, if you have "ignore unknown moves" checked, it just skips over the rotation.
EDIT: Writing it without the rotation does show the old school G perms as more efficient. This shows that the movecount coefficient calculator still needs some work.
 
Last edited:

SoundBalloon

Member
Joined
Apr 21, 2018
Messages
15
Location
France
WCA
2016LEHE01
That is great! I assume you used JPerm's Algometer formula? It looks extremely close but you never mention it.

I had a similar project in the works for the last two years, with a different approach -- more centered on regrips and fingertricks. Used it for 3-style alg generation. Worked fine for face turns, but it took dust when I had to include slice moves. I'll try to dust things off and perhaps share it too. Hopefully with more similar yet different tools to improve the estimation of alg's quality, the dream of automating alg search will come true!

Say, in what language is the online tool coded?
 

trangium

Member
Joined
Jul 24, 2019
Messages
64
WCA
2019TRAN10
That is great! I assume you used JPerm's Algometer formula? It looks extremely close but you never mention it.

I had a similar project in the works for the last two years, with a different approach -- more centered on regrips and fingertricks. Used it for 3-style alg generation. Worked fine for face turns, but it took dust when I had to include slice moves. I'll try to dust things off and perhaps share it too. Hopefully with more similar yet different tools to improve the estimation of alg's quality, the dream of automating alg search will come true!

Say, in what language is the online tool coded?
Yes, it's based off Jperm's algometer, as well as some testing to fill in the gaps in his algometer. It's written in JavaScript.
I'm also making an algorithm searcher (it's also on my website) that has the movecount coefficient calculator integrated. I would say that the movecount coefficient calculator is mainly centered on fingertricks, since it internally figures out the fingertricks for each alg and gets its result based on those fingertricks. I've already used this to automate Mehta-TDR algorithms. As I improve this, automating alg search will become more and more viable.
 

efattah

Member
Joined
Feb 14, 2016
Messages
592
Thank you for making this. I have been asking the community for something like this for years. I ran some of the LMCF algorithms through it, and indeed it did sort them approximately in correct ranking based on how long they take to execute. It isn't perfect but tremendously useful when doing new method development. Thanks again.
I was particularly impressed that one of my algs with the strangest fingertricks was correctly placed in the lowest scoring section (M2 U' l' L' D M D' L2 U). This is impressive.
 
Top