Fridrich F2L Move Count

[Cride5]

I've been scouring the internet to find some figures for the average optimal move-count of Fridrich F2L, but unfortunately I've only been able to find estimates based on a small sample of human or computer solves.

Has anyone computed the figures for this?

Ideally, what I would like to know is the average optimal move count for solving four slots:

(1) in fixed order
(2) in 'best first' order
(3) simultaneously

Here are some links to material I've found on it so far...
http://www.speedsolving.com/forum/archive/index.php/t-2504.html
http://stefan-pochmann.info/misc/F2Lstudy/
http://www.speedsolving.com/forum/showthread.php?p=69583#post69583
http://www.speedsolving.com/forum/showthread.php?p=96007

 

[blakedacuber]

well it takes me on avg 56 moves using 3ll and f2l

 

[Zarxrax]

What do you mean by "optimal"? You can optimize f2l for a rather small number of moves, but it would be slower than using longer sequences that are more fingertrick friendly.
If you just want to go by an algorithmic based move-count, you could just choose an f2l algorithm list, find the average number of moves across all cases, then multiply that by 4. That might give you a good estimate.

 

[riffz]

well it takes me on avg 56 moves using 3ll and f2l

56 moves for F2L or the whole solve??


Cride, is solving F2L considered to be solving the cross and then after each slot the cross is still solved? (Not referring to the multi-slotting case.)

 

[Stefan]

Section 4.2 of my thesis has statistics for best-first order of 10,000 solves and for fixed order of 1,000 solves, not sure whether you've seen it already but it's not in your references:
http://stefan-pochmann.info/hume/hume_diploma_thesis.pdf

 

[Cride5]

Section 4.2 of my thesis has statistics for best-first order of 10,000 solves and for fixed order of 1,000 solves, not sure whether you've seen it already but it's not in your references:
http://stefan-pochmann.info/hume/hume_diploma_thesis.pdf

Hi Stefan, I wasn't aware of your thesis, thanks for sharing. Looks interesting .. I think I'll have a proper read of it later!

The stats for 10,000 solves should be robust enough. The only question: is 'Hume' an optimal solver?

What do you mean by "optimal"? You can optimize f2l for a rather small number of moves, but it would be slower than using longer sequences that are more fingertrick friendly.
If you just want to go by an algorithmic based move-count, you could just choose an f2l algorithm list, find the average number of moves across all cases, then multiply that by 4. That might give you a good estimate.

By optimal I mean optimal. The fewest number of moves to solve each slot (cases 1 and 2), or all four at once (case 3). Algorithm lists don't include all cases where pieces aren't available in the U-layer and don't take advantage of free slots. Using that approach would be a poor estimate.

Cride, is solving F2L considered to be solving the cross and then after each slot the cross is still solved? (Not referring to the multi-slotting case.)

In cases (1) and (2), yes. In case (3) they are all done at once so so the cross may (and probably will) be messed up between slots. Case 3 would show the potential for Fridrich in an FM-style solve where the solver is considering all four slots simultaneously. Of course this is an unrealistic goal for a human solver, but it illustrates the potential and is useful for comparison with other methods.

 

[Stefan]

The stats for 10,000 solves should be robust enough. The only question: is 'Hume' an optimal solver?

It should be optimal in each solution step ("should be" in the sense that it is if I implemented it correctly). So optimal cross, then optimal first slot, then optimal second slot etc.

 

[Lucas Garron]

The stats for 10,000 solves should be robust enough. The only question: is 'Hume' an optimal solver?

It should be optimal in each solution step ("should be" in the sense that it is if I implemented it correctly). So optimal cross, then optimal first slot, then optimal second slot etc.

Lovely if we could see those results ourselves. Source?
(Poke.)

 

[Cride5]

The stats for 10,000 solves should be robust enough. The only question: is 'Hume' an optimal solver?

It should be optimal in each solution step ("should be" in the sense that it is if I implemented it correctly). So optimal cross, then optimal first slot, then optimal second slot etc.

OK Cheers ... I trust your implementation

One more question, I couldn't find much detail about the scramble method used, but I did see something about a scramble parameter T (number of turns). Was the scramble method 25 random moves, rather than a random cube state?

 

[Stefan]

Lovely if we could see those results ourselves. Source?
(Poke.)

I saw that coming

Ok, I'll put it up soon, though it'll probably still be ugly, slow, and not easy to use. Problem is that at some point I realized I had to turn in the thesis but not the program. So I polished the thesis but not the program. For example I think I did have some memory leak and actually couldn't do very large experiments, ran the program 10 times with 1,000 solves each time or so and combined the results.

One more question, I couldn't find much detail about the scramble method used, but I did see something about a scramble parameter T (number of turns). Was the scramble method 25 random moves, rather than a random cube state?

Good question, don't quite remember. Not random state, that would've required too much intelligence (keep in mind the program is designed for arbitrary puzzles, not just 3x3x3, and I'd like to ensure the scrambled state is solvable). Looks like I used 50 moves, possibly canceling.