# Request for 4x4x4 LL scrambler.

#### Owen

##### Member
Just use a regular 4x4x4 scramble, and solve everything but the last layer. Wow people, don't be lazy.

#### irontwig

##### Member
Just use a regular 4x4x4 scramble, and solve everything but the last layer. Wow people, don't be lazy.
I don't think that the fact that some people might want to use their practice times efficiently has a lot to do with laziness.

#### Kirjava

##### Colourful
Surely we all can agree that if 2, 3, or 4 (and probably 5) wings unsolved is not considered a scramble.
I disagree with this. No current cube scrambler does this and I don't see why ELL should be any different.

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.
In this context, only one type of parity exists.

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.

Just use a regular 4x4x4 scramble, and solve everything but the last layer. Wow people, don't be lazy.
Well done, you missed the entire point of the thread.

#### cuBerBruce

##### Member
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.

#### cuBerBruce

##### Member
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.

The complete distribution:
Code:
moves  count   count if final AUF ignored
11       0         2
12       2         1
13      11        14
14       4        14
15      86       108
16      56       240
17     414       290
18     162       600
19    1495      1593
20    1170      3443
21    6146      6486
22    5589      9851
23   15269     12888
24    7108      3978
25    2729       807
26      76         4
27       2         0
-----     -----
40319     40319

EDIT: I've updated the table in the spoiler to give the distribution when AUF maneuvers at the end of a scramble are ignored.

Last edited:

#### qqwref

##### Member
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?)

#### Kirjava

##### Colourful
cuBerBruce: can you paste the list somewhere? this is pretty much exactly what we need

#### chicken9290

##### Banned
use yau its a better method (i learned it in a day and started averaging sub 65 seconds)

#### cuBerBruce

##### Member
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.

cuBerBruce: can you paste the list somewhere? this is pretty much exactly what we need
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

##### Colourful
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.

Thanks!

#### cuBerBruce

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

Last edited:

#### cuBerBruce

##### Member
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.

#### Attachments

• 6.2 KB Views: 28