Request Support for Multiple Solved States

[DougCube]

This is probably a huge ask, but for my use case, I would very much like a mode of operation where for the "same puzzle" (same set of pieces and same moves), I can define multiple "solved states" with different subsets of what are considered identical pieces.

Let me elaborate. Currently, what I'm doing is writting multiple definition files and executing multiple runs with the same ScrambleAlg then finding the best solution among them with post-processing of the results.

I'll give a concrete example. For 3x3, I can define 6 solved states for color-neutral Cross (solves all 4 edges around a center piece), one on each of the 6 faces. I have to run the program 6 times, gather and parse the solutions, then output the shortest solutions among them. I do have a way to automate this now, but the runtimes are rather long. When I profile the performance of it, there is tremendous overhead in I/O operations. If this mode of operation was to be natively supported in the tool, then I can reduce the multiple program calls to just one and greatly improve the performance -- presumably there are optimizations in the tool to leverage the puzzle being the same.

In this toy example, it's only 6 calls, but in practice, I am running usages with hundreds or even thousands of calls.

[rokicki]

Consider using --nowrite and manually deleting the pruning table for cases like this. Also you should try much smaller memory sizes. But yes I see what you want. The first step would likely be just to support multiple solved states (as when final orientation of the puzzle doesn’t matter). For the case you want though the mathematics would be different so I’d have to think about how that would work. - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -

…

On Wed, Dec 11, 2024 at 11:15 AM DougCube ***@***.***> wrote: This is probably a huge ask, but for my use case, I would very much like a mode of operation where for the "same puzzle" (same set of pieces and same moves), I can define multiple "solved states" with different subsets of what are considered identical pieces. Let me elaborate. Currently, what I'm doing is writting multiple definition files and executing multiple runs with the same ScrambleAlg then finding the best solution among them with post-processing of the results. I'll give a concrete example. For 3x3, I can define 6 solved states for color-neutral Cross (solves all 4 edges around a center piece), one on each of the 6 faces. I have to run the program 6 times, gather and parse the solutions, then output the shortest solutions among them. I do have a way to automate this now, but the runtimes are rather long. When I profile the performance of it, there is tremendous overhead in I/O operations. If this mode of operation was to be natively supported in the tool, then I can reduce the multiple program calls to just one and greatly improve the performance -- presumably there are optimizations in the tool to leverage the puzzle being the same. In this toy example, it's only 6 calls, but in practice, I am running usages with hundreds or even thousands of calls. — Reply to this email directly, view it on GitHub <#69>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOLS6MTHZNFZVAZQAZBR32FCFO5AVCNFSM6AAAAABTOFWPK6VHI2DSMVQWIX3LMV43ASLTON2WKOZSG4ZTGNZXG43TGMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[DougCube]

A few days ago, I accidentally stumbled on using smaller memory size causing a dramatic speedup. But not sure what the optimal memory size is for each puzzle. Not sure what you mean be "manually delete pruning tables" tho.

An initial step, just running multiple times in a loop for each solved state, where the puzzle is only loaded once and having a way to define multiple solved states in the same definition file, then post-processing the solutions, would speed things up a bit for my use case. But I guess for other use cases, might be a good idea to support two modes: one where it spits out solutions for each solved state and one where it rolls it up for you. Another problem is how to denote which solved state is achieved by each solution line.

[DougCube]

How do I delete the pruning tables?

[DougCube]

Nvm, I figured it out. It was in ~/.cache/twsearch/

[rokicki]

Sorry for not responding earlier! Yeah, twsearch normally reports the filenames of the pruning tables it reads and writes. They used to be in the current working directory, but since I've adopted a common convention for where to put cache files.

…

On Tue, Dec 17, 2024 at 4:50 AM DougCube ***@***.***> wrote: Nvm, I figured it out. It was in ~/.cache/twsearch/ — Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOLSYMVJ7VMH3GZSURDSD2GAMZPAVCNFSM6AAAAABTOFWPK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBYGM3TONBYGU> . You are receiving this because you commented.Message ID: ***@***.***>

-- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.net/ / -