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

[Help Thread] Redi Cube Discussion & Help Thread

xyzzy

Member
Joined
Dec 24, 2015
Messages
2,877
Has anyone calculated the amount of permutations yet? I just got 1,571,364,748,800, but my math is probably incorrect seeing as I did it in a couple minutes. :p

Yeah, that's the correct value. 12!/2 for edge permutation, 3^8 for corner orientation.
 

DGCubes

Member
Joined
Feb 14, 2014
Messages
1,823
Location
Over there
WCA
2013GOOD01
YouTube
Visit Channel
I think there are 333 algs to solve all corners in one alg

(8*3^4 + 3*3^4 + 6*3^2 + 6*3^4 + 3^8)/24

I guess that counts the same case from different angles as one case? That's really not too bad, but it'd be a pain to recognize, and not really worth it imo.

I think with the method @fabdabs1234 and I are using, sub-10 global averages are possible with enough practice. In just 300 solves over the last week or so, my global average has dropped from 17 to 14, and my TPS is still pretty bad.
 

DGCubes

Member
Joined
Feb 14, 2014
Messages
1,823
Location
Over there
WCA
2013GOOD01
YouTube
Visit Channel
Did you switch?

Oh oops, I lied. I forgot our methods were slightly different. Most of it is the same, but I end the solve somewhat differently.
Here's a breakdown of the method I use now:

Blockbuild a layer
Solve four corner-edge pairs
Solve LL with sledges (maximum of 2)

Sorry about the confusion. :p
 

WaffleCuber

Member
Joined
Jun 13, 2017
Messages
23
Hey everyone, I got my redi cube a few hours ago and have had a lot of fun with it. I average around 55 seconds. Right now I just use hand scrambles. I was wondering if there are any good scramble generators? Thanks!
 

DGCubes

Member
Joined
Feb 14, 2014
Messages
1,823
Location
Over there
WCA
2013GOOD01
YouTube
Visit Channel
Yesssss, just got UWR single, 6.13! :D

Scramble: F R' r R r B' F L B F L B F' L'
y // inspection
f' L F' f' // first layer + one corner-edge pair
F // second corner-edge pair
Not sure exactly what I did for the last 2 pairs, but I know I got a sledge for LL. I was pretty hyped to see the whole face and first pair in inspection. :)
 

Nice One Bob!

Member
Joined
Aug 10, 2017
Messages
4
Location
New Zealand
Yesssss, just got UWR single, 6.13! :D

Scramble: F R' r R r B' F L B F L B F' L'
y // inspection
f' L F' f' // first layer + one corner-edge pair
F // second corner-edge pair
Not sure exactly what I did for the last 2 pairs, but I know I got a sledge for LL. I was pretty hyped to see the whole face and first pair in inspection. :)
waow good one!
 

DGCubes

Member
Joined
Feb 14, 2014
Messages
1,823
Location
Over there
WCA
2013GOOD01
YouTube
Visit Channel
Spotted this on YouTube just now: link because embeds are still broken

(I'm clearly not doing a very good job of advertising my own code lol.)

Haha, that's really awesome. Hopefully a bunch of competitions actually do the Redi Cube challenge.

By the way, I recently added to your random state Redi Cube scrambler. I started out by making a 2D Redi Cube simulator, and then I adapted your code to work with it so random state scrambles with pictures can be generated. Unfortunately it does look like a 3x3, as I didn't feel like coding the center piece to be split into four triangles and thought squares would be easier, so for now just ignore the center piece, lol. My code is absolutely disgustingly written, but it works for now. I'll comment it eventually. :p

It'd be nice if MoYu would consider using this full-fledged scramble generator for the Redi Cube challenge; I might try messaging them on Facebook about it.

Oh and sorry for stealing your code without asking first... if you want me to take this down or give you any more credit on the actual page, I'm completely OK with it. Thanks for making the awesome scrambler! :)
 

xyzzy

Member
Joined
Dec 24, 2015
Messages
2,877
Oh and sorry for stealing your code without asking first... if you want me to take this down or give you any more credit on the actual page, I'm completely OK with it.
I think it's fair to assume that, unless otherwise stated, all code posted without an explicit copyright licence is free for use. So yeah, download that car and steal that floppy! (And then there's this thing called the Berne Convention, which says that, no, this is completely wrong, and you don't need an explicit copyright notice for something to be copyrighted. I don't bother with copyright licences because that requires plastering my True Name all over it, but let's just say all of the code I write and post/link on these forums is WTFPL v2 unless otherwise stated.)

The thing that bothers me, though, is that you can actually just read off the state from the arrays used in generating the scramble… (The same thing happened with the original kilominx scramble drawer when Kit reimplemented all of the kilominx move logic instead of just using what was already there.)
There's a "generate_random_state" function, which does exactly that.

Code:
js> generate_random_state().toSource()
"[[9, 6, 10, 5, 1, 3, 0, 8, 7, 11, 2, 4], [1, 1, 1, 1, 0, 0, 1, 2]]"

The first array is the edge permutation and the second array is the corner orientation. For CO, 0 = correctly oriented, 1 = twisted ccw, 2 = twisted cw.

Edges: 0..3 = UF, LU, UB, RU; 4..7 = FL, BL, BR, FR; 8..11 = DF, LD, DB, RD
Corners: 0..3 = UFL, ULB, UBR, URF; 4..7 = DLF, DBL, DRB, DFR

The first entry in the EP array is 9, which means that the UF location gets the LD piece (i.e. orange-yellow). The second entry is 6, so the LU location gets the BR piece (i.e. blue-red). And so on.

And then we use the "solve" function to solve the given state with a two-phase algorithm (solve D layer first, then last two layers). The first run takes a bit longer because it needs to compute a bunch of lookup tables. Other than that, it tries out different D-layer solutions up to a maximum of 25 attempts and a time limit of 300 milliseconds and picks the best one found.

Normally, with a random-state scrambling algorithm, you'd want to invert the solution to get a scramble sequence. We don't do that here for two reasons. One, because we don't need to: the Redi Cube's states form a group, so taking the inverse of a state is a meaningful thing to do. Two, it causes the scramble sequence to almost never end with a short D-layer solution. If you're not blinded to the scrambles (as is the case when you don't have someone else to scramble cubes for you), merely knowing that there's a short D-layer solution in the scramble orientation could clue you into checking for a yellow layer first. (This is a similar problem to what I mentioned in the ZBLL trainer thread. The scramble sequence should leak as little information as possible.)

(That's the reason we don't do antisymmetry reduction. We don't do symmetry reduction either, but that's for ergonomic reasons: it's easier to make twists on only the U layer, and the current implementation automatically biases towards that.)

When you call solve(state), what you get is a sequence of a moves to solve it, not a sequence of moves to generate it. If all we care about are the scramble sequences, then for the above reasons, there's nothing else to do. But if we also want to draw the scrambles, you have to call something like solve(invert(state)) instead, and then implement an invert function because I didn't.

Or, you can also read the moves off the move array and apply them to a pristine cube, and then draw the result of that:
Code:
js> let state = generate_random_state()
js> solve(state)
[[0, 2], [5, 1], [1, 2], [2, 1], [7, 2], [6, 1], [5, 2], [1, 2], [0, 1], [2, 1], [3, 1], [0, 1], [3, 1], [2, 2], [3, 2]]
js> apply_move_sequence(solved, solve(state))
[[6, 4, 10, 5, 11, 3, 1, 8, 7, 0, 2, 9], [2, 2, 2, 2, 0, 0, 2, 1]]

(solve returns a list of 2-tuples; the first element is the move (0..3 = LBRF; 4..7 = lbrf) and the second element is the number of times to twist the corresponding corner cw.)
 

DGCubes

Member
Joined
Feb 14, 2014
Messages
1,823
Location
Over there
WCA
2013GOOD01
YouTube
Visit Channel
I think it's fair to assume that, unless otherwise stated, all code posted without an explicit copyright licence is free for use. So yeah, download that car and steal that floppy! (And then there's this thing called the Berne Convention, which says that, no, this is completely wrong, and you don't need an explicit copyright notice for something to be copyrighted. I don't bother with copyright licences because that requires plastering my True Name all over it, but let's just say all of the code I write and post/link on these forums is WTFPL v2 unless otherwise stated.)

The thing that bothers me, though, is that you can actually just read off the state from the arrays used in generating the scramble… (The same thing happened with the original kilominx scramble drawer when Kit reimplemented all of the kilominx move logic instead of just using what was already there.)
There's a "generate_random_state" function, which does exactly that.

Code:
js> generate_random_state().toSource()
"[[9, 6, 10, 5, 1, 3, 0, 8, 7, 11, 2, 4], [1, 1, 1, 1, 0, 0, 1, 2]]"

The first array is the edge permutation and the second array is the corner orientation. For CO, 0 = correctly oriented, 1 = twisted ccw, 2 = twisted cw.

Edges: 0..3 = UF, LU, UB, RU; 4..7 = FL, BL, BR, FR; 8..11 = DF, LD, DB, RD
Corners: 0..3 = UFL, ULB, UBR, URF; 4..7 = DLF, DBL, DRB, DFR

The first entry in the EP array is 9, which means that the UF location gets the LD piece (i.e. orange-yellow). The second entry is 6, so the LU location gets the BR piece (i.e. blue-red). And so on.

And then we use the "solve" function to solve the given state with a two-phase algorithm (solve D layer first, then last two layers). The first run takes a bit longer because it needs to compute a bunch of lookup tables. Other than that, it tries out different D-layer solutions up to a maximum of 25 attempts and a time limit of 300 milliseconds and picks the best one found.

Normally, with a random-state scrambling algorithm, you'd want to invert the solution to get a scramble sequence. We don't do that here for two reasons. One, because we don't need to: the Redi Cube's states form a group, so taking the inverse of a state is a meaningful thing to do. Two, it causes the scramble sequence to almost never end with a short D-layer solution. If you're not blinded to the scrambles (as is the case when you don't have someone else to scramble cubes for you), merely knowing that there's a short D-layer solution in the scramble orientation could clue you into checking for a yellow layer first. (This is a similar problem to what I mentioned in the ZBLL trainer thread. The scramble sequence should leak as little information as possible.)

(That's the reason we don't do antisymmetry reduction. We don't do symmetry reduction either, but that's for ergonomic reasons: it's easier to make twists on only the U layer, and the current implementation automatically biases towards that.)

When you call solve(state), what you get is a sequence of a moves to solve it, not a sequence of moves to generate it. If all we care about are the scramble sequences, then for the above reasons, there's nothing else to do. But if we also want to draw the scrambles, you have to call something like solve(invert(state)) instead, and then implement an invert function because I didn't.

Or, you can also read the moves off the move array and apply them to a pristine cube, and then draw the result of that:
Code:
js> let state = generate_random_state()
js> solve(state)
[[0, 2], [5, 1], [1, 2], [2, 1], [7, 2], [6, 1], [5, 2], [1, 2], [0, 1], [2, 1], [3, 1], [0, 1], [3, 1], [2, 2], [3, 2]]
js> apply_move_sequence(solved, solve(state))
[[6, 4, 10, 5, 11, 3, 1, 8, 7, 0, 2, 9], [2, 2, 2, 2, 0, 0, 2, 1]]

(solve returns a list of 2-tuples; the first element is the move (0..3 = LBRF; 4..7 = lbrf) and the second element is the number of times to twist the corresponding corner cw.)

Wow, I probably should've thought about trying to understand your code beforehand, lol. I might try using your functions for a V2; I was planning on making my code cleaner in the future anyway. Thanks for all the info, and for being cool with me using your code! :)
 

WaffleCuber

Member
Joined
Jun 13, 2017
Messages
23
I've found that you can usually get really close to optimal just by intuitively matching up the edges to the corners, although an "algorithmic" approach for some cases might be useful. (Maybe the ones where there's no ready-made corner-edge pair?)
Haha I was about to post about this thinking it was an original idea (to do this intuitively) but then I read this and found out I reinvented something lol. anyway I think this is definitely a viable method. I can do this step in around 7 seconds with decent cases(This could be improved to around 3 I bet for faster people)
 
Last edited:

Cale S

Member
Joined
Jan 18, 2014
Messages
2,421
Location
Iowa, USA
WCA
2014SCHO02
YouTube
Visit Channel
22.15 avg12 with only one sub-20 single, I'm too consistent

How viable would 3-style be for speedsolving? Solving corners takes like 3 seconds on average, you could force some edges to be solved and then probably like 5 edge cycles which would average 5 moves, taking 2 seconds for each would be 13ish average

also only 55 cases
 
Top