[Help Thread] Kilominx Discussion Thread

[xyzzy]

Any chance of Kilominx ZBLL? Assuming I'm not missing anything, it should just be 48 algs, right?

EDIT: I feel like I must be missing something. According to Ranzha on the Kilominx petition thread, it has 1944 LL states. I think I sort of get why in my head, but the jump from seemingly 48 to nearly 2000 doesn't quite make sense to me. Any chance anyone could explain?

Kilominx CLL has 972 states (half of 1944; I think Ranzha didn't account for parity), but if you account for rotational/AUF symmetry, this drops to 196 cases. (Large, but not unreasonable?) You can't just multiply the number of OLL cases with the number of PLL cases because they might have different AUFs.

 

[DGCubes]

Kilominx CLL has 972 states (half of 1944; I think Ranzha didn't account for parity), but if you account for rotational/AUF symmetry, this drops to 196 cases. (Large, but not unreasonable?) You can't just multiply the number of OLL cases with the number of PLL cases because they might have different AUFs.

Ah, that makes sense. 196 cases really isn't too bad, although it is still a decent amount to learn. A good way to start might be to figure out the most common OLL cases, and then learn the CLL algs corresponding to them.

Also, I wrote a quick random-move scrambler in Java. It accounts for moves not being the same as previous moves (e.g. nothing like "B B2' B2" would ever show up), and it allows you to choose how many moves you want the scramble to be. I set the default as 40, but in the Main class I gave an example of how you could set it to anything else. Here's the code:

EDIT: It doesn't yet account for things like "F B F", but I'll re-edit this post once I fix it.

Spoiler: Scramble class

import java.util.ArrayList;

public class Scramble {
    private String [] moves = {"U","F","L","R","bL","bR","dL","dR","dbL","dbR","B","D"};
    private String [] modifiers = {"","\'","2","2\'"};
    private int movecount;
    private ArrayList <String> scramble = new ArrayList <String> ();
 
    public Scramble () {
        this(40);
    }
 
    public Scramble (int movecount) {
        this.movecount = movecount;
        doScramble();
    }
 
    private void doScramble () {     
        for (int i=0; i < movecount; i++) {
            int movesIndex = (int) (Math.random() * moves.length);
         
            while (i > 0 && scramble.get(i - 1).equals(moves[movesIndex])) {
                movesIndex = (int) (Math.random() * moves.length);
            }
         
            scramble.add(moves[movesIndex]);
        }
     
        for (int i=0; i < movecount; i++) {
            int modifiersIndex = (int) (Math.random() * modifiers.length);
         
            String temp = scramble.get(i);
            temp += modifiers[modifiersIndex];
            scramble.set(i,temp);
        }
    }
 
    public String toString () {
        String returnValue = "";
     
        for (int i=0; i < scramble.size(); i++) {
            returnValue += (scramble.get(i) + " ");
        }
     
        return returnValue;
    }
}

Spoiler: Main class

public class Main {
    public static void main (String [] args) {
        Scramble s = new Scramble();
        System.out.println(s);
     
        Scramble s1 = new Scramble(50);
        System.out.println(s1);
    }
}

I also really like Kit's idea from the Kilominx petition thread:

...Maybe having scrambling phases with 2-3 rotations in the middle, only turning on parts of the puzzle in each phase?...

Perhaps we could have 15 or so moves only affecting the top 6 sides, then do the equivalent of a 3x3 z2 (although this rotation would need to be specifically defined in the regs; a "z2"-type move on Megaminx would also require adjusting it on the y-axis slightly, because otherwise either one of two faces could be considered the front). After that, we could do another ~15 moves only affecting the other 6 sides. It might be necessary to do more than just those moves though; I can't really say how much would be necessary for a random move scramble.

 

[Chree]

... scramble, scramble, scramble...

Though I appreciate the effort, I don't see why we'd need Random Move scramblers using all 12 faces. Scrambling with all 12 sides is a pain on Megaminx, and accuracy was a huge problem... I doubt it'll be any easier on Kilominx.

When I ask people how they're scrambling, most people I know are just using regular WCA Megaminx scramblers, including Kit:
- I've been using 4 lines. Because I'm lazy, and I almost never see blocks after anyway.
- Walker was using 5, last I checked (weeks ago).
- And Kit "Mr. Thorough-Pants" Clement was using 7.

Of course, we're only using Mega scramblers based on the assumption that it's "just as random" on Kilo as it is on Mega. We don't actually have any good reason to believe that. But for now, it gets the job done in a much more ergonomic way than 12-sided scrambling.

I don't know if you hope to get this deep into it... but I'd say put your effort into a random state scrambler.

 

[JustinTimeCuber]

var m=function(){return ["++ ","-- "][Math.floor(2*Math.random())];};var k=function(x){if(x===0){return "";}else{return "R"+m()+"D"+m()+"R"+m()+"D"+m()+"R"+m()+"D"+m()+"R"+m()+"D"+m()+"R"+m()+"D"+m()+["U\n","U'\n"][Math.floor(2*Math.random())]+k(x-1)}};var z=k(5);z.substr(0,z.length-1)

Megaminx-style scrambler
I have no idea how to make a random state one

 

[Robert-Y]

@CLL: Recognition though...

I reckon you need to know our colour scheme really well before your recognition becomes any "good". But having said that, I can't say I've tried to recognise a CLL case before; especially not cases involving 4 or 5 unsolved corners.

 

[Chree]

@CLL: Recognition though...

I reckon you need to know our colour scheme really well before your recognition becomes any "good". But having said that, I can't say I've tried to recognise a CLL case before; especially not cases involving 4 or 5 unsolved corners.

Starting with the 'Solved' and 'E-Perm' sets might not be that bad, since they have rotational symmetry... recognition would still be just.... just awful.

 

[Cale S]

How many OLL cases can you reduce it to by influencing CO by choosing from R U' R', R' F R F', R U2' R', R U2 R', and mirrors for last slot?

 

[Kit Clement]

So in the interest of determining what lengths of Kilo scrambles generated by <U, R, L, BL, BR, x2> would be, I've created a ksolve file. I can't get it to make pruning tables, and I'm not really sure what I'm doing/where my error is. If anyone's better with ksolve than myself, I'd appreciate someone taking a look at this.

Name Kilominx Scrambling (Top + x2 rotation)

Set CORNERS 20 3

Solved 
CORNERS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
End

Move U
CORNERS
2 3 4 5 1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
End

Move R
CORNERS
1 2 3 12 4 6 7 8 9 10 11 13 14 5 15 16 17 18 19 20
0 0 0 1 2 0 0 0 0 0 0 2 0 1 0 0 0 0 0 0 
End

Move F
CORNERS
1 2 10 3 5 6 7 8 9 11 12 4 13 14 15 16 17 18 19 20
0 0 1 2 0 0 0 0 0 2 0 1 0 0 0 0 0 0 0 0 
End

Move L
CORNERS
1 8 2 4 5 6 7 9 10 3 11 12 13 14 15 16 17 18 19 20
0 1 2 0 0 0 0 2 0 1 0 0 0 0 0 0 0 0 0 0
End

Move BL
CORNERS
6 1 3 4 5 7 8 2 9 10 11 12 13 14 15 16 17 18 19 20
1 2 0 0 0 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0
End

Move BR 
CORNERS
5 2 3 4 14 1 7 8 9 10 11 12 13 15 6 16 17 18 19 20
2 0 0 0 1 1 0 0 0 0 0 0 0 2 0 0 0 0 0 0 
End

Move x2
CORNERS
16 17 18 19 20 11 10 9 8 7 6 15 14 13 12 1 2 3 4 5
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
End

Map of pieces:


(16-20 are where 1-5 are after doing an x2)

 

[Robert-Y]

Well let's say you can always get one corner to be oriented correctly. This cut off 24 CLL cases I think (i.e. every case with 5 corners unoriented is avoided).It's not a big percentage cut. But what if somehow you could get 2 corners oriented correctly? I think this cuts off a further 72 cases which brings the total down to 196 - (24+72) = 100... (including the solved case)

 

[DGCubes]

Well let's say you can always get one corner to be oriented correctly. This cut off 24 CLL cases I think (i.e. every case with 5 corners unoriented is avoided).It's not a big percentage cut. But what if somehow you could get 2 corners oriented correctly? I think this cuts off a further 72 cases which brings the total down to 196 - (24+72) = 100... (including the solved case)

Doesn't seem like that would be too hard. Perhaps sune/antisune followed by CLL? I haven't learned the 5-corner OLLs yet, so I tend to do that for OLL anyway. Recognition wouldn't really be too bad considering at least one of the oriented corners could be permuted with an AUF, so you really only need to recognize 4 corners.

Another method to getting 2 corners oriented is to just mess around with last slot. It's pretty intuitive to just throw a couple extra moves in there to orient some corners. Plus it saves an alg, which is nice.

 

[wir3sandfir3s]

Can't wait till I get a kilo minx...
anyway, here's a theoretical LL method based of an old megaminx method recently brought to light (by effetah, I think?)
1. Solve till "LS"+LL
2. Something similar to the heise 2 pairs approach, except 4 corners are left unsolved. Solve with an alg/comm.
I think solving till 3 corners may be better because you can use a comm, but I think recog for that would suck. Solving until 4 corners and using an alg is probably faster.

 

[Cale S]

WV algs are really nice

0 unoriented:
(U) F' U' F U R U2' R'

1 unoriented:
(U) R U' R'
(U) F' U F R U' R'
R' U' R U R U' R' U' R' U R
(U) F' U2' F U R U2' R'
(U2') R' U2' R2 U' R2' U2' R
(U) R U R' U' R U' R'
(U') R U' R' U' R U2 R' or Br' R' F R F' Br
(U2) R U' R' U2 R U2 R' or (U2) y' R2' F R F' R

2 unoriented has 24 cases

 

[wir3sandfir3s]

WV algs are really nice

0 unoriented:
(U) F' U' F U R U2' R'

1 unoriented:
(U) R U' R'
(U) F' U F R U' R'
(U) R U' R' U2 R U2 R' U' R U' R' (pls help there must be something better)
(U) F' U2' F U R U2' R'
(U2') R' U2' R2 U' R2' U2' R
(U) R U R' U' R U' R'
(U') R U' R' U' R U2 R' or Br' R' F R F' Br
(U2) R U' R' U2 R U2 R' or (U2) y' R2' F R F' R

2 unoriented has 24 cases

WV? kms
Why wv sucks especially for kilominx:
Your literally putting the cube/minx/whatever into a position where you can insert it in three moves, but feel it is then unnecessary to do a .01 second insert+a super quick alg which great recog and very few cases, and instead proceed to do an alg the same size as the insert+alg, or sometimes even form pair+insert+alg which worse recog and several more cases.
Like, wtf

 

[Cale S]

WV? kms
Why wv sucks especially for kilominx:
Your literally putting the cube/minx/whatever into a position where you can insert it in three moves, but feel it is then unnecessary to do a .01 second insert+a super quick alg which great recog and very few cases, and instead proceed to do an alg the same size as the insert+alg, or sometimes even form pair+insert+alg which worse recog and several more cases.
Like, wtf

it's probably only worth it to use the 0-1 unoriented and the really easy 2 corner cases (like sledge), because they are almost instant to recognize and are at most 7 moves

 

[wir3sandfir3s]

it's probably only worth it to use the 0-1 unoriented and the really easy 2 corner cases (like sledge), because they are almost instant to recognize and are at most 7 moves

Not even because then you have to stop and figure out if it's the case or not before proceeding to insertion, adding an unnecessary look.

 

[JustinTimeCuber]

So in the interest of determining what lengths of Kilo scrambles generated by <U, R, L, BL, BR, x2> would be, I've created a ksolve file. I can't get it to make pruning tables, and I'm not really sure what I'm doing/where my error is. If anyone's better with ksolve than myself, I'd appreciate someone taking a look at this.

Name Kilominx Scrambling (Top + x2 rotation)

Set CORNERS 20 3

Solved 
CORNERS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
End

Move U
CORNERS
2 3 4 5 1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
End

Move R
CORNERS
1 2 3 12 4 6 7 8 9 10 11 13 14 5 15 16 17 18 19 20
0 0 0 1 2 0 0 0 0 0 0 2 0 1 0 0 0 0 0 0 
End

Move F
CORNERS
1 2 10 3 5 6 7 8 9 11 12 4 13 14 15 16 17 18 19 20
0 0 1 2 0 0 0 0 0 2 0 1 0 0 0 0 0 0 0 0 
End

Move L
CORNERS
1 8 2 4 5 6 7 9 10 3 11 12 13 14 15 16 17 18 19 20
0 1 2 0 0 0 0 2 0 1 0 0 0 0 0 0 0 0 0 0
End

Move BL
CORNERS
6 1 3 4 5 7 8 2 9 10 11 12 13 14 15 16 17 18 19 20
1 2 0 0 0 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0
End

Move BR 
CORNERS
5 2 3 4 14 1 7 8 9 10 11 12 13 15 6 16 17 18 19 20
2 0 0 0 1 1 0 0 0 0 0 0 0 2 0 0 0 0 0 0 
End

Move x2
CORNERS
16 17 18 19 20 11 10 9 8 7 6 15 14 13 12 1 2 3 4 5
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
End

Map of pieces:

View attachment 6575
(16-20 are where 1-5 are after doing an x2)

Can someone explain how CO is determined on kilo?

Sent from my MotoE2(4G-LTE) using Tapatalk

 

[h2f]

I think kilominx needs clear notation with one letter for a side. My first thought: E (east) and W (west) instead of BR and BL and small letters for down side. Or just: L, F, R, N, B. Or whatever. It's just an idea. But good notation is a basis.

 

[Kit Clement]

Yeah, I'm less concerned about what the notation actually is at this point, and just want to see a proof of concept for doing hemisphere notation with x2. With Kilo, it's clear that any scramble could be done with this idea with at most 2 x2s, but how long would scrambles need to be? Is there an advantage for allowing a 3rd, maybe a 4th in terms of length? That's what I wanted to see by getting a working .def file.

I have no idea how the EO works though, I mimicked the turn definitions done for the template Mega UFR given by ksolve, but I don't know if that makes sense when you have six sides rather than just 3.

 

[xyzzy]

I just finished writing a rudimentary kilominx solver. The "x2" rotations are denoted as "flip" instead of "x2" because x rotations already mean something else, but that can be easily changed. (It's possibly buggy and definitely slow; your mileage may vary.)

>>> print_move_sequence(solve(random_state()))
"F2 flip R2 BR2' U F2' U2 BR' R2 BR2 flip F2' BL2' BR' U' BR' BL2 L2 U F U2' R U' R2' F2' U R2 F2' U' R2 U'"
>>> print_move_sequence(solve(random_state()))
"F2' R2 BL U2 L' BL' BR flip U' F' BL2 U2' BR2' R2' F2' L2 U R F R' U2 F U' R' F2' R2' U2'"
>>> print_move_sequence(solve(random_state()))
"R flip U R' BR2 BL2 BR2' BL2 BR' flip U' R2 BL2 U2 L2 BL2 BR BL' F U2 R' U' F2' R2 U2 R' F R2 F2 R2'"
>>> print_move_sequence(solve(random_state()))
"U R F2' L' U2' R2 L' flip U R2' BR' U2 BL' BR U F2 L2' U2' R2 U F2' R2 U' F2' R2 U2' F2' U' R2"

 

[Hssandwich]

E perm: R U' R U R U R' U' R' U' R' U2 R'

ksolve ftw as usual

EDIT: It seems to work on 3x3x3. It's a U perm

Just found that the inverse is also very good
R U2' R U R U R U' R' U' R' U R'