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.
Yeah, that's the correct value. 12!/2 for edge permutation, 3^8 for corner orientation.
[Help Thread] Redi Cube Discussion and Help
- Thread starter DGCubes
- Start date
Yeah, that's the correct value. 12!/2 for edge permutation, 3^8 for corner orientation.
Cale S
Veteran
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
(8*3^4 + 3*3^4 + 6*3^2 + 6*3^4 + 3^8)/24
DGCubes
Veteran
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.
Did you switch?
DGCubes
Veteran
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.
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!
Cale S
Veteran
Ghost Cuber
Veteran
That is random state too iirc
DGCubes
Veteran
Yesssss, just got UWR single, 6.13! 
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.
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
waow good one!Yesssss, just got UWR single, 6.13!
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.
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.)
(I'm clearly not doing a very good job of advertising my own code lol.)
DGCubes
Veteran
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.
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!
Guildford Open will have it, and Fabio will be there, but I expect he'll do about as well as he does in most official events
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.
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:
(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.)
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.)
biscuit
Veteran
The Redi Cube challenge will be happening at KCubingFall2017, so there's one more!
DGCubes
Veteran
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!
Draranor
Premium Member
Awesome! I just signed up for it. Guess I better get to practicing it more
WaffleCuber
Member
- Joined
- Jun 13, 2017
- Messages
- 23
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
Veteran
Cale S
Veteran
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
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
Similar threads
