# ksolve+ v1.0 - general-purpose algorithm finder

#### mark49152

##### Super Moderator
Staff member
ad windows version: Have you tried downloading the zip (containing an exe) from qqref's original post. This version works fine on my laptop (Win 7).
Thanks for the help. I think that and the github .exe are the same version, as the byte count is identical. Anyway, I found the problem - the advice to not include blank lines at the end means don't append a return to the final "End" either. I should have caught that earlier, must have been half asleep.

Also the 3x3x3.def file on both github and qqwref's site isn't Windows-friendly and needs CRs added before it will work.

ad F2L-Solver: In the scramble you have to ignore the last layer pieces with a ?. E.G. if your scramble is 1 3 7 9 2 6 ... and you want to ignore the last layer, write ? ? 7 9 ? 6 ... In the definition file you're only specifying the pieces, which may be ignored. To really ignore them, write ?s.
Yeah I should have read the whole thread, and the (excellent) readme.txt in more detail However, I still can't get it working. When the pieces are replaced with '?' it fails to find any solution, even U R U' R'. If I include hints then it does find some solutions, but not all of them - only those that also leave solved pieces at URF/UR where the F2L pair started. See below for scramble file and output.

Scramble file:-
Code:
Scramble Piece configuration as reported by ScrambleAlg R U R' U'
CORNERS
5 2 4 3 1 6 7 8
2 0 0 2 2 0 0 0
EDGES
1 2 4 5 3 6 7 8 9 10 11 12
0 0 0 1 1 0 0 0 0 0 0 0
End

Scramble U layer pieces replaced with ?
CORNERS
5 ? ? ? ? 6 7 8
2 ? ? ? ? 0 0 0
EDGES
? ? ? 5 ? 6 7 8 9 10 11 12
? ? ? 1 ? 0 0 0 0 0 0 0
End

Scramble U layer pieces with ? prepended
CORNERS
5 ?2 ?4 ?3 ?1 6 7 8
2 ?0 ?0 ?2 ?2 0 0 0
EDGES
?1 ?2 ?4 5 ?3 6 7 8 9 10 11 12
?0 ?0 ?0 1 ?1 0 0 0 0 0 0 0
End
And the output:-
Code:
Solving "Piece configuration as reported by ScrambleAlg R U R' U'"
Depth 0
Depth 1
Depth 2
Depth 3
Depth 4
U R U' R'
Depth 5
Depth 6
Depth 7
Depth 8
U F' U2 L' U' L F U2
R2 B' D' R D R2 B R'

Max depth reached, aborting.

Solving "U layer pieces replaced with ?"
Depth 0
Depth 1
Depth 2
Depth 3
Depth 4
Depth 5
Depth 6
Depth 7
Depth 8

Max depth reached, aborting.

Solving "U layer pieces with ? prepended"
Depth 0
Depth 1
Depth 2
Depth 3
Depth 4
U R U' R'
Depth 5
Depth 6
L' U R U' L R'
Depth 7
U F' L' U' L F U
Depth 8
U F' U L' U2 L U F
U F' U2 F R U' R' U'
U F' U2 L' U' L F U2
U B' R U' R2 U R B
U B' R U' R' U B U'
R2 B' D' R D R2 B R'

Max depth reached, aborting.

#### qqwref

##### Member
I'm not completely sure, but I think you want to do it like this:
Code:
Scramble U layer pieces with ? prepended
CORNERS
?5 ?2 ?4 ?3 1 6 7 8
?2 ?0 ?0 ?2 2 0 0 0
EDGES
?1 ?2 ?4 ?5 3 6 7 8 9 10 11 12
?0 ?0 ?0 ?1 1 0 0 0 0 0 0 0
End

#### mark49152

##### Super Moderator
Staff member
I'm not completely sure, but I think you want to do it like this:
Yeah, that works, great, thanks! So the ?s apply to the positions not the cubies initially in them. Doesn't that mean only the hint notation will work? I have to tell it where the F2L pair pieces are although they occupy positions that will be ignored.

Is this the best way to implement an F2L solver? Looking at the 3-colour cube (with repeating piece types) I'm wondering if it would be more efficient to change the def file to have 4 identical corners and 4 identical edges in the U layer. However, could I ignore orientations of those pieces without having to still include the ?s in the scrambles?

#### Robert-Y

##### Member
I think you could go further than that and define a 3x3x3 in such a way so that it allows 4 (wanted) solved states.

1. Let the bottom (D) edges be the same
2. Let the bottom (D) corners be the same
3. Let the middle (E slice) edges be the same
4. Omit centres in the definition.

Example:

# CORNERS URF, ULF, ULB, URB, DRF, DLF, DLB, DRB
# EDGES UF UL UB UR FR FL BL BR DF DL DB DR

Set CORNERS 8 3
Set EDGES 12 2

Solved
CORNERS
1 1 1 1 2 2 2 2
EDGES
1 1 1 1 2 2 2 2 3 3 3 3
End

<Define moves>

Ignore
CORNERS
1 1 1 1 0 0 0 0
1 1 1 1 0 0 0 0
EDGES
1 1 1 1 0 0 0 0 0 0 0 0
1 1 1 1 0 0 0 0 0 0 0 0
End

Obviously I haven't defined any moves but if you define the solved state in this way, then solutions containing y,y',y2 will work without the need of "undoing" the rotation from the algorithm.

Also there are "dangers" with this. Perhaps this is not recommended for multislotting cases but hopefully valid yet unwanted algorithms are rare and use more moves...

#### mark49152

##### Super Moderator
Staff member
I think you could go further than that and define a 3x3x3 in such a way so that it allows 4 (wanted) solved states.

1. Let the bottom (D) edges be the same
2. Let the bottom (D) corners be the same
3. Let the middle (E slice) edges be the same
I haven't tried it yet, but wouldn't that allow pieces in each group to be interchanged? I would expect solutions to preserve the rest of F2L. Also, how would I identify the pieces of the pair I want to solve?

Last edited:

#### Robert-Y

##### Member
Yes you are right, this is what I was talking about when I mentioned the "dangers" of defining such a solved state. But if you only have one more pair to solve, then I would imagine that it wouldn't be much of a problem. As for your second question, you would just set up the case as you normally would? I don't see any issues there...

#### mark49152

##### Super Moderator
Staff member
As for your second question, you would just set up the case as you normally would? I don't see any issues there...
In the scramble I would need to specifically identify the pieces of the pair to be solved. So the sets would have to be something like:-

Solved
CORNERS
1 1 1 1 3 2 2 2
EDGES
1 1 1 1 4 2 2 2 3 3 3 3
End

This is great software and I'm anticipating hours of fun messing around with it, so many thanks to qqwref and all the contributors!

I'm not keen on the "ignore" feature though. Given that the question marks denote ignored positions rather than ignored pieces, it means that in the scramble I have to identify pieces which will eventually end up in ignored positions - for example, the corner and edge initially in my target F2L slot. That seems redundant. Also, although the format "?5" is described by the readme as a "hint", it's not. It appears to signify that piece 5 is initially in this position, but we don't care what ends up in this position when solved.

This is based on the assumption that the sets are a sequence of positions giving the numbers of the held pieces, rather than a sequence of pieces giving the number of their positions. I'm not 100% sure that assumption is correct because the readme states that "the 2 in the first spot means that piece number 1 is in [position] 2". However, in practice it appears to be the other way around, so "the 2 in the first spot means that position 1 holds piece number 2". This is evident from the scramble generated for R U R' U' where the edges are cycled such that piece UR is in position UB - note that in the scramble, position 3 (UB) holds piece 4 (UR), not vice-versa.

# EDGES UF UL UB UR FR FL BL BR DF DL DB DR
...
EDGES
1 2 4 5 3 6 7 8 9 10 11 12

A simpler way to present the "ignore" feature would be to always ignore the pieces/positions as configured in the defs file, and use ? in the scramble to indicate where the ignored pieces are initially.

#### Robert-Y

##### Member
In the scramble I would need to specifically identify the pieces of the pair to be solved. So the sets would have to be something like:-

Solved
CORNERS
1 1 1 1 3 2 2 2
EDGES
1 1 1 1 4 2 2 2 3 3 3 3
End
No you don't?... Like I said before as long you are only solving one pair and all of the other pairs are solved then most of the solutions that are found should work. I'm aware that this can go wrong but I can't see it going completely wrong in this case? I doubt you would have to keep trying many algs until you get one that works.

EDIT: No harm in trying it out. In fact I don't mind trying it out if you have any requests in mind.

Last edited:

#### mark49152

##### Super Moderator
Staff member
No you don't?
Yes I see what you mean now. That's a neat idea, although I'm not sure what the advantage would be compared to not making the F2L pieces interchangeable. There would have to be a very clear performance advantage to make it worth weeding out all the wrong solutions. Anyhow, I am including multi-slotting cases so it wouldn't work for me.

I do now have ksolve working nicely, solving a big list of cases generated using Perl.

Is there a way to request larger pruning tables, without rebuilding? It's fast up to depth 9, just a minute or two for depth 10, then depth 11 takes ages. Ideally I wanted to search up to 13 but that looks like a non-starter for ~300 cases with my PC resources.

#### unsolved

##### Member
4x4x4 version of ksolve?

Does anyone have a pre-built settings file for the 4x4x4 Revenge cube?

#### unsolved

##### Member
Here's a def file for 4x4x4 centers. http://mzrg.com/rubik/ksolve+/ You can merge it with one of the 3x3x3 corner files, then you only have to write the edge part.
That sounds like too much work for me. I'll just write my own 4x4x4 solver program. Oh, wait, I already did that, so how about I trade you a free copy of the latest version of it for a ready-to-go version of ksolve so I can compare solving times?

#### Ross The Boss

##### Member
Issues Using Ksolve

Yes, I thought that I had finally figured out this app, but now I am not so sure. The cube I'm attempting to define is a 3x3x3 which can only have RrFUM turns applied to it, and the unsolved state for which solutions are to be generated is an F1 CMLL(T, no swaps) with the UF and UB edges flipped. Since I'm trying to generate Roux algorithms, edge permutation can be ignored; the orientation is all that matters.
So I wrote these two things into a .def and a .txt file and they all seem to check out nicely... except for the fact that it takes forever to get nothing done. I left my computer running over night -a relatively good computer, mind you- and upon checking in the morning it had only searched down to a depth of 14, yielding no results. I can tell that this is a load of BS as my two other algs for this case are only 13 moves in length. WHAT AM I DOING WRONG D:?????

Name 3X3X3_RUFM

# CORNERS URF ULF ULB URB DRF DLF DRB
# EDGES UF UL UB UR FR FL BL BR DF DL DB DR

Set CORNERS 7 3
Set EDGES 12 2

Solved
CORNERS
1 2 3 4 5 6 7
EDGES
1 2 3 4 5 6 7 8 9 10 11 12
End

Move M
CORNERS
1 2 3 4 5 6 7
EDGES
3 2 11 4 5 6 7 8 1 10 9 12
End

Move U
CORNERS
4 1 2 3 5 6 7
EDGES
4 1 2 3 5 6 7 8 9 10 11 12
End

Move R
CORNERS
5 2 3 1 7 6 4
1 0 0 2 2 0 1
EDGES
1 2 3 5 9 6 4 8 7 10 11 12
0 0 0 1 1 0 1 0 1 0 0 0
End

Move r
CORNERS
5 2 3 1 7 6 4
1 0 0 2 2 0 1
EDGES
9 2 1 5 12 6 7 4 11 10 3 8
1 0 1 1 1 0 0 1 1 0 1 1
End

Move F
CORNERS
2 6 3 4 1 5 7
2 1 0 0 1 2 0
EDGES
6 2 3 4 1 8 7 5 9 10 11 12
End

Ignore
EDGES
1 1 1 1 0 0 0 0 1 0 1 0
1 1 1 1 0 0 0 0 1 0 1 0
End

Slack 3
Scramble UF+UB
CORNERS
1 2 3 4 5 6 7
0 0 2 1 0 0 0
EDGES
? ? ? ? 5 6 7 8 ? 10 ? 12
1 0 1 0 0 0 0 0 0 0 0 0
End

As you see , no definition for the center pieces have been given. This is because I do not want my results limited to algs that will preserve yellow on bottom or any of that Roux-irrelevant stuff. This ofcourse leaves me open to results where all edges are oriented relative to U/D corners, but the center pieces are off by an M. Robert Yau, i think it was, said that this could be dealt with by defining the solved state of the centers as "1 2 1 2", but this did not work for me. Any suggestions?

Last edited:

#### mark49152

##### Super Moderator
Staff member
In my experience, using IGNORE slows down ksolve tremendously, so ignore as few pieces as possible.

#### Ross The Boss

##### Member
In my experience, using IGNORE slows down ksolve tremendously, so ignore as few pieces as possible.
ahh, that's unfortunate. Is there any way that i could make M/U edge permutation irrelevant without using the Ignore command? Like some solve state trickery maybe?

#### kcl

##### Member
ahh, that's unfortunate. Is there any way that i could make M/U edge permutation irrelevant without using the Ignore command? Like some solve state trickery maybe?
You could maybe define them as permuted? Just always do 1 2 3 4 5 6 7 8 9 10 11 12 for permutation and define orientation as normal.

#### Ross The Boss

##### Member
You could maybe define them as permuted? Just always do 1 2 3 4 5 6 7 8 9 10 11 12 for permutation and define orientation as normal.
define them as permuted where? the solve state command? but then wont ksolve only generate solutions that solve the cube fully? that would defeat the purpose of generating roux optimal algs.

#### Robert-Y

##### Member
Many things need correcting

1. You need to give an edge orientation vector for the moves M and F.
2. UF=UB=UR=UL=DF=DB right? So you probably want the solved state for edges to be something like:

1 1 1 1 5 6 7 8 1 10 1 12

or

1 1 1 1 2 3 4 5 1 6 1 7 (whichever seems more sensible)

3. The length of scramble orientation and permutation vectors need to match the solved state. I think maybe you know this, but you just provided the wrong scramble file?