Omitting piece types for Corner Helicopter 2x2, missed optimal #76
Comments
|
On an unrelated note.. While creating the modified scramble in this example, I noticed that it doesn't support using |
|
twsearch only supports comments (in tws files) that consist of a line
starting with a pound sign.
There is no support (nor is any planned) for comments at the end of lines
with semantic content.
I realize it's pretty common for languages to support both at the same time
with the same syntax,
but it's not a feature that twsearch supports.
…On Mon, Dec 23, 2024 at 10:14 PM DougCube ***@***.***> wrote:
On an unrelated note.. While creating the modified scramble in this
example, I noticed that it doesn't support using # to comment at the end
of scramble lines and I had to insert line breaks to make it work.
—
Reply to this email directly, view it on GitHub
<#76 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSZA3BH2DKV7GRYR4TT2HD3TJAVCNFSM6AAAAABUEFW6YWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRQG4YDQMJXGY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I don't think this is a bug; at most it is a missing feature. The twsearch
program does not omit moves that
"don't affect state". Likely there is a simple algorithm that would permit
it to do so, but right now it doesn't.
Anyway, the first problem is the --omit option does not take a
comma-separated list, but just a name. It's a
bug that it doesn't complain if it can't find that name. So give it
separate --omit commands for each thing to
delete.
Unfortunately this doesn't quite work, because with those piece sets
omitted, the moves that now "do nothing"
also don't get expanded move definitions (that is, from UBR I don't
generate UBR', for instance) since the
order of those moves is now 1 instead of 3. So your scramble algorithms
won't work due to "undefined moves".
I'm not sure how to fix this . . . I could define moves based on the
original def, but that just starts to get
complicated . . .
…-tom
On Mon, Dec 23, 2024 at 9:59 PM DougCube ***@***.***> wrote:
I created a definiton file for the "Corner Helicopter 2x2" (CH2) puzzle.
I'm trying to create a multi-phase solver for it.
But I was suprised with extremely poor runitmes. As an experiement I ran
with omitting all the pieces except for the induced 2x2 using this command: ./build/bin/twsearch
-c 1 --omit WING,TIP,MIDGE full.tws ch2_steven_1.scr. But I let it hit
depth 14 before killing it -- turns out there is a solution at depth 6.
I modified the scramble file to remove the moves that don't alter the 2x2
state and instead ran with the sample 2x2x2 definition file like this: ./build/bin/twsearch
-c 1 --moves U,F,R samples/main/2x2x2.tws ch2_steven_1_only_2x2.scr which
immediately found an optimal solution at depth 6 (U2 R' F' U F2 R). The
relavent files are attached below.
This seems to be a bug. I suspect that it's being slowed down by moves in
the scramble that only affect omitted pieces. Is the tool smart enough to
ignore searching moves which only impact omitted pieces?
Using the same basic definition file (but with some sets removed and/or
identical piece usage) and also modifing the scramble to remove the useless
moves, it runs as expected. Thus, I don't believe there's any problem with
my underlying defnition files. In the past, I got it to a 14-stage solver
that combined to produce solutions that actually solve a random scramble
after a lot of manual effort.
ch2_testcase.tar.gz
<https://github.com/user-attachments/files/18236279/ch2_testcase.tar.gz>
—
Reply to this email directly, view it on GitHub
<#76>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS4SCXWKM5LPNUYL72L2HDZ55AVCNFSM6AAAAABUEFW6YWVHI2DSMVQWIX3LMV43ASLTON2WKOZSG42TOMRTGQYTCMQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
--moves supports a comma-separated list, but --omit does not AND does not issue an error or warning when the set name does not exist in the definition file. This seems like a problem to me. The result was that the tool wasn't running what I expected it to be running. Then using multiple --omit options, I am seeing the "bad move name" error now. But if instead of using a ScrambleAlg, I use a Scramble state, then it will probably run as expected... and indeed it does. So a workaround would be to convert the ScrambleAlg to a state using --showpositions then put that into a .scr file and run it instead. But it should be possible to support ignoring those moves in the ScrambleAlg. Not sure why it's so complicated -- could just internally convert it to a state and drop the omitted piece sets. |
I created a definiton file for the "Corner Helicopter 2x2" (CH2) puzzle. I'm trying to create a multi-phase solver for it.
But I was suprised with extremely poor runitmes. As an experiement I ran with omitting all the pieces except for the induced 2x2 using this command:
./build/bin/twsearch -c 1 --omit WING,TIP,MIDGE full.tws ch2_steven_1.scr. But I let it hit depth 14 before killing it -- turns out there is a solution at depth 6.I modified the scramble file to remove the moves that don't alter the 2x2 state and instead ran with the sample 2x2x2 definition file like this:
./build/bin/twsearch -c 1 --moves U,F,R samples/main/2x2x2.tws ch2_steven_1_only_2x2.scrwhich immediately found an optimal solution at depth 6 (U2 R' F' U F2 R). The relavent files are attached below.This seems to be a bug. I suspect that it's being slowed down by moves in the scramble that only affect omitted pieces. Is the tool smart enough to ignore searching moves which only impact omitted pieces?
Using the same basic definition file (but with some sets removed and/or identical piece usage) and also modifing the scramble to remove the useless moves, it runs as expected. Thus, I don't believe there's any problem with my underlying defnition files. In the past, I got it to a 14-stage solver that combined to produce solutions that actually solve a random scramble after a lot of manual effort.
ch2_testcase.tar.gz
The text was updated successfully, but these errors were encountered: