Open DougCube opened 1 year ago
To generate the "additional" moves, we need to know the order of a move (so we know what additional moves to generate), and an empty (null) move has 0 order, so no moves are generated.
Moves should not exist in .scr files; are you putting Move commands in .scr files?
It is not impossible to extend twsearch to accept additional moves (such as U2') but doing so generally would require some non-trivial effort. For instance, one might want to accept u as a synonym for Uw, or accept slice designations such as 2-4U, like twizzle explorer and editor, but right now twsearch does not implement a full SiGN parser or swizzler.
You can specify a move subset on the command line (as in, --moves U,R,F2) and twsearch will ignore the moves from the .tws file that are not in the move list; perhaps this feature will be useful for what you are trying to do? Does this change your request in any meaningful way?
> You can specify a move subset on the command line (as in, --moves U,R,F2) and twsearch will ignore the moves from the .tws file that are not in the move list; perhaps this feature will be useful for what you are trying to do?
I overlooked this feature to do what I want. It's perfect... as long as Twsearch can deal with parsing moves from the SCR file that are no longer in the TWS file, which I doubt.
I just tried the '--moves' option. It is not happy with undefined moves. So I'll try to define it as null move X, but then it won't take X' in the scramble. Can I define X' as a null move directly?
The intent is that all the moves remain in the .tws file, and you use --moves to restrict the move set for solving/searching. But all moves from the .tws file (even those not specified in --moves) remain available for parsing move sequences. (Be careful; unless you use --checkbeforesolve, you can then specify a scramble that is unsolvable, as in --moves U,F,R --scramblealg D).
On Thu, Nov 9, 2023 at 10:10 AM DougCube @.***> wrote:
> You can specify a move subset on the command line (as in, --moves U,R,F2) and twsearch will ignore the moves from the .tws file that are not in the move list; perhaps this feature will be useful for what you are trying to do?
I overlooked this feature to do what I want. It's perfect... as long as Twsearch can deal with parsing moves that are no longer in the TWS file, which I doubt.
— Reply to this email directly, view it on GitHub https://github.com/cubing/twsearch/issues/42#issuecomment-1804317602, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMOLS42FJNCLJ7IJLEMN2TYDUMC3AVCNFSM6AAAAAA7E46QZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUGMYTONRQGI . You are receiving this because you commented.Message ID: @.***>
--
Bottom line is, I fail to see justification for "null moves" in .tws files. Given our discussion, can you motivate the need for these?
On Thu, Nov 9, 2023 at 10:26 AM Tomas Rokicki @.***> wrote:
The intent is that all the moves remain in the .tws file, and you use --moves to restrict the move set for solving/searching. But all moves from the .tws file (even those not specified in --moves) remain available for parsing move sequences. (Be careful; unless you use --checkbeforesolve, you can then specify a scramble that is unsolvable, as in --moves U,F,R --scramblealg D).
On Thu, Nov 9, 2023 at 10:10 AM DougCube @.***> wrote:
> You can specify a move subset on the command line (as in, --moves U,R,F2) and twsearch will ignore the moves from the .tws file that are not in the move list; perhaps this feature will be useful for what you are trying to do?
I overlooked this feature to do what I want. It's perfect... as long as Twsearch can deal with parsing moves that are no longer in the TWS file, which I doubt.
— Reply to this email directly, view it on GitHub https://github.com/cubing/twsearch/issues/42#issuecomment-1804317602, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMOLS42FJNCLJ7IJLEMN2TYDUMC3AVCNFSM6AAAAAA7E46QZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUGMYTONRQGI . You are receiving this because you commented.Message ID: @.***>
--
--
I should better explain what I'm trying to do. For a larger puzzle, I created a complete definition file, but it's too computationally intensive to solve a random state or the particular scramble I provided. I want to create a two-phase solver, so I copy the definition file and delete all of some type of piece, but it leaves some types of moves null. I want to run the new definition file on the same scramble, but the parser is okay with the null moves still being there but then if the scramble contains a previously "created move," the parser will error out.
My attempt at a two-phase solver for this puzzle is iterative -- it will require a lot of experimentation to balance the phases and pick which pieces to ignore and when. So I end up with dozens of variations of the full definition file, but I don't want to also have dozens of variations of what is essentially the same scramble file.
Understand. And interestingly I am also working on the same sort of thing, perhaps even for the same puzzle!
Generally what you want to do is leave the .tws file alone, except for the Solved section. Using identical piece definitions (giving more than one piece the same value) and orientation wildcards (give a ? instead of a number), you can accomplish quite a bit. See samples/main/3p1 for an example that uses identical pieces for the conventional phase 1 of the 3x3x3 solver.
For moves, remember that you only need to specify a base move; on the 3x3x3, U means U + U2 + U'; U2 means only U2.
You can even drop a set completely with the --omit command line option (or --nocorners, --noedges, --nocenters); again, no change to the .tws file needed.
This does not satisfy all requirements of multiphase solver exploration, but it goes a long way.
If you find this useful, I would almost certainly be willing to add a --solvedfile option that lets you specify (override) the "solved" definition in the .tws file with a different one.
Although '--solvedfile' might be useful for other people or for me in other efforts. I think what was mainly gating me was that there is just --nocorner, --noedges, and --nocenters. I want a general --nopieces so I could do something like '--nopieces CORNER,EDGE'. But in my case, the name of the piece type I want to omit is different.
I think with that ability I wouldn't have to touch the TWS file at all!
The --omit is exactly for this case. You can --omit CORNER_EDGE --omit PIECESET33 --omit FOOPARITY99 or whatever else you need.
But you can also get the effect of --omit in solved by giving each piece a value of one and an orientation (if the piece has orientation) of ?. That makes that set essentially a no-op, except the piece will still be considered when generating move sets (that is, the order of a move is defined by its order on the superpuzzle identity, with no identical pieces or orientation wildcards), so parsing sequences/etc. will still work fine.
I just dug around and '--omit' is not in the README, also I tried '-h' and '--help' to see if it gives a more updated list of options, but those don't work either. So how was I supposed to know that option existed?! :)
> If you find this useful, I would almost certainly be willing to add a --solvedfile option that lets you specify (override) the "solved" definition in the .tws file with a different one.
Okay, now that I understand the usage-model a lot better I do think this would be a very useful feature. Because even with the '--omit' flag, I cannot do some of the things I want, such as, having indistinguish pieces for a stage.
Problem. Using the '--omit' doesn't work for my problem as I just found out. I expected it to work.
It suppresses or still avoids the "Created new moves" part of the execution and flags some illegal moves in my ScrambleAlg, which were allowed before adding the '--omit'.
This is unfortunate. I understand why this happens, but I don't have an excellent fix for you. A workaround is, instead of using --omit, use identical pieces and orientation wildcards to "null out" the effect of a set while preserving the move semantics. If you do this, the moves should work as you expect.
For convenience, when coming up with multi-stage solvers, I copy an existing TWS file and remove pieces which leaves some move lines empty (like "Move ABC\nEnd"). I keep those lines to avoid having to remove those moves from the SCR files. It allows such moves in the TWS and in the SCR, but does not allow things like ABC' or ABC2 in the SCR file whereas it would allow them when using the old TWS file. It would be nice to give the option of forcing the "Created new moves" feature to create those dummy moves. Similarly, for an order-2 MOVE, to accept MOVE' even though it's the same as MOVE.
The reason I want this is to keep using same SCR file with different TWS files. The problem is amplified when I have a large set of SCR files.
I also do hope that with the null moves, Twsearch properly ignores them from the scrambles and doesn't output any in its solutions.