# 2gen Square-1 Solver (by ben1996123)



## qqwref (Aug 28, 2014)

God's number is 43 ignoring the middle layer, or 44 including the middle layer in turn metric (/ = 1 move, (x,0) = 1 move).

Ignoring middle layer:


Spoiler





```
depth   positions
0       1
1       8
2       10
3       39
4       40
5       142
6       144
7       460
8       426
9       1304
10      1186
11      3544
12      3375
13      9878
14      9769
15      29002
16      29573
17      88309
18      90465
19      271282
20      277449
21      827415
22      843048
23      2460655
24      2431730
25      6697884
26      6019635
27      14389848
28      10693709
29      21423501
30      15307424
31      30447214
32      21390049
33      32266820
34      14093340
35      12748845
36      4583014
37      5464277
38      2351079
39      1413334
40      148940
41      23142
42      290
43      1
```




Including middle layer:


Spoiler





```
depth   positions
0       1
1       8
2       10
3       40
4       50
5       184
6       227
7       584
8       700
9       1680
10      2017
11      4560
12      5670
13      12736
14      16000
15      37272
16      47451
17      112968
18      145182
19      346648
20      446528
21      1058968
22      1364842
23      3168264
24      4045811
25      8800688
26      10802822
27      19927400
28      22620870
29      31615032
30      34929938
31      44881008
32      49595709
33      54070720
34      50129617
35      28152160
36      21500086
37      10339048
38      8838395
39      4092704
40      2301502
41      218304
42      48159
43      624
44      13
```




Solver download link here

Input format: letters a-l and (if you are using the solver with the middle layer) a 1 to indicate that the middle layer is flipped. Solved state is abcdefghijkl





example: F perm + edge parity on D + middle layer flip: gfcdebahkjil1

When you run the solver it will generate a 457mb file if you ignore the middle layer, or 914mb if you include it, then ask for a position to solve. It will give you a list of all of the optimal solutions.

Some stuff I've found so far:
adjacent parity: 4/3/2/3/-3/-2/-4/-2/-3/-2/3/2/5/2/2/5/3/3/
adj-adj CP parity: /3/3/-2/-2/4/-4/-2/5/-3/
corner-edge swap: -2/-4/3/-5/-4/-2/-5/-4/2/4/-3/4/2/-4/-5/-2/-1/-5/-3
j perm: 1/3/5/3/1/4/-1/2/3/-2/1/4/-4/4/2/6/5/-3/-3
u perm: /3/1/4/5/6/2/4/1/2/-3/-1/-3/3/


----------



## Wilhelm (Aug 28, 2014)

This is really nice. I considered bandaging a Square-1 that I have laying around and now I might end up doing it cause I can solve it. I already tried to solve it but couldn't really find any algs and I had to stop at EO.


----------



## Lucas Garron (Aug 28, 2014)

qqwref said:


> Some stuff I've found so far:
> adjacent parity: 4/3/2/3/-3/-2/-4/-2/-3/-2/3/2/5/2/2/5/3/3/
> adj-adj CP parity: /3/3/-2/-2/4/-4/-2/5/-3/
> corner-edge swap: -2/-4/3/-5/-4/-2/-5/-4/2/4/-3/4/2/-4/-5/-2/-1/-5/-3
> ...



These are cool. I would have expected them to be quite longer.

Do you have any data on whether a typical position takes about the same number of U turns + D turns compared to a normal alg?


----------



## ~Adam~ (Aug 28, 2014)

I'm just glad Ben is banned again. He's clearly not a valuable member of this community.


----------



## ajayd (Aug 29, 2014)

Why doesn't he just make another account?


----------



## qqwref (Aug 29, 2014)

ajayd, he did that and it got banned too 

Here's the source code: http://pastebin.com/CLeCMZYQ


----------



## Forte (Aug 29, 2014)

This is awesome, contributing to the community like this is much appreciated


----------



## Stefan (Aug 29, 2014)

Yay, 2gen Square-1! I wrote one almost ten years ago as well and checked all possible swaps, this one was the shortest:
UFR<=>DBR: / 3 / -5 / -4 / 4 / 4 / -4 / 4 / 4 / -4 / 4 / -3 / -3 / (or backwards)
Ben's solver finds the same alg(s) for that case (it's abcdeflhijkg). Mine also found the same for qqwref's "adjacent parity". Looks like both solvers are correct 

Would be good to write the sum of the numbers as well (i.e., the total number of 30 degree U-turns), and sort the optimal algs for a case by this number.


----------



## qqwref (Aug 29, 2014)

Sorry, to be clear, that's not my parity, it's ben's  None of the work in this thread is mine.


----------



## Stefan (Aug 29, 2014)

Oh... I thought he had just written the solver. It's a bit confusing, wish he were back...

Compared my favorite case as well, the solvers again found the same alg(s):
DRF<=>DBR: /3/1/2/-4/4/-4/-4/4/-4/-4/-2/5/-3/ (or backwards)


----------



## Joey VOV (Aug 29, 2014)

hmmm, This could be pretty cool to use to find solutions and tricks to certain right block cases for roux/screw method, which I use.


----------



## Stefan (Aug 29, 2014)

I realized our solvers don't fully match, because I went the other direction on the D layer. So for example abcdelghijkf ("swapping f and l) is invalid for mine, while for yours it results in the shortest "swap" alg:
4/2/5/-2/-3/2/3/-3/4/-3/3/-1
Though I can't execute it, I get stuck at the 5. What's going on?


----------



## Stefan (Aug 29, 2014)

Another nice one, with few 30 degree U turns (best among the "real" swaps):
UFR<=>UBL: /3/1/2/2/-4/4/-4/2/4/2/-2/-4/2/-3/-3/


----------



## Stefan (Aug 29, 2014)

Hmm, that opposite corner parity is much shorter than the opposite edge parities. I wonder whether that's the case in general, and what the average move counts are for "CP, EP" vs "EP, CP". Has this been compared already? What do the top solvers do?


----------



## blade740 (Aug 29, 2014)

Stefan said:


> Hmm, that opposite corner parity is much shorter than the opposite edge parities. I wonder whether that's the case in general, and what the average move counts are for "CP, EP" vs "EP, CP". Has this been compared already? What do the top solvers do?



CP, EP is the generally accepted norm. However, I solve parity along with CP, partially to take advantage of the lower movecount algorithms.


----------



## Jimmy Liu (Aug 29, 2014)

This is interesting, though it's not very useful for speedsolving.


----------



## Stefan (Aug 29, 2014)

Jimmy Liu said:


> This is interesting, though it's not very useful for speedsolving.



Isn't or can't be?


----------



## qqwref (Aug 30, 2014)

Stefan said:


> I realized our solvers don't fully match, because I went the other direction on the D layer. So for example abcdelghijkf ("swapping f and l) is invalid for mine, while for yours it results in the shortest "swap" alg:
> 4/2/5/-2/-3/2/3/-3/4/-3/3/-1
> Though I can't execute it, I get stuck at the 5. What's going on?


Ben says that the reason it doesn't work is because the position isn't cubeshape. So you have to do the inverse to set it up.


----------

