Request for 4x4x4 LL scrambler.

[DavidWoner]

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 them and even possibly give them a hug (or not if that is their preference).

 

[Kirjava]

If someone makes it I'll do lots more of this

 

[Zarxrax]

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.

 

[Kirjava]

You still have to find a way of generating algs for the 40320 ELL cases that there are.

If we had a list of algs this would be easy.

 

[Zarxrax]

Oh, I thought there were cases for this >.>
carry on then.

 

[qqwref]

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]

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.

 

[vcuber13]

what about doing something like RrFU scrambles then optimally solve the rest of F3L? or something similar

 

[StachuK1992]

Someone should just make kSolve not suck.
Ideas here?

 

[qqwref]

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]

Someone should just make kSolve not suck.
Ideas here?

ksolve can generate <U,r> solutions for the LL edges, but probably a little too slow for what you would want for this application. Also, I don't know if ksolve can be told to stop after the first solution found.

 

[StachuK1992]

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.

 

[cuBerBruce]

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.

 

[deepSubDiver]

Can we generate parity situations with just <U,r>? If we can, I'll probably have a look into this.

 

[qqwref]

Can we generate parity situations with just <U,r>? If we can, I'll probably have a look into this.

r U2 r U2 r U2 r U2 r

 

[MaeLSTRoM]

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]

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.

 

[cuBerBruce]

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.

 

[cuBerBruce]

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

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]

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.

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)