Search

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.

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.

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?

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?

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...

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.

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.

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.

Super Moderator

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.

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?

Member

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:?????

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?

About Speedsolving.com

SpeedSolving.com is a community focused on speed-solving puzzles, particularly the Rubik’s cube and alike. Created in 2006, the speedcubing community has grown from just a few to over 35,000 people that make up the community today. Competitions and unofficial meetups are organized all over the world on a weekly basis. The forum now has well over 1,200,000 posts and growing.