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

[trangium]

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.)

Update 6/2/2021: Added rotations and risk parameters which brings even more of the standard algs closer to the top. For example, the standard Jb perm used to rank around 20th but now it's tied for first.

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

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.

Spoiler: How I got the numbers used in the calculator

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.

 

[qwr]

(the number of moves)+0.65*(the number of half turns).

so my 1.5 half turn metric wasn't so unreasonable after all

 

[SpeedCMOS]

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.

 

[trangium]

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]

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)).

 

[abunickabhi]

Interesting tool trangium. I will check it out.
Definitely seems useful.

 

[Cubing Forever]

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

 

[trangium]

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.

 

[Cubing Forever]

The movecount coefficient calculator currently doesn't support rotations. So, if you have "ignore unknown moves" checked, it just skips over the rotation.

I wrote the alg as R2 u R' U R' U R U' R2 u' F' U F still it showed a lower score than R2 U R' U R' U' R U' R2 U' D R' U R D'

 

[SoundBalloon]

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]

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]

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.

 

[Pyjam]

Is it broken? Nothing happens when I click on Calculate.

 

[trangium]

I have released major updates to the MCC:

1. Risk parameters: These can be changed by checking "show advanced options". There are ten risk parameters which are described below.

- Wrist Turn Multiplier: Makes R and L turns, the least risky turns, count as slightly less than 1 move. Default: 0.8
- Push Turn Multiplier: Makes push turns, which are more risky than flicks or wrist turns, count as slightly more than 1 move. Default: 1.3
- Ring Turn Multiplier: Makes ring turns, which are more risky than flicks or wrist turns, count as slightly more than 1 move. This includes D turns, some F or B turns if they are executed with ring (like in R F' R'), but not M moves. Default: 1.4
- Destabilize Penalty: Any turn made on the same face as where 4 fingers are holding the cube, like the U' in R' U' R or then B2 in R B2 R', destabilizes the grip slightly, increasing risk. Default: 0.5
- Soft Regrip Penalty: Soft regrips increase risk, so the soft regrip penalty adds to the value in addition to the normal regrip penalty of 2 minus how long that hand has not been used for. So, if this value is nonzero, any regrip, even soft regrips, will add to the MCC. Default: 1
- Half Turn Multiplier: Controls how much a half turn counts as. Default: 1.65
- S/E Slice Multiplier: Makes S and E slices, which are riskier than face turns or M slices, count as slightly more than 1 move. Default: 1.25
- Overwork Penalty: Most overworks add (Overwork Penalty)-(how long that finger has not been used for). Default: 2.25
- Move Block Penalty: This is a new feature in the MCC. To illustrate, do R D F starting from home grip. You will find that it is nearly impossible to do the F quickly as a ring push. Why? Because it is blocked by the preceding D. An F with a ring push requires a ring finger on RDF, which moves when the D is performed, making it impossible to pre-set the ring finger up for an F. Therefore, this essentially requires the same time as a regrip. Some move blocks are not as bad though, such as R B U starting from home grip with a left index push for U. So, I made 3 categories of move blocks. The worst category includes situations such as the aforementioned R D F, and these count as a hard regrip. The second category includes situations such as R B' U starting from home grip, and they incur the move block penalty. The final and least bad category includes situations such as the aforementioned R B U, and they incur half the move block penalty (this is also the most common category). Default: 0.8
- y/z Rotation: Controls how many moves a y/z rotation counts as. x rotations are special because they count as regrips. Default: 3.5

All multipliers stack, so for example, a ring push would count as (ring turn multiplier) * (push turn multiplier). Another example is a y2 counts as (y/z rotation) * (half turn multiplier).

If all these setting seem too complicated for you, you can just ignore the "show advanced options" box and use the movecount coefficient calculator normally. This will just use the default risk parameters.

2. Rotations: y and z rotations will just add a certain amount to the MCC: 3.5 by default. x rotations count as regrips if they are even necessary. Multiple simultaneous rotations like x y might not be counted accurately because they are considered 2 separate rotations rather than 1 continuous motion.

3. Made F move fingertricks symmetrical across both hands: Originally, some fingertricks were only supported on one hand, but not on the other. This has now been fixed.

4. Miscellaneous tweaks and fixes: If you really want to know every minor change I have made, go to my github repository.

With the default risk settings, the top-ranking algs for most PLLs are standard algs, which is a big improvement over how it was before.

There may be bugs, so if nothing happens when you click on Calculate, let me know what alg caused the error, any error messages in the console (F12), and what browser you used (I only tested this in Chrome).

 

[StrategySam]

I've been using the movecount calculator for a while. Since I don't like S and E moves as much as they are risky I put S and E moves are more then 1.25.

 

[Megaminx lover]

Can x rotations and regrips be seperated?

 

[trangium]

Can x rotations and regrips be seperated?

No, because x rotations are just regrips written in a different way.

 

[LBr]

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.)

Update 6/2/2021: Added rotations and risk parameters which brings even more of the standard algs closer to the top. For example, the standard Jb perm used to rank around 20th but now it's tied for first.

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

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.

Spoiler: How I got the numbers used in the calculator

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.

Could you please factor in Wide moves and simultaneous moves? as it does not recognise them and its a bit annoying. If you could fix this your website would be so good

 

[Megaminx lover]

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.)

Update 6/2/2021: Added rotations and risk parameters which brings even more of the standard algs closer to the top. For example, the standard Jb perm used to rank around 20th but now it's tied for first.

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

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.

Spoiler: How I got the numbers used in the calculator

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.

This is one of my favourite cubing websites of all time! However most of the best PLLs by the algometer aren't really standard

 

[Flummox]

Can I see the code for how this is calculated? I’m trying to write a solver that makes use of this.