• 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] Kilominx Discussion Thread

xyzzy

Member
Joined
Dec 24, 2015
Messages
2,467
So I had a question: Is it possible to merge OLL and PLL into one phase and do it faster using this R' D' R D algorithm?
Sort of—that's pretty much the last step of the 8355 method. Roughly two-thirds of the time you'll be left with one twisted last-layer corner (and obviously also one more twisted corner elsewhere); when this happens, just rotate the whole puzzle and do the RDRD thing to fix the two twisted corners.

R' D' R D swaps the U-R-F corner with the DFR-F-R corner, but it also does a swap of two more corners on the back-right face. Furthermore, these swaps are "twisted": do it twice and you end up with the corners twisted, so you really need to do it a multiple of six times to fix the two back-right corners.

If we're only orienting the corners, we'll be doing R' D' R D twice for every corner that needs to twist anticlockwise and four times for every corner that needs to twist clockwise, so the total number is guaranteed to be a multiple of six. Likewise, if we're only permuting the corners, we'll be doing R' D' R D either 1+5 times or 5+1 times each time we transfer a corner piece from one location to another, so it's again forced to be a multiple of six.

However, if we're simultaneously orienting and permuting the corner pieces like in the 8355 method, this constraint no longer has a reason to hold. When we hit the last corner to solve and it ends up not being a multiple of six, there are two options: just solve it (this leaves three twisted corners total—but this only works on kilominx, not on megaminx, because the edges are messed up) or do R' D' R D a few more times to fix the back-right corners (this leaves two twisted corners total).
 

xyzzy

Member
Joined
Dec 24, 2015
Messages
2,467
If you downloaded kilosolver.js versions 0.5 or 0.6, upgrade to 0.7. (Same link.)

Why:
(i) Now uses Fisher-Yates shuffling instead of… whatever the heck I was doing before! (What this means: it's truly random-state now, as opposed to being very slightly biased. At least, insofar as you can assume the web browser's RNG is free from bias.)
I made a mistake by accidentally implementing Sattolo's algorithm instead. Sattolo's algorithm causes the corner permutation to always be a 20-cycle, except that the parity fix splits that into two cycles. This is now fixed, with a correct Fisher-Yates implementation. Practically, this had almost zero effect on scramble distribution modulo rotations, and I bet it was still better than 40-move Pochmann scrambles anyway.

Version 0.3 is not affected by this bug, and for some reason I never released version 0.4 so you couldn't possibly have that anyway. (Yes, yes, it's very ironic that the change to get rid of minuscule scramble bias actually made the scramble bias less minuscule.)

PS: This also affects the FTO random-state scrambler I wrote (and it's also fixed there), but I've already contacted Wes (who runs cubers.io) and Mike about that, which probably covers two-thirds of all the people regularly using it. (I don't know who runs Extra Events, and I don't know if it's used anywhere else.)
 

K2Cubing

Member
Joined
Feb 27, 2021
Messages
9
i don't know a very advanced method and it is very beginner. so when you are on you last layer you use an alg multiple times until you get the corners in there correct positions the twist them (by turning) like you do on the old beginner method on 3x3.

i need to lean a new one.
 
Top