Finger-trick Optimal Algorithm Finder

[NaeosPsy]

Hi.
A friend of mine asked me to write a part of text for he's coursework, it's about computer program which could find finger-optimal algorithms for 2x2 methods(like, not the ones with less moves, but ones who are the fastest to execute),mostly the less documented ones - OFOTA, SOAP, SS. I wanted to ask you guys, if you have any ideas that I could use in writing. It's the theoretical part, so mostly just chit-chat about options it should have, and what advantages it could bring. ^^

 

[Ickathu]

Finger tricks are unique to each person. For instance, I find the <MU> subset incredibly fast, but a ZZ user may prefer <LUR>, and a CFOP user would probably prefer <RU>. I personally hate <LUR> but I'm fine with <RUD> which is just a cube rotation from <LUR>

 

[applemobile]

If you take a very simple alg such as Sune, and look how many different ways people 'finger trick' it, I think it shows that that you will never find a common to work with. Just too many variables. Not to mention some Algs (anything 2gen) look like they will be easy/fast, yet they just aren't, for various reasons.

 

[Escher]

Finger tricks are unique to each person. For instance, I find the <MU> subset incredibly fast, but a ZZ user may prefer <LUR>, and a CFOP user would probably prefer <RU>. I personally hate <LUR> but I'm fine with <RUD> which is just a cube rotation from <LUR>

Not sure if preferences are important really, it's more about what is easily possible (lots of people don't use LH index push on LUB but it has made a ton of my algs much smoother). Nobody used to use ring D until it was popularised by a couple of people a while ago.

Just creating a model for fingertrick use would take quite a bit of work, though I imagine a structured tree of pre-requisites for certain types of moves would be a start. For example, one could map the possible moves from various starting grips for RH, then describe how each move or common group of moves affect grip or wrist rotation, and structure a bunch of pre-requisites for allowing certain moves to follow previous ones. For many cases there wouldn't be a 'best' execution let alone a best algorithm, but I think that would just make it more useful for being flexible to individuality.

A big problem is displaying the alg in a way that shows how it is meant to be performed, raw notation doesn't describe execution at all, perhaps besides the movegroup it is written in.

 

[NaeosPsy]

He has thought out notation for various hand positions and it also shows which fingers are used for pushes. It's pretty simple I think.

About preferences to certain move groups, I thought that it should have an option to describe preferences, like - RUD,RFU,RUL, burst or close to move optimal and more tricky, and include/exclude OH and other flicks.

 

[CarlBrannen]

So each move needs a "cost" and in addition, a user would need to give a cost for the transition from one move to the next. This seems doable even for bigger cubes.

 

[JustinJ]

Somewhat related, the TNoodle 2x2 scrambler was recently outfitted with a cost function to spit out more fingertrick-friendly scrambles. I haven't tried it, but I think it's a really cool idea.

The file

 

[Lucas Garron]

Make sure to look at Gripper.