The latest feature that needs testing is solve reconstructions. I do my best to take your solve and break it down into Roux moves, trying to recognize `r` moves for example even if your cube doesn't contain a gyro. For each phase of your solve, the analysis can show you a potentially shorter version.
Here's what this looks like graphically:
First Block: a much shorter solution was possible.
In this case, the user has clicked on the 'First Block' phase, either by clicking that row of the table or by clicking that bar in the bar chart. The alternate first block looks much shorter -- perhaps too short, but worth checking out to see if you might have spotted it during the actual solve.
Sometimes, your solution is about as good as the discovered one but it might still be worth looking to see if you could save a move, or consider whether the proposed solution was better for finger tricks...
Square: R2 is more ergonomic M2, so the proposed solution might be better.
Last Pair: M2 could be avoided and a move saved.
LSE: Whoah. Major savings here.
Looking over the whole solve, if the same TPS could be maintained in first block and LSE, those two stages alone could cut this solve from 59.2s down to 37s, hopefully guiding the aspiring speed solver to focus on better FB planning and execution plus a bit more recognition for LSE.
The solve
exports to Twizzle like this:
// Scramble: B' U' F' L U2 F' R L2' U B' L2' U2 B' U2 F' L2' U2 L2' B2' R2 B2'
x2 x D B F R2 B F' R' D' D U' F' D R' D U' B D' // First block(17) vs (7) x2 x' D F D2 r2 B
r' U' r' U' M2 R' U R // Square(8) vs (6) R2 U' R' M' U R
M' U2 M2 r U r' // Last pair(6) vs (6) M' U2 R M U R'
U' F R U R' U' F' U' R U R' F' R U R' U' R' F R2 U' R' // CMLL(21) vs (0)
U r R' U R r' U2 M' U M' R r' M' U U' U M2 U' M2 U M' U2 M3 // LSE(23) vs (10) U M U M2 U' M' U2 M' U M' |
which can be done by either clicking the 'copy' button and pasting it, or clicking the 'Tw' button on the player.
If a solve reconstruction is wrong, you can PM me an automated test case by clicking the bug icon, which will generate this:
// Bug Report: incorrect solve reconstruction.
validateUserSolution({
scramble: "B' U' F' L U2 F' R L2' U B' L2' U2 B' U2 F' L2' U2 L2' B2' R2 B2'",
orientation: "x2 ",
fb: "x D B F R2 B F' R' D' D U' F' D R' D U' B D' ",
ss: "r' U' r' U' M2 R' U R ",
lp: "M' U2 M2 r U r' ",
cmll: "U' F R U R' U' F' U' R U R' F' R U R' U' R' F R2 U' R' ",
lse: "U r R' U R r' U2 M' U M' R r' M' U U' U M2 U' M2 U M' U2 M3 "
}); |
which is code I can copy/paste into the unit tests that will validate the solution actually solves the cube, and that the optimized solution steps can be executed in place of the user's solution for that step and get the cube into the correct state for the phase (not necessarily the identical state the user achieved, but the same FB the user chose with other pieces potentially different).
This needs a fair bit of testing because there were a lot of bugs putting this together. GAN's MonsterGo cube is pretty cost effective if you don't want to spend a lot of money on a higher-end bluetooth cube. It is $37 CAD at cubingoutloud (that's $27 USD). Unfortunately it doesn't contain a gyro but it's a pretty reasonable bluetooth cube at that price.
Osric
