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.
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.
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 think with the method @fabdabs1234 and I are using
Did you switch?
https://torchlight.github.io/rediscrambler.htmlHey 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!
That is random state too iirc
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.)
Hopefully a bunch of competitions actually do the Redi Cube challenge.
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.)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.
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]]"
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]]
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.)
Awesome! I just signed up for it. Guess I better get to practicing it moreThe Redi Cube challenge will be happening at KCubingFall2017, so there's one more!
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)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?)
The Redi Cube challenge will be happening at KCubingFall2017, so there's one more!
Thread starter | Similar threads | Forum | Replies | Date |
---|---|---|---|---|
redi cube | Hardware Area | 10 | ||
Predictions for new cubes (Any Brand) | Hardware Area | 42 | ||
help on redi cube notation | Cubing Help & Questions | 3 | ||
Cube Master’s Predictions (Live updates) | General Speedcubing Discussion | 38 | ||
My redi cube progression | Cubing Progression | 4 |