• 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.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Request for 4x4x4 LL scrambler.

DavidWoner

The Punchmaster
Joined
May 7, 2008
Messages
3,936
Location
Kansas City, MO, USA
WCA
2008WONE01
YouTube
Visit Channel
ELL is by far my worst phase of K4 and I'd like to improve since I have poor time management when it comes to cubing. I'd like to practice it without having to go through all that F3L stuff first. As I've pointed out in previous requests, I can't program my way out of a paper bag so once again I have to ask someone else.

I'd assume the easiest implementation is to choose from a list of pre-generated algs for LL positions. If this is the case then just an ELL scrambler would be much easier than a full LL scrambler.

If someone can do this I would <3 them and even possibly give them a hug (or not if that is their preference).
 

Zarxrax

Member
Joined
Jan 7, 2009
Messages
1,282
Location
North Carolina
I might be willing to try adapting support for 4x4x4 into this, but I'm not too familiar with 4x4x4 notation, though I do know that there are several varieties of notation out there.
It does support double layer turns already [r, u, d, etc] but this was intended for 3x3x3, so I have no idea what effect it would have on 4x4.
 

qqwref

Member
Joined
Dec 18, 2007
Messages
7,834
Location
a <script> tag near you
WCA
2006GOTT01
YouTube
Visit Channel
If someone's willing to give me a bunch of algs I could whip up something similar to the old random-state pyraminx scrambler The program would imagine a random ELL state and then solve it in 3 looks in a mechanized way (such as L edge - R edge - F/B edges) and output the solve. It would be a lot of moves, but a lot less than doing a solve and unsolve, and it would definitely be random.

If you want me to do this, I'll need to make a list of all possible scenarios for those cases. Are the ones in [wiki]KBCM Step 6[/wiki] any good?
 

Kirjava

Colourful
Joined
Mar 26, 2006
Messages
6,121
WCA
2006BARL01
YouTube
Visit Channel
The problem with that is that it's quite obvious to tell when you're going to get parity.

Lots of moves is annoying too. Someone else made a crappy one of these and my solutions were shorter than the scrambles.
 

qqwref

Member
Joined
Dec 18, 2007
Messages
7,834
Location
a <script> tag near you
WCA
2006GOTT01
YouTube
Visit Channel
The problem with that is that it's quite obvious to tell when you're going to get parity.
Pretty sure there's no way around this. It's the same idea as asking for a post-reduction 4x4 scrambler - parity situations will always take longer just because of the constraints that are set up.

Lots of moves is annoying too. Someone else made a crappy one of these and my solutions were shorter than the scrambles.
To be fair, the movecount would probably be something like 30-35 slice moves on average - not TOO bad. You could even try a more intelligent way, where if some pieces are solved it will work around those to only solve what it needs to. But I think that would require a lot more thought, and be a lot more annoying to program.
 

cuBerBruce

Member
Joined
Oct 8, 2006
Messages
914
Location
Malden, MA, USA
WCA
2006NORS01
YouTube
Visit Channel
I know it can do that, which is why I said we should make it *better*.

I'm hoping someone had an idea of *how* to make it faster. As in, a rewrite of sorts for the program.

Well, I haven't seen the source code for ksolve. It would certainly be easier to write a custom <U,r> or <U,Rw> solver program than to write a new and better "ksolve" from scratch.
 

MaeLSTRoM

Member
Joined
Jan 7, 2011
Messages
1,862
Location
UK
WCA
2011WALL02
YouTube
Visit Channel
What also would be good is maybe a <r,l,u> scrambler that then solves the centres and DF/DB. that might potentially give a better scrambler for K4 ELL. just a thought.
 

deepSubDiver

Member
Joined
Jun 17, 2009
Messages
161
Location
Germany
What also would be good is maybe a <r,l,u> scrambler that then solves the centres and DF/DB. that might potentially give a better scrambler for K4 ELL. just a thought.
That is the basic idea I had, but <r,l,U> is probably a little too much to compute for just generating a scramble. The search tree would get a value of 6 (9 initially) in width and we had to track 16 pieces.
 
Last edited:

cuBerBruce

Member
Joined
Oct 8, 2006
Messages
914
Location
Malden, MA, USA
WCA
2006NORS01
YouTube
Visit Channel
What also would be good is maybe a <r,l,u> scrambler that then solves the centres and DF/DB. that might potentially give a better scrambler for K4 ELL. just a thought.

That is the basic idea I had, but <r,l,U> is probably a little too much to compute for just generating a scramble. The search tree would get a value of 6 (9 initially) in width and we had to track 16 pieces.

I think MaeLSTRoM meant generating a random sequence of perhaps 25 or 30 <r,l,U> moves (similar to vcuber13's idea), not writing an <r,l,U> solver. Care would be needed so that solving the edge D Layer edges doesn't affect the probability distribution of the 8 LL edge pieces. (And, of course, an AUF would be needed to solve the corners, assuming you want them solved. If you want corners scrambled, then an extra move sequence for scrambling the corners would be needed.)

Keep in mind whether or not you want a scrambler that only "preserves" the centers on the 4x4x4 or works for all big cube sizes too. If so, then the scrambles will need to be longer and many optimal <U, r> algorithms that work on the 4x4x4 won't be able to work on other big cube sizes.

We've not been talking about any cubes other than 4x4x4 in this thread. And I've been assuming that centers on a given face are to be considered indistinguishable.

If anyone really wants a scrambler that has any chance of using fewer moves than a human solution, you must allow more types of moves than just <U, r>.

<U,r> seems to generate solutions of around 25 moves. I think that this would be adequate for what David asked for, even if the sequences might be longer in some cases than what a person would need to solve them.

What counts as an ELL scramble? Surely we all can agree that if 2, 3, or 4 (and probably 5) wings unsolved is not considered a scramble. So, the maker of this software should know if indeed 6 or more wings messed up is a scramble or not. That definitely would lessen the number of algs to be found.
I've been assuming the scrambler would generate any of the 40320 cases with equal probability - well, except probably rejecting the solved case. If additional easy cases are to be rejected, it is easy to do that when using a random state generator. With a generic <U,r> solver, you would not need to find any algs up front (assuming it can generate them fast enough). You only need to find algs up front if you are using an n-phase solver approach like what qqwref suggested.
 
Last edited:

cuBerBruce

Member
Joined
Oct 8, 2006
Messages
914
Location
Malden, MA, USA
WCA
2006NORS01
YouTube
Visit Channel
I wanted to see if a custom search program could find <U,r> solutions significantly faster than ksolve. I now have some working code, and indeed a significant improvement was achieved. I used a test case that was generated from manually scrambling a cube and solving the first 3 layers and the corners. This particular test case had a 25-move optimal solution in <U,r> for either center pure or center non-pure. The test runs were done on the same computer (a fairly fast computer).

Code:
Solver                 First solution    Finish depth-25 search

ksolve (center-pure)       80 sec            122 sec
ksolve (non-center-pure)  171 sec            443 sec
custom (non-center-pure)    3 sec              7 sec

I think this test may have a higher than average move count, so typical solves may be faster. However, I'm concerned that worst case solutions may require significantly longer because of exponential time growth with respect to number of moves.
 

deepSubDiver

Member
Joined
Jun 17, 2009
Messages
161
Location
Germany
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.
Code:
Loaded pruning table: centers, nodes: 18900
Loaded pruning table: edges, nodes: 90

Number of scrambles: 25

 1: U2 r' U' r U' r U' r U2 r2 U' r2 U2 r2 U2 r U r2 U r2 U r' U r U2 r U r U' r U r' U r  (34 BTM)
 2: r U r U2 r2 U' r2 U' r U' r2 U2 r U' r2 U2 r U' r' U' r' U2 r U' r U' r U' r2 U r U2 r  (33 BTM)
 3: r2 U2 r2 U2 r U r2 U' r' U r' U r' U2 r' U' r U2 r' U' r' U' r2 U' r' U' r U2 r' U r2 U2 r  (33 BTM)
 4: r' U r' U r U2 r U r U2 r U r2 U' r2 U r2 U2 r' U r2 U' r' U2 r2 U r' U r U r2 U2 r  (33 BTM)
 5: r U2 r2 U2 r U' r2 U' r' U' r2 U2 r' U' r2 U r U2 r2 U r' U' r' U r2 U2 r U r2 U' r U r'  (33 BTM)
 6: U r2 U' r' U r U2 r' U' r' U2 r2 U2 r U r' U2 r U2 r' U2 r' U r U' r2 U r2 U' r U2 r  (32 BTM)
 7: r U r2 U' r U' r' U' r U2 r2 U' r2 U' r2 U' r U2 r2 U' r2 U r' U' r2 U2 r' U r U' r' U2 r  (33 BTM)
 8: r2 U' r2 U' r' U r2 U' r2 U2 r' U r2 U' r' U' r U r U' r' U r' U2 r' U r2 U r U2 r U' r  (33 BTM)
 9: U' r2 U' r' U r' U r U r2 U' r2 U' r' U' r' U' r' U r' U2 r2 U2 r' U2 r U r2 U' r' U' r  (32 BTM)
10: r2 U' r' U2 r U' r U' r U r U' r' U2 r' U2 r2 U r2 U r U r' U2 r' U2 r' U' r' U2 r U r2  (33 BTM)
11: U2 r U r U' r2 U2 r2 U2 r' U2 r2 U' r' U' r U2 r U' r' U r' U r U r2 U' r' U r U' r2 U2 r'  (34 BTM)
12: U' r U2 r2 U r U r2 U' r' U' r' U2 r U' r U r' U2 r U2 r U2 r' U' r2 U2 r' U' r2  (30 BTM)
13: U2 r U2 r2 U2 r' U2 r U r' U' r' U2 r' U r2 U' r2 U' r' U' r2 U r2 U' r2 U2 r U2 r' U' r'  (32 BTM)
14: r' U' r' U' r U2 r' U r' U' r2 U' r U2 r' U r2 U2 r2 U2 r2 U' r2 U2 r' U2 r U r U' r2 U r'  (33 BTM)
15: U r' U r U' r U' r U2 r2 U r' U r2 U' r2 U r2 U2 r' U2 r' U' r2 U' r U' r' U2 r' U' r  (32 BTM)
16: r U2 r' U r2 U2 r' U r' U r2 U r2 U r U2 r2 U' r' U' r U r' U2 r2 U r' U r' U r U2 r  (33 BTM)
17: U r U2 r2 U r U' r U r' U r2 U' r U' r2 U2 r U r U r2 U r2 U r U r U' r U2 r' U r2  (34 BTM)
18: r2 U r2 U2 r U' r' U r' U' r2 U' r2 U2 r2 U' r U2 r2 U r U r' U r U r2 U' r2 U r2 U r'  (33 BTM)
19: U r2 U' r' U r2 U2 r U2 r U2 r2 U2 r2 U r' U2 r2 U' r U r' U2 r2 U2 r2 U r2 U' r  (30 BTM)
20: r U2 r2 U' r' U' r' U r' U2 r U r2 U' r' U r2 U r' U r' U' r U2 r2 U2 r U r2  (29 BTM)
21: U2 r U r' U2 r2 U r2 U r U2 r2 U' r U2 r2 U' r U2 r2 U r' U2 r2 U r U' r U2 r2 U r' U2 r2  (34 BTM)
22: U' r' U2 r' U' r U r U' r U2 r' U r2 U' r' U r' U' r2 U2 r' U r2 U2 r2 U r2 U2 r U2 r  (32 BTM)
23: U' r' U2 r U2 r' U' r2 U r2 U r U2 r2 U r U r U r U r U' r U r U' r2 U r' U2 r'  (32 BTM)
24: U' r2 U' r' U' r' U' r2 U r' U2 r U2 r U2 r2 U2 r' U r2 U2 r U r U r2 U' r' U2 r U2 r  (32 BTM)
25: r2 U2 r2 U2 r U r U r2 U2 r2 U' r2 U' r2 U' r U r' U2 r2 U2 r2 U r2 U' r2 U r U' r2 U' r'  (33 BTM)

Time computed: 0,106 seconds (average: 0,00424 seconds)
 
Last edited:
Top