# Hand simulator for algorithm rating



## SoundBalloon (Dec 3, 2020)

*Call for volunteers: I am looking for data on execution times of algorithms.*

As you will read below, I am trying to design a data-driven algorithm speed estimator. For this, I need data!
More precisely, I need a list (algorithm, execution time), satisfying the following critera:


Spoiler: It's not much I swear.



- You should be averaging sub-20.
- What algorithm you include is up to you. However, you should know each of them, or have drilled them enough that you are approching your top execution speed on it.
- Any timing material (stackmat, online timer, or even phone...) is fine, *as long as you use exactly the same for every algorithm and try to minimize variations between solves.*
- Please at least 50 algs. 100 or more is even better. If you know full ZBLL and are willing to time yourself and send me the times, you are the best.
- Any format is good, provided it clearly links the algorithm and the time. I suggest a spreadsheet (or .csv file).
- Also, if you use a fancy / unusual fingertrick (meaning, one not listed in the next post), then let me know!





Spoiler: Here is how I suggest you time your alg.



1- Warm up. For example, execute the alg between 5 and 20 times.
2- Do three timed series. In each series, execute the algorithm three times in a row, as fast as you can and without pauses.
3- The end time is the best time of the three series.
You are free to change the number of series or the number of repetition in each series. I strongly suggest to keep at least 3 algs per series (more if your timer isn't precise). However, once you start with a given timing method please *stick to it throughout the data collection.*



Okay, let's start!

*I want to design a program that automatically rates an algorithm depending on its execution speed.*

The end goal is to automate, or drastically accelerate, alg generation for new methods and alg sets.

The software studies how one executes an algorithm, as a sequence of fingertricks. Each fingertrick costs some time: how much is estimated using linear regression. The model is highly modular, and uses a variable, and customizable, number of parameters: a simplified version will be fast, a more developped version will be more precise.




Spoiler: State of the art



That goal is not new. Here are the other attempts to address it that I am aware of (after browsing the software section of Speedsolving), and my opinion on what they do well, and what is improvable.

I will make no comment on the reliability of the different methods, as I hope to evaluate them soon.



Spoiler: Use a smaller moveset



Limit the alg to <R,U,F>, <R,U,D>, <M,U>, or any other "nice" subset of moves.

PROS
Braindead simple: no coding required!
When using a software like CubeExplorer, you can generate longer algorithms

CONS
The best algorithm is always outside of the set you chose. You just know it.





Spoiler: Identify triggers. More triggers, better alg



Leibniz' AlgSort (July 16, 2016): https://www.speedsolving.com/thread...od-algorithms-and-removes-rubbish-algs.61730/ . Identifies triggers in the algorithm. The less moves are outside of a trigger, the better the alg.

PROS
Simple
Extremely fast
Can possibly give good results as a first pass

CONS
Some would say simplistic





Spoiler: Myopically look, step by step, if the alg flows well



Teoidus's AlgExplorer (June 5, 2017): https://www.speedsolving.com/thread...ine-utility-to-assist-in-alg-searching.65189/ . Evaluates the algorithm by whether it "flows" like a speedsolving algorithm. Trained on ~4k alg set.

PROS
Conceptually elegant, thus probably easy to code (if you are good at math)

CONS
The quality of the estimation strongly relies on what you feed it. If you give it algs with lots of slice turns, it will like algs with lots of slice turns.
The end score tells how "speedsolve-friendly" the algorithm is, not how fast it is.





Spoiler: Derive a simple formula from linear regression: JPerm's Algometer



JPerm's "Algometer" (march 24, 2020) and improvements by other people. This formula approximates an algorithm's execution time, given how you execute it.

PROS
Elegant
Simple
Quick to calculate
Derived from statistical estimation (more precisely linear regression): ensures a lack of bias and good reliability (for a given dataset)

CONS
You need to know how you execute the algorithm: impossible to use for automated alg search
Poor robustness. The dataset is made of a small number of algorithms that look alike. As JPerm observed, changing a parameter from 1.5 to 2.5 basically changes nothing to the quality of the formula.





Spoiler: Use the previous formula with a heuristic to generate one possible execution



trangium's Movecount Coefficient Calculator (Nov 26, 2020): https://www.speedsolving.com/thread...o-evaluate-the-speed-of-3x3-algorithms.79025/
Given an algorithm, this online tool first guesses a not-too-bad execution of the alg, then evaluates it using a homemade variant of JPerm's Algometer.

PROS
Works with raw algs: compatible with automated alg search
Prooftested: The software creator used it to generate algs for Mehta's method
Practical: sleek online tool
Very quick: can handle a large number of algs and you don't have to wait for the result

CONS
The alg execution the software uses is not always the best (it often is, so this isn't a big problem)
Does not handle rotations
Some arbitrary coefficient choices, done "by hand" instead of using a statistical estimation method (one of the Algometer's strong points). (The issue is theoretical, it still gives good result.)
The calculation procedure could be clarified. (If you just want to use the software, ignore this point.)

(Also, shoutout for trangium, who has extended his MCC to a full-blown alg generator *à la* CubeExplorer! Does not handle partial cubes apparently (yet?), but it's great nevertheless.)





Spoiler: "Gripper"












Gripper: Rubik's Cube Algorithm Analyzer


For the past few days I have been working on a program that would analyze algorithms and output an expected time of execution. This idea is of course by no means unique, but as far as I am aware, even though there have been some attempts at this, noone has actually made or published anyhting...




www.speedsolving.com




Apparently close in spirit to what I want to do here, minus the stats and with less fingertricks included. Also mentions a similar (though less advanced?) software that I have been unable to find.

PROS:
Simpler version, so very likely faster

CONS:
Not available anymore
Takes less fingertricks into account
Arbitrary choices instead of learning from reality
The author commented that some algs it outputs were overrated. But that's a common point of each of these softwares, so no big deal.





> "Okay SoundBalloon, there are great alg rating methods already, why do you want to do another one yourself?"



Well first, because although they are great, they are not perfect, and I have ideas to address their weaknesses. Second, because estimating alg quality is crucial for the future of cubing, and I think contributing there is worthwhile. Third, because having two ways (or even four and a half ways) to do a thing doesn't mean a third is irrelevant -- Roux came after CFOP and Petrus, yet no one would say it was useless to suggest it. In fact, you will be able to cross-reference several alg estimators to get even better algs!


So without further ado, here is my suggestion.




PHILOSOPHY

There are a few principles that will guide the design of the program.

- Transparency. No secret tricks. You are free to use ideas presented in this thread (but give credit where credit is due). The more people understand what it does, the more people can improve it.
- Reliance on data. I will minimize choices that are "arbitrary" or made "by hand". While we will have to decide on a model, the parameters of the model will be estimated from raw data. The data gathering and processing will be carefully designed to improve the quality of the estimation.
- Quality testing. The algorithm will be rigorously tested on data that is independent from the data used to estimate the parameter.
- Usability. The algorithm should be usable, meaning fast. If it is too complex, it should be simplified.


Since every parameter is estimated, we could end up designing a way to calibrate the algorithm specifically for YOU, so you can find what alg is best for YOU.

The reliance on data also means that the model is bound to evolve. If an alternative model is suggested, I will test (as objectively as I can) whether it gives better result, or similar results for a reduced complexity, and if yes switch to it.


HAND MODEL (complete version)

The core of the software is a simplified hand model, that includes the most used fingertricks.


GRIP

The way you hold the cube is called the grip. The current grip determines what fingertricks, and thus what movements you can do.

Fingertricks come in many sorts. For now, let's take the very abstract definition that it is an action that you do on the cube, that causes its state, its position, and/or your grip on it, to change in one way or another. They usually involve one finger (U, F...), two fingers (U2, M2'), one whole hand (regripping the left hand, flicky R2...), or the two hands (x, y...). Key examples are face moves and regrips. (Pops are another, but I will not include them, unless you plan to reliably include a pop in your alg execution )


Spoiler: More details on how the grip is modelled.



Let us observe how cubers grip the cube. Take your cube, start a solve, then stop anywhere, in any mid-alg position. Let go of one hand. Normally the cube should stick to your remaining hand. Then you may notice that you can let go of all your non-thumb fingers but one, and end up holding the cube with only two fingers: the thumb, and another one (usually, either the index, middle, or ring finger). I call this finger "opposite finger".
Each hand holds the cube like a pincer, between thumb and opposite finger. These two fingers are always on the same slice, otherwise you would accidentally turn a face at the slightest disturbance. In fact, the position of the opposite finger is entirely determined by the position of the thumb. (It might even look eerily symmetric!)

 

Furthermore, the two hands aren't placed in any random position: both palms face opposite faces. (R and L usually, but if you are doing FM they might face B/F or U/D. Watch out!)

To sum up, here are the parameters that determine the grip in our simplified model:
- the orientation of the cube (what is the front face and the top face -- changed through x,y,z moves, requires regripping two hands most of the time.)
- the relative orientation of the left and right hand (changed through R or L moves)
- which finger of each hand is the opposite finger (changing this requires regripping one hand.)
- the position of the left, respectively right thumb on the cube. (changing this requires regripping one hand.)



There is one thing missing from our model, that we cannot see in "static" grips: overworks.


COOLDOWN AND OVERWORKS

An overwork happens when you use a finger, and have to use it again immediately. It results in a delay in the alg execution.

Modelling overworks is tricky. I plan to model it using cooldowns. The idea is the following: after using a finger during a trick, said finger becomes unavailable for any further trick for a given time ("cooldown"). This cooldown depends on the trick.


Spoiler: Extra note on the model



Here is the first significant approximation that my model make. Some tricks actually facilitate others. For example, it should be faster to do U S' (pushing the S layer with the index finger) than S' U, because the U moves brings the index into position. Similarly, U' U (both performed with the left index) is actually quite fast, because you do not have to reset the index finger between both moves.

My philosophy is that the errors that this simplification causes are rather minor, show up rarely, and will in any case be drowned out by the other errors (mainly in the estimation of the parameters), so it does not matter if we are forgetting a specific trigger. Ultimately, we do not want the perfect alg speed estimation -- we want an approximation.




HOW IS THE SCORE COMPUTED?

Let us assume that we have an algorithm, translated into a sequence of grips and fingertricks (note that, since regrips are themselves "fingertricks", it is enough to know the starting grip and the sequence of fingertricks). How do we compute a numerical value giving the quality of the algorithm, and hopefully correctly approximating the time we need to execute it? Let us call this value: the algorithm's score.


Spoiler: On the subject on ghost moves



Here comes the second significant approximation: I do not take ghost moves into account.

Why?

Let me answer with a question of my own: why should every move be the same "length"?
This is an implicit assumption in JPerm's video (and in CubeHead's sequel). They only account for double moves taking a-bit-longer-but-not-twice-as-long. But why should a D be the same length as a U? Or a right thumby F the same length as a R?

Given this, because the moves that show up into ghost moves are usually among the fastest one can execute, I believe that the gain in accuracy from counting "ghost moves", when taking into account the **real time** spent on this trigger, is not as large as it is made out to be. But of course, this will be put to test! (Also, a good algorithm is basically a sequence of chained "ghost moves", where I mean "fast triggers".)

On the other hand, every trigger excluding ghost moves correspond to exactly ONE face turn or one regrip. Adding ghost moves forces us to consider sequences of face turns as "elementary brick" of the algorithm instead of face turns (as usual). While this might not be a big problem, I do find that it adds unnecessary complications to an already daunting-looking task. (But perhaps I'm just lazy.)

If you really love those ghost moves, fear not -- adding them to the list of elementary moves is still possible (though a bit artificial), so we will ultimately be able to check, using real data, whether including them in the modelisation is worth it. If it is, I will use them. For now, let's keep things simple.



So, with ghost moves out of the way, how is the alg score computed?

Beware! We do not compute the score of an algorithm -- we compute the score of an EXECUTION of said algorithm (where the execution is the sequence of fingertricks and grips). The execution with the lowest (and thus, best) score wins.


Spoiler: A note on trangium's MCC



This is a possible (likely minor) improvement in quality over trangium's software -- but it comes with a (possibly severe) computational cost. Perhaps using good heuristics, like trangium but possibly different ones, would be a way to speed up the final algorithm significantly.



Each fingertrick has an elementary score (estimated from real data), which is a positive number. Without cooldown, the score of the execution would simply be the sum of the elementary scores of every fingertrick that appears in the execution. But we do need to take cooldown into account. Here is how.

You have a global clock, and each finger has a timer that starts at zero and can only have nonnegative times. You can only do a fingertrick when the timer of its finger is at zero. When you do a fingertrick with this finger, the timer is set to whatever the cooldown for this fingertrick is. You will then be unable to use this finger for the duration of the cooldown.

Also, the fingertrick takes some time, so when you start the next fingertrick, the global clock has increased by the fingertrick's score, and the timer of every finger (including the one you just used) decreased by the same amount. Now check if you can do the next fingertrick, that is, if the timer of the finger you want to use is zero. If it is, you can directly do the fingertrick! Otherwise, you have to wait until the timer reaches zero (in other words, you wait for the amount of time remaining in the cooldown timer).

The time displayed on the global clock when you finish executing the last fingertrick is the global score of the algorithm.




Spoiler: A word on estimating elementary scores






> But SoundBalloon, you said JPerm was doing statistics wrong by using only 20 algs to estimate 5 parameters. Now you want to estimate 50 parameters?! I don't want to drill 1000 algorithms!



Ah, how observant of you. You are, of course, correct! More parameters to estimate means we need more data to get the same precision in our estimation.

However, there are ways to simplify the problem (just like JPerm discarded two of the variables he considered initially). Some are arbitrary, and thus should be avoided, but I might end up doing them nonetheless; for example saying "these two fingertricks have the same elementary score". This way, we have less parameters to estimate.

Another way is more hopeful: it is to take a better dataset. PLLs are very similar-looking algorithms. So if you take a more varied set of algorithms, you will get more contrast, which can help estimating elementary scores.

Then, assuming we are reduced to 50 parameters, if we use 200 algs we get about the same ratio alg/parameter as JPerm (so hopefully, a similar quality). ZBLL is 500 algs, so it is possible we might actually get a better quality than JPerm's Algometer. Again, only experiments will tell.

And finally, even if the estimation is not that good, the software might still be usable. The software won't be perfect, but it might still be pretty precise -- just like JPerm's algometer is good despite being rough around the edges. And you can always feed it more data if you find an alg that it values completely wrongly!




CONCLUDING WORDS

Since this post is already long, I pushed all the detailed specifications into a separate post below.

The next post includes:
- the description of the grip,
- the list of currently considered fingertricks, and in which grip they are possible. I provided algs where the fingertrick is used for around half of them.

I do not provide any "elementary score" for the algorithm, since by my philosophy they will have to be estimated from timed executions. I plan on designing a set of "calibration" algorithms, from which we could draw a first estimate for the score of every fingertrick. Any simplifying hypothesis can be put there, and should ultimately be tested.


Spoiler: Example of simplifying hypotheses



For example, I shall assume that the speed of a fingertrick performed with one hand does not depend on the position of the other hand.

I do NOT, however, assume that the same fingertrick, performed from the right and from the left hand, takes the same time (my righty D2 is horrible ).





Spoiler: Grip description



Relative orientation of left and right hand

The home grip is when both thumbs are on the F face. If you do a R move, you are in the R grip; a R2 move and you are in the R2 grip. Similarly, do a R' move and you are in the R' grip, a R2' and you are in the R2' grip.

Below, pictures of the grips, from R2 to R2' from left to right.
    
We will need to check the feasability of every fingertrick in the R2 and R2' grips.


Note on the symmetry of both hands

The fingertricks of both hands are identical, even though their effect is symmetrized (L becomes R', U becomes U').

Also, the effect of the fingertrick needs to be altered depending on the relative orientation of the left and right hand. For example, in the R grip, U by the right hand becomes B, D' becomes F', while R remains R. *By convention, the left hand always remains "static". L moves are thus replaced by r moves.*


UED position (y position)

The grip of each hand is characterized by two "coordinates". The first is the U/E/D orientation.

grip on U : prevents U moves, but allows E, D and d moves.
grip on D : prevents D moves, but allows U, u, and E moves.
grip on E : prevents E moves, but allows U and D moves.

Below, grips on U, E, and D from left to right.
  

Note that the actual moves allowed or prevented are altered by the relative orientation of the hands. Say for example that the right hand has a grip on U, while the left hand has a grip on D.
- If we are in home grip, only E moves are allowed. F,f, S moves (but not B and b moves, unless you show me a fingertrick to do that...), are allowed. Whether M moves are allowed depends on the L/M/R position described below.
- If we are in the R grip though, in addition to the previously allowed move, U and u moves are allowed too. B and b remain impossible.


LMR position (x position)

There are three positions:
- left hand grips L, right hand grips M and R ("L position"),
- left hand grips L, right hand grips R, M is free ("M position"),
- left hand grips L and M, right hand grips R ("R position").

Below, from left to right, L position, M position, and R position. (The placement of the thumb might often be less pronounced than this.)
  

In L position, only r* moves are possible.
In R position, only R* moves are possible.
The M position is the only one where M* moves are possible. Since R moves have a chance to take the M slice with them, while R' moves can be blocked by the ring finger (the index finger is assumed taken by U moves), my take is to allow R' and R2' moves while forbidding R and R2 moves. Similarly, r and r2 moves are allowed but r' and r2' are forbidden.


Opposite finger

Finally, we need to specify for each hand whether the opposite finger (the finger that, together with the thumb, holds the cube) is the index, middle, or ring finger. (If anyone seriously uses their pinkie to grip the cube, post a video of the fingertrick please).

Below, from left to right, the opposite finger is the index, middle, and ring finger.
  


This entirely specifies the grip. There are 1215 possible grips in total.






Spoiler: Fingertricks list



Below is my list of fingertricks, sorted by the finger used to execute it. I also provide an alg where I use this fingertrick.
Let me know if one isn't clear.

I only describe fingertricks from the left hand: the effect from the right hand in home grip is symmetric, though we need to take the relative orientation of both hands into account.

Note that I list all moves that might be doable in some grip. That a grip prevents it from being done (especially a grip from the other hand) should be checked separately.

Reminder: the "opposite finger" of a hand is the finger that, together with the thumb of the same hand, holds the cube.

INDEX FINGER (when the index finger is not the opposite finger)
Any grip:
M _( (M D2)4 )_
when in grip E or D:
U' _(M' U' M U)_
U _ (first U of the T-perm; R' U R' U; sune)_
U2 *(ONLY if you use that fancy U2 fingertrick that does NOT use the middle finger -- forgot the name)*
F' _(?)_
F _(?)_
f' _(?)_
f _(?)_
S' _(S' R U R' S R U' R' -- btw I do the S with the right middle finger)_
S _(?)_
when in grip D:
u' _(u' M u2 M u')_
u_ (?)_
u2 (ONLY with the fancy index-only U2 trick)
E _(E R U R' E' R U' R' -- Note : even better when the E/E' are done with the left middle finger so the left index finger can do the U')_
E' _(also E R U R' E' R U' R')_


MIDDLE FINGER (when the ring finger is the opposite finger)
when in grip E or D:
U2 _(antisune) _(cooldown affects the index finger too)
U' _(antisune)_ (for double turns)
when in grip D:
u' _(u' M' u2 M' u')_
u2 _(u2 M' u2 M') _(cooldown affects the index finger too)
E' _(again E R U R' E' R U' R')_
E_ (again E R U R' E' R U' R')_
E2_ (E2 R U R' E2 R U' R')_ (cooldown affects the index finger too)


MIDDLE FINGER (when the index finger is the opposite finger)
Any grip:
M' _(<M,U> Z-perm or U-perms)_
M _(U-perms)_
M2' _(H-perm)_ (cooldown affects the ring finger too)
when in grip U or E:
D2 _(?) _(cooldown affects the ring finger too)
D _ (?) _(for double turns)
when in grip U :
d2 _(some F2L) _(cooldown affects the ring finger too)
d _(some F2L) _(for double turns)
D' _(?)_
d' _ (some F2L)_
E' _(E R2 E' R2)_
E_ (E R2 E' R2)_
E2 (cooldown affects the ring finger too)


RING FINGER (when it is not the opposite finger)
Any grip:
M' _(M' U2 M U2)_
M _(M' U2 M U2)_
when in grip U or E:
D2 _(D2 R U R' D R U' R' D)_ (uses the pinky)
D _(D2 R U R' D R U' R' D)_
D' _(D R U R' D' R U' R')_
when in grip U :
d _(some F2L)_
d' _(some F2L)_
d2 _(some F2L)_
E _(?)_
E' _(?)_
E2 _(?)_


THUMB
F' _ (F R' F' R)_
F _(last move of the Y-perm ; F' R U R' U' R' F R)_


ONE HAND REGRIPS
"r"
"r'"
"r2"
"r2'"
"rolled R" (ring finger flick) _(<R,U> U-perm)_
"rolled r" (ring finger flick)_ (?)_
"rolled R2" (middle+ring finger flick) _(<R,U> U-perm)_
"rolled r2" (middle+ring finger flick)_ (?)_


FULL REGRIPS
All 23 regrips: x,x2,x',z,z2,z',y,y2,y',...


NO REGRIP (R/r moves)
(we must arrive in a legal relative orientation!)
(These moves are not symmetrized, and are only performed by the right hand.)
R
R'
R2
R2'
r
r'
r2
r2'


----------



## trangium (Dec 6, 2020)

SoundBalloon said:


> The alg execution the software uses is not always the best (it often is, so this isn't a big problem)


This is a valid concern. However, branching at every possible decision would make computational cost exponential in the length of the alg, making this not a very good option. A heuristic approach might be best, but I didn't want to deal with that.


SoundBalloon said:


> Does not handle regrips (yet?)


It does handle regrips. This penalizes algs such as R U R U R U R U R. It tries to minimize mid-alg regrips, in that it will go as far as possible without regripping before it preforms a regrip. Also, if you look in the source code, you can see regrip() written over 25 times. However, it does not handle rotations such as x, y, and z, so if that's what you meant by "regrip", that's a valid point.


SoundBalloon said:


> Some arbitrary coefficient choices, done "by hand" instead of using a statistical estimation method (one of the Algometer's strong points).


This is true for some coefficient choices, however, for most coefficients 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. 


SoundBalloon said:


> The calculation procedure could be clarified.


I don't understand this con. Does it mean that I did a poor job explaining how the movecount coefficient calculator worked? Even if that is the case, it doesn't affect the actual results that the movecount coefficient calculator outputs.


----------



## SoundBalloon (Dec 6, 2020)

Thank you for the detailed answer!



trangium said:


> (...) However, branching at every possible decision would make computational cost exponential in the length of the alg, making this not a very good option. (...)


Actually, if you enumerate the possible "grips", there is a way to compute the optimal alg in (number of grips)*(number of fingertricks)*(length of the alg). You do this by filling in a 2D array, indexed by the grips and the number of moves already executed in the alg, so that each slot contains the shortest partial execution that ends up in this grip at this point of the algorithm. I have a first draft of my hand simulator (that doesn't handle slice moves) that works just like that. It is still slow though: it is able to analyse ~100 algs of length ~13 per second, much slower than your software.



trangium said:


> It does handle regrips. (...) However, it does not handle rotations such as x, y, and z, so if that's what you meant by "regrip", that's a valid point.


Sorry for the mistake. I didn't look the source code, so I probably missed some functionalities of your software. I'll correct my post. Let me know if you spot further inaccuracies 



trangium said:


> This is true for some coefficient choices, however, for most coefficients 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.


That is a good way indeed. It is how I will proceed to estimate the length of each fingertrick: find algorithm that are alike but slightly different, so that I know precisely where the difference in execution time comes from.
I'm complaining that the choices are "arbitrary", but that's with my goal in mind: estimate everything from raw data. You didn't have that goal so your methodology is fine: if your software gives good result, then it's doing a great job.



trangium said:


> I don't understand this con. Does it mean that I did a poor job explaining how the movecount coefficient calculator worked? Even if that is the case, it doesn't affect the actual results that the movecount coefficient calculator outputs.


The explanation you posted is clear for the most part. The unclear part is the last two paragraphs: what are the exceptions? How do you model fingertricks, and in particular which ones do you include? Without knowing this it is hard to know if the execution your software finds would be considered good by a human.
Also, even though your software is heavily based on JPerm's Algometer, it is nowhere credited.

Nevertheless, I agree that it doesn't matter much as long as you just want to use the software. My goal is transparency, and yours isn't. Google's search engine is doing a great job even though its detailed inner workings are a trade secret. That doesn't detract from its main strength, since knowing how it works is secondary. Your software works -- if we want to find algs, we don't need to know how. But I want to understand what makes an alg fast, so I do want to know 

I updated the Pros and Cons of your entry accordingly.


----------



## Filipe Teixeira (Dec 6, 2020)

make a foot simulator next


----------



## SoundBalloon (Dec 7, 2020)

Filipe Teixeira said:


> make a foot simulator next


Thanks for the input. Though if you give me an exhaustive list of feettricks and get a top footcuber to time 100 algs why not. But I would do OH first.


----------



## MJS Cubing (Dec 7, 2020)

I would help, but My average is about 21-22


----------



## Ravagerous (Dec 10, 2020)

Filipe Teixeira said:


> make a foot simulator next



Great idea, I applaud it.


----------

