unsolved
Veteran
Let's say you have a "TFS" database of depth 6. Let's say you are currently looking for a solution of length 14, having previously guaranteed no solution of length 13 exists. Then we know we don't have to check the TFS database until we've reached a depth of 8 moves from the scramble position. The TFS database will then tell us whether or not we can reach a solution of distance 14 from this search branch. But to be sure we haven't pruned away a good branch up to this point, we must have been making pruning decisions based upon a desired solution length of 14, not 8. This generally makes a big difference in how much pruning you can do.
Hmmmm. Yes, I see your point now. I was hoping that something along these lines would not crop up.
If we were doing pruning based upon a goal of 8 moves, we likely might find out right off that we're 9, 10, or 11 moves away from solved, and not have to generate any nodes at all. But this does not guarantee we're at least 15 moves from solved so we could be pruning away a good branch if we did this. Having the TFS database basically does us no good at all until we're out far enough from the scramble position to have a chance at hitting a database position.
And turning it on or off in certain situations is plenty tricky. I was having fits with the "collapsing the noose" implementation. This is when you find a TFS hit of distance N at depth D, then you find another line of distance N-1. Do you turn off the higher distance database right away? Or do you let the iteration finish out, and then turn it off? There could be interesting gold nuggets in there that are just one move longer. Or, as you have seen, you can get hundreds of solutions that are basically every permutation of a means to enter the database at the optimal distance.
In an aggressive mining mode, you can even turn off the optimal distance TFS, if you want to search for something only better than what you have just found, and you don't care for the (possibly hundreds) of solutions of equal length pouring out of the thing. The configuration possibilities require a great deal of thought.
I've been using the 5-TFS version to search for O-Perm solutions for about a day. I knew there existed a 13-move solution, so I knew it would not have to search deeper than that. The spoiler has my results so far.
Solution [252] = u2 l2 b2 D2 r2 D r2 D2 [inside 5-TFS] ---> f2 D' l2 b2 u2 @ 0085582952883 nodes with 1133755020714 5-TFS probes
DEPTHS 08-13 MOVE (06/36) u2 F' l2 B L U D f NODES: 0087879251587 DATABASE ACTIVITY: 000002544721722703 probes
That is a fair number of solutions! Now I really hope I purged the PV bug for good! (I am pretty sure I did, I rewrote like 300 lines of code yesterday.)
And now a little sneak peek at tomorrow's version:
I made a couple of changes, as you can see.
The first one is pretty apparent: I added color.
The second new feature is the ability to parse a 1-line text file to input a scramble, and the interface could not be easier.
Name the text file "scramble.txt" and just put your move sequence in there. Make sure it is in the same directory as the program.
Next, at the "enter scramble" prompt, just type the lower-case letter "i," and it will load it and start searching right away.
Trying the spoiler thingee to show how easy it is to get a pre-loaded entry into the program:
And... whenever a new "best line of play" outdoes any of the others, or if it is the first solution found, I have it appear in yellow.
And something you guys will probably hate me for now, but will like later once I do some leaf node pruning: I went ahead and implemented Iteration Jumping. It just seemed like a waste to rescan all of those positions constantly when they were already probed at prior iterations. If you have the 5-TFS loaded, it will jump in 2-ply increments. If you have 6-TFS, for now, I have it jump in 3-ply increments.
I may change it back if enough people start throwing stones my way.
Last edited:
