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.

I didn't check too many scrambles, but those seem okay (nice distribution of the pieces, about 50% orientation and about 50% permutation parity). It is also pretty efficient, but not optimal.

However, holy ****. This seems to be pretty much exactly what we were after. Any chance you could release the program? It would be useful if you released the source too so we could incorporate this into Nibblr or Minxy.

I didn't check too many scrambles, but those seem okay (nice distribution of the pieces, about 50% orientation and about 50% permutation parity). It is also pretty efficient, but not optimal.

Edit, I forgot to mention: Scramble length can be easily increased for more randomness, but I think 35 moves is okay.

So, clearly this is not a random-state based scrambler. It looks like you are making some number of random <U,r> moves (alternating the axis on each move, of course) and then solving (also in <U,r>) the F3L pieces with a depth-first search. You seem to ignore the LL corners, so typically an AUF is needed to solve them. This probably doesn't matter much, except that randomness of the edge configurations needs to be checked with respect to the LL corners rather than with respect to the F3L.

I have generated optimal <U,r> scrambles for all 40319 cases of the 4x4x4 with everything solved except for the last layer edges. The number of moves required ranges from 12 moves to 27 moves. Only 2 configurations require 27 moves. These two cases were solved with my program on my computer in under 20 seconds each. On average, about 1.2 seconds was needed per case. The average number of moves is about 22.526.

The 12-movers are the canonical H-Perm and the UF-UB dedge swap.

Interesting distribution. I'm a bit surprised at how quickly it drops off, and how the odd numbers seem to be higher than the next even number.

I think, for speed purposes, it would not be too crazy to hard-code in the 26 and 27 move cases, and then only search up to 25 moves. What do you think? (Also: If we don't count AUF before and after, how does that improve the search speed?)

Interesting distribution. I'm a bit surprised at how quickly it drops off, and how the odd numbers seem to be higher than the next even number.

I think, for speed purposes, it would not be too crazy to hard-code in the 26 and 27 move cases, and then only search up to 25 moves. What do you think? (Also: If we don't count AUF before and after, how does that improve the search speed?)

I could change the code to consider there to be 4 solved states instead of 1. This would allow eliminating the AUF at the end of a scramble. For some cases, all optimal <U,r> scrambles start with a U layer move. For example, for the UL-UR dedge swap, all optimal <U,r> scrambles start with a U or U' move. So you can't assume the scramble can start with an r layer move.

Kirjava, can I email you a half-megabyte zip file at the email address on your K4 page? Also, I would like to know what data you want. I have generated all optimal scrambles (for the corners solved states) as well as 1 per case. Right now, my one per case data set has cases where the scramble could be replaced by a maneuver where an AUF could be omitted at the end. So if you want scrambles that are "optimized" in this way, I can send the maneuvers after I regenerate the data in that manner.

Kirjava, can I email you a half-megabyte zip file at the email address on your K4 page? Also, I would like to know what data you want. I have generated all optimal scrambles (for the corners solved states) as well as 1 per case. Right now, my one per case data set has cases where the scramble could be replaced by a maneuver where an AUF could be omitted at the end. So if you want scrambles that are "optimized" in this way, I can send the maneuvers after I regenerate the data in that manner.

Yeah, just send it over to [email protected]. Half a meg doesn't seem that big.

I'd just like one scramble per case. Preferably one on a line each with no other data on the line. Please keep the AUF in as we would like corners solved.

I have now calculated "optimized" <U,r> move sequences if you want to allow the corners to be an AUF move from solved. The edge permutation is considered to use the corner pieces as reference, so a U layer turn is not considered to change what edge permutation case you have. I have added this move count distribution to the spoiler in my [post=601369]post[/post] earlier in the thread.

I also note that of the of the 11 cases that require 13 moves (where corners are kept fixed, not AUF'ed), 2 of those were odd parity. These are inverses of each other, and 4-cycle the UF and UB dedge pieces. I note these are also palindromes. (These are known manuevers. I am not claiming them to be newly discovered.)

r U2 r2 U2 r' U2 r U2 r' U2 r2 U2 r
r' U2 r2 U2 r U2 r' U2 r U2 r2 U2 r'

Given qqwref showed that there are 9-move 4-cycles (involving non-LL edge pieces), I guess it should not be too surprising to find 4-cycles among the 13-move maneuvers affecting only LL edges. (Yeah, I know these 4-cycles really also have hidden effects on center pieces as well.)

Attached is the source code that I used for generating the optimal <U,r> maneuvers for the various ELL cases. The file is intended to be the primary file in a "Win32 Console Project" for Microsoft Visual Studio, so if you are using another compiler, just delete the line with #include "stdafx.h" and it should probably compile fine.