The Batch Solver - Generate large algorithm sets automatically!

[OreKehStrah]

@trangium Any idea how you'd set up OL5C for SSC? I tried setting it up as (1) <R, D R D' R D R2 D'>R U D2 and (2) <U, R U R' U R U2 R'>R U D2. Gotten some weird results. Feel like I'm missing something but can't quite tell what it is. Thinking it has to do with the UBL corner.

What pieces need to be preserved and which don't? and is the L5CO the 4 U corners+DFR?

 

[OreKehStrah]

how can i do cube rotations? i know y is like U and D' at the same time, x is like R and L' at the same time and z is like F and B' at the same time. for each, i can copy the clockwise move (U, R and F) from the already written definiton, but i'm not sure how i would define the counter-clockwise move. can somebody explain?

Sure!

You can take the existing definition and combine them to make rotations. Keep in mind you have to also include slices. For the prime moves, take the definition of the move, then simply reverse the order of the pieces. If you look at the definition, you see that the order of the pieces in each bracket set is the order that the pieces move. So { UF UL UB UR } is how the edges cycle in U, so if you want U' you reverse it: { UF UR UB UL }.

I went ahead and created and tested y for you so you can see how to make the other two from the existing definitions. For the slices, leave the second half as it was written.

y is U + D' + E'

y: (UF UL UB UR) (UFR UFL UBL UBR) (DF DL DB DR) (DFR DFL DBL DBR) (FR+1 FL+1 BL+1 BR+1) (RL FB+1 RL+1)

If you need more help just let me know!

 

[Silky]

What pieces need to be preserved and which don't? and is the L5CO the 4 U corners+DFR?

Get a solved cube and preform R U D2. This is doing to be the set up for the alg. There is an 2 oriented E-Slice edges in FL BL and WV pair in UFL ( psuedo pair so any U/D corient oriented accordingly )and a psuedo triplet in LD. The psuedo-triplet has the DFR corner oriented counter clockwise and DBR clockwise ( again do the setup to see what it looks like ). Corner permutation doesn't matter nor non-E-slice edges. The alg will orient UBL UBR UFR DFR DBR such that it will be off a U/D R move. Think of it as a conjugated winter variation. Original OL5C algs here.

 

[trangium]

@trangium Any idea how you'd set up OL5C for SSC? I tried setting it up as (1) <R, D R D' R D R2 D'>R U D2 and (2) <U, R U R' U R U2 R'>R U D2. Gotten some weird results. Feel like I'm missing something but can't quite tell what it is. Thinking it has to do with the UBL corner.

Try R U D2 <R, U R U'>.

 

[Silky]

Try R U D2 <R, U R U'>.

Awesome, works. Could you explain how this works? What does putting something before <x,y,z> do vs putting it after <x,y,z> ?

 

[ruffleduck]

Awesome, works. Could you explain how this works? What does putting something before <x,y,z> do vs putting it after <x,y,z> ?

The moves are applied before the combinations from the generator <x,y,z>

Basic example:
U <R> would generate the 4 states reached by (U), (U R), (U R2), (U R')
<R> U would generate the 4 states reached by (U), (R U), (R2 U), (R' U)

 

[Melkor]

Awesome, works. Could you explain how this works? What does putting something before <x,y,z> do vs putting it after <x,y,z> ?

Moves placed before and after the generator are applied before and after, respectively, the generator moves for each case. So this example performs R U D2 before applying R, U R U', R U R U', R2 U R U' R', etc.

 

[mk8]

suggestion: generators (i mean <these>) inside generators. idk how complex this would be, but it would be really cool. sorry if this is too much of a requirement. this program is awesome btw

 

[OreKehStrah]

suggestion: generators (i mean <these>) inside generators. idk how complex this would be, but it would be really cool. sorry if this is too much of a requirement. this program is awesome btw

Just chain them. < set 1 > < set 2 > or is there something you found that this won’t work for?

 

[ruffleduck]

suggestion: generators (i mean <these>) inside generators. idk how complex this would be, but it would be really cool. sorry if this is too much of a requirement. this program is awesome btw

Nested generators can always be expanded with the same effect. <<x, y, z>, a, b, c> = <x, y, z, a, b, c>

 

[mk8]

Nested generators can always be expanded with the same effect. <<x, y, z>, a, b, c> = <x, y, z, a, b, c>

oh ok, but what if i wanted to do
<a, b <x, y, z> c, d>?
(note that there are no commas between b <x, y, z> c)
but havent thought about a workaround like this, so thanks a lot!

 

[mk8]

sorry for double posting, but this post has abslutely nothing to do with the old one

i would like to ask how orientation is defined for the batch solver? if i needed all the corners to point up/down with U/D color (but have them permuted randomly), would that just be
{UFR UFL UBR UBL ...}
or
1:UFR UFL UBR UBL ...
as the equivalence or something completely different?
(the corners dont need to be in their correct layers, just facing U/D with U/D color)

 

[IsThatA4x4]

sorry for double posting, but this post has abslutely nothing to do with the old one

i would like to ask how orientation is defined for the batch solver? if i needed all the corners to point up/down with U/D color (but have them permuted randomly), would that just be
{UFR UFL UBR UBL ...}
or
1:UFR UFL UBR UBL ...
as the equivalence or something completely different?
(the corners dont need to be in their correct layers, just facing U/D with U/D color)

If you wanted U/D to face U/D, then you would put every corner in the curly braces {}

1:{}= don't care about permutation or orientation
1: = don't care about orientation, do care about permutation

For your case you were correct, to have U/D corners facing U/D, you would use {UFR UFL UBR UBL DFR DFL DBL DBR}
If, say, you DID want them on the correct layers, you would use
{UFR UFL UBR UBL}
{DFR DFL DBR DBL}

 

[mk8]

why nested generators would be useful:
im making a guimond-style separation+permutaton of corners on both layers which preserves the E slice, so its basically <R2 U D> gen. however, when solving, at this point when the algset is applied, the E slice (and CO ofc) will already be solved, so i would like to filter out the algs that have the right side of the E slice flipped by 180°. however, i can't put R2 as the setup move since i need U, D as the setup moves. one way to do this would be with nested gens, e. g. <U, D, R2 <U, D> R2>, but that is not really possible as of now (or is it?). or is there a better way to do this?

EDIT: for now i did it by manually typing out all the combinations of R2 <U, D> R2 (luckily theres just a few of them) but for future situations, it would be nice to have something like this implemented. tysm

 

[kubesolver]

and another thing, this is pretty concrete but how could i make the a move from a generator be always executed an even number of times?
im making a guimond-style separation+permutaton of corners on both layers which preserves the E slice, so its basically <R2 U D> gen. however, when solving, at this point when the algset is applied, the E slice (and CO ofc) will already be solved, so i would like to filter out the algs that have the right side of the E slice flipped by 180°. however, i can't put R2 as the setup moves since i need U, D as the setup moves. one way to do this would be what i asked above, e. g. <U, D, R2 <U, D> R2>, but that is not really possible as of now (or is it?). or is there a better way

EDIT: for now i did it by manually typing out all the combinations of R2 <U, D> R2 (luckily theres just a few of them) but for future situations, it would be nice to have something like this implemented. tysm

"all the combination" There are only 2 combinations needed
R2 U R2 and R2 D R2

 

[mk8]

"all the combination" There are only 2 combinations needed
R2 U R2 and R2 D R2

thinking about it you're probably right, my brain is just too slow right now to evaluate it

EDIT: bruh ur right. still tho, there could be a situation (i dont think i can come up with one rn) where this nesting would be needed, or?
sorry i currently dont possess the ability to perform mind operations more complicated than mashing a keyboard (lol), feel free to tell me im a dumbass (but please explain why i do wanna learn)

 

[kubesolver]

> thinking about it you're probably right, my brain is just too slow right now to evaluate
it's fairly simple:
any R2 <U, D> R2 sequence can be decomposed like this:
R2 U' R2 = (R2 U R2)3 and R2 U D R2 = R2 U R2 R2 D R2

 

[mk8]

also sorry for posting in this thread so much, but as @IsThatA4x4 said, being able to adjust the table size would be nice (maybe a dropdown to choose to set the width or height and a number box for the value ig) and the visualisation option to show both top and bottom layers (like top view, but for both) would be cool. im genning an algset that permutes pieces in both layers (U and D) at once and having to regen it all twice to get both the top & bottom views takes reeeeally long

 

[trangium]

also sorry for posting in this thread so much, but as @IsThatA4x4 said, being able to adjust the table size would be nice (maybe a dropdown to choose to set the width or height and a number box for the value ig) and the visualisation option to show both top and bottom layers (like top view, but for both) would be cool. im genning an algset that permutes pieces in both layers (U and D) at once and having to regen it all twice to get both the top & bottom views takes reeeeally long

Workaround for now: To quickly generate images without waiting to generate algs again, set all the prune and search to 1, keeping everything else the same.

 

[mk8]

so i wanted to make a sort of a PBL step for the 3x3, where CO is done and the E slice needs to be preserved. this is what i put as the scramble:

<U, D,
R U R' F' R U R' U' R' F R2 U' R', --J perm
R' U R' F' R U R' U' R' F R2 U' R' U R2, --J perm on D
F R U' R' U' R U R' F' R U R' U' R' F R F', --Y perm
L2 R2 F R U' R' U' R U R' F' R U R' U' R' F R F' R2 L2 --Y perm on D
>

there should be only 8 cases, but the program somehow got 172. i didnt check them all out sice i didnt want to run it for this long. what could the problem be? (M and S slice edges are equivalent and dont need to be oriented. CO is done and every corner is in the correct layer. E slice is done. at the end of the alg all pieces except the M and S slice should be solved)

EDIT: oh and the algs are <R, U, D, F> gen, prune is 4 and search is 8, pre- and post- adjust are both <U, D>