God's Number Search for X-Cross, Bug in Position Counts with Identical Pieces #113
Comments
|
Earlier, the one I ran for Cross yielded results identically matching the results published by others: And I had also run one for 2x2x2 block which has total positions matching expected value of And there are other cases I ran that match expectation, but the X-Cross one does not match expectation. |
|
NEVERMIND, I forgot about the FR edge piece in my calculation. |
|
I spoke too soon. Next line of output was this: But: And it's been running for 10 hours now. |
|
So we're good on this one?
…On Mon, Feb 24, 2025 at 2:34 PM DougCube ***@***.***> wrote:
I spoke too soon. Next line of output was this:
Dist 10 cnt 36023 tot 72990721 in 13.6056
But:
CP = 8
CO = 3
EP = 12 * 11 * 10 * 9 * 8
EO = 2^5
product = *72,990,720*
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS5PMWGD6APRF6KLWFT2ROM63AVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZHAYTQMZZGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
I spoke too soon. Next line of output was this:
Dist 10 cnt 36023 tot 72990721 in 13.6056
But:
CP = 8
CO = 3
EP = 12 * 11 * 10 * 9 * 8
EO = 2^5
product = *72,990,720*
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS5PMWGD6APRF6KLWFT2ROM63AVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZHAYTQMZZGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Maybe not, because it's total at 10 moves or less is 1 OVER the expected count already. |
|
Use -F.
- https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/
<http://golly.sf.net/> - https://alpha.twizzle.net/
/ -
…On Mon, Feb 24, 2025 at 3:25 PM DougCube ***@***.***> wrote:
Maybe not, because it's total at 10 moves or less is 1 OVER the expected
count already.
I'm going to wait for this to finish and then run it again, because it
could be a glitch.
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS4VHRDAJ324Y2FLMQ32ROS7XAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZHEZDGMBSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
Maybe not, because it's total at 10 moves or less is 1 OVER the expected
count already.
I'm going to wait for this to finish and then run it again, because it
could be a glitch.
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS4VHRDAJ324Y2FLMQ32ROS7XAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZHEZDGMBSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I doubt it is either a glitch or incorrect. Can you explain why you think
the distance is wrong? Do you have a different analysis or calculation
which indicates something different?
- https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/
<http://golly.sf.net/> - https://alpha.twizzle.net/
/ -
…On Mon, Feb 24, 2025 at 3:25 PM DougCube ***@***.***> wrote:
Maybe not, because it's total at 10 moves or less is 1 OVER the expected
count already.
I'm going to wait for this to finish and then run it again, because it
could be a glitch.
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS4VHRDAJ324Y2FLMQ32ROS7XAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZHEZDGMBSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
Maybe not, because it's total at 10 moves or less is 1 OVER the expected
count already.
I'm going to wait for this to finish and then run it again, because it
could be a glitch.
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS4VHRDAJ324Y2FLMQ32ROS7XAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZHEZDGMBSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I didn't know about the -F option. How does it impact the runtime? The number of positions is 72,990,720 but the current total it is giving uo to distance 10 is already 1 greater than this number.
I do agree that |
|
Oh wait, that 721 is a problem. That . . . shouldn't happen.
It's funny though that it says "in 13.6s". Can you send me the full log?
Something looks
really screwy here.
…On Mon, Feb 24, 2025 at 10:26 PM DougCube ***@***.***> wrote:
I didn't know about the -F option. How does it impact the runtime?
The number of positions is 72,990,720 but the current total it is giving
uo to distance 10 is already 1 greater than this number.
Also, even if these numbers are fine, it has been running for nearly 18
hours now, which would indicate a serious performance issue. I should rerun
with -F (and -t 23). Btw, what is the default thread usage when there is
no -t given?
Dist 10 cnt 36023 tot 72990721 in 13.6056
But:
CP = 8
CO = 3
EP = 12 * 11 * 10 * 9 * 8
EO = 2^5
product = *72,990,720*
I do agree that Dist 1 cnt 15.
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS5T2LY6UUZNCSRGRKL2RQEK3AVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBQG43TCNBWGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
I didn't know about the -F option. How does it impact the runtime?
The number of positions is 72,990,720 but the current total it is giving
uo to distance 10 is already 1 greater than this number.
Also, even if these numbers are fine, it has been running for nearly 18
hours now, which would indicate a serious performance issue. I should rerun
with -F (and -t 23). Btw, what is the default thread usage when there is
no -t given?
Dist 10 cnt 36023 tot 72990721 in 13.6056
But:
CP = 8
CO = 3
EP = 12 * 11 * 10 * 9 * 8
EO = 2^5
product = *72,990,720*
I do agree that Dist 1 cnt 15.
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS5T2LY6UUZNCSRGRKL2RQEK3AVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBQG43TCNBWGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I just ran something else to verify that the totals are correct up to distance 5. gods_number_for_xcross_log.txt |
|
If you run with -F it should be finished really quickly. (It's just a
variation of the
default -g search, which for this file is really quite dreadful.)
But the 721 at the end for your normal run . . . I'm checking that. It's
going
to need an overnight run.
…-tom
On Mon, Feb 24, 2025 at 11:26 PM DougCube ***@***.***> wrote:
I just ran something else to verify that the totals are correct up to
distance 5.
gods_number_for_xcross_log.txt
<https://github.com/user-attachments/files/18959013/gods_number_for_xcross_log.txt>
xcross_UFR_(change ext to tws).txt
<https://github.com/user-attachments/files/18959063/xcross_UFR_.change.ext.to.tws.txt>
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSY5UUV63VBI2DTCK4D2RQLJZAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBQHEZDONRZGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
I just ran something else to verify that the totals are correct up to
distance 5.
gods_number_for_xcross_log.txt
<https://github.com/user-attachments/files/18959013/gods_number_for_xcross_log.txt>
xcross_UFR_(change ext to tws).txt
<https://github.com/user-attachments/files/18959063/xcross_UFR_.change.ext.to.tws.txt>
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSY5UUV63VBI2DTCK4D2RQLJZAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBQHEZDONRZGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Okay, at this point I suspect it's stuck in an inf-loop so I killed it after letting it run for 19 hours. I reluanched using |
|
The point of what I'm trying to do is to find some gods numbers to different subgoals and append |
I think these numbers are correct, they are consistent with another calculation result from more than ten years ago: http://www.mf8-china.com/forum.php?mod=viewthread&tid=93127 |
|
Yes, I started having confidence in these numbers when I manually tried dist=2 and ran a different tool that matched up to dist=5. Comparing this correct table, with the version run without |
|
I changed definition files to run similar search but for a 2x2x3 block. It keeps crashing due to running out of memory. |
|
I notice you're not giving it a -M option to say how much memory it is
allowed to use . . . the default is 8GB. If you have more memory that
twsearch can use, letting it know will help it run larger searches.
…On Mon, Feb 24, 2025 at 11:50 PM DougCube ***@***.***> wrote:
I changed definition files to run similar search but for a 2x2x3 block. It
keeps getting quickly killed for running out of memory.
$ time ./twsearch -g -F -t 23 def_files/2x2x3_DL.tws
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 def_files/2x2x3_DL.tws
Created new moves U2 U' D2 D' R2 R' L2 L' F2 F' B2 B'
State size is about 6.89703 x 10^20 log2 69.2245
Requiring 161 bits 24 bytes per entry; 32 from identity.
Found 7 canonical move states.
Calculated canonical states in 0.000111103
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.29018e-05
Dist 1 cnt 12 tot 13 in 0.00113106
Dist 2 cnt 141 tot 154 in 0.00108409
Dist 3 cnt 1746 tot 1900 in 0.00120497
Dist 4 cnt 20935 tot 22835 in 0.00329089
Dist 5 cnt 243092 tot 265927 in 0.020803
Dist 6 cnt 2698935 tot 2964862 in 0.218474
Dist 7 cnt 27258179 tot 30223041 in 2.74685
Created 327956796 elements in 3.01091
to 161981604 in 13.9112
Dist 8 cnt 216204042 tot 246427083 in 20.5663
Created 114451686 elements in 0.66789
to 55362257 in 5.59231
Created 114451685 elements in 0.322043
to 80247849 in 6.96348
Created 114451701 elements in 0.186485
to 94441887 in 6.11235
Created 114451695 elements in 0.106997
to 102607201 in 5.60856
Created 114451687 elements in 0.07144
to 107380002 in 6.40387
Created 114451698 elements in 0.039526
to 110130399 in 6.52557
! out of memory
real 1m19.096s
user 6m32.798s
sys 0m3.954s
$ time ./twsearch -g -F -t 23 def_files/2x2x3_DL.tws
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 def_files/2x2x3_DL.tws
Created new moves U2 U' D2 D' R2 R' L2 L' F2 F' B2 B'
State size is about 6.89703 x 10^20 log2 69.2245
Requiring 161 bits 24 bytes per entry; 32 from identity.
Found 7 canonical move states.
Calculated canonical states in 0.000104904
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.00407e-05
Dist 1 cnt 12 tot 13 in 0.00110698
Dist 2 cnt 141 tot 154 in 0.00089407
Dist 3 cnt 1746 tot 1900 in 0.00112987
Dist 4 cnt 20935 tot 22835 in 0.00310898
Dist 5 cnt 243092 tot 265927 in 0.0202291
Dist 6 cnt 2698935 tot 2964862 in 0.217447
Dist 7 cnt 27258179 tot 30223041 in 2.59254
Created 327956814 elements in 2.48277
to 161981611 in 13.4103
Dist 8 cnt 216204042 tot 246427083 in 19.9385
Created 114451704 elements in 0.161602
to 55362262 in 5.89678
Created 114451708 elements in 0.27744
to 80247872 in 6.77853
Created 114451706 elements in 0.172443
to 94441896 in 6.07879
Created 114451704 elements in 0.097373
to 102607206 in 179.863
Created 114451710 elements in 0.061398
to 107380014 in -167.603
Created 114451710 elements in 0.0403171
to 110130402 in 6.35392
! out of memory
real 1m16.860s
user 6m8.993s
sys 0m3.089s
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSZITDDC24MVSBXEC4L2RQOEPAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBQHE4TIOJQGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
I changed definition files to run similar search but for a 2x2x3 block. It
keeps getting quickly killed for running out of memory.
$ time ./twsearch -g -F -t 23 def_files/2x2x3_DL.tws
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 def_files/2x2x3_DL.tws
Created new moves U2 U' D2 D' R2 R' L2 L' F2 F' B2 B'
State size is about 6.89703 x 10^20 log2 69.2245
Requiring 161 bits 24 bytes per entry; 32 from identity.
Found 7 canonical move states.
Calculated canonical states in 0.000111103
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.29018e-05
Dist 1 cnt 12 tot 13 in 0.00113106
Dist 2 cnt 141 tot 154 in 0.00108409
Dist 3 cnt 1746 tot 1900 in 0.00120497
Dist 4 cnt 20935 tot 22835 in 0.00329089
Dist 5 cnt 243092 tot 265927 in 0.020803
Dist 6 cnt 2698935 tot 2964862 in 0.218474
Dist 7 cnt 27258179 tot 30223041 in 2.74685
Created 327956796 elements in 3.01091
to 161981604 in 13.9112
Dist 8 cnt 216204042 tot 246427083 in 20.5663
Created 114451686 elements in 0.66789
to 55362257 in 5.59231
Created 114451685 elements in 0.322043
to 80247849 in 6.96348
Created 114451701 elements in 0.186485
to 94441887 in 6.11235
Created 114451695 elements in 0.106997
to 102607201 in 5.60856
Created 114451687 elements in 0.07144
to 107380002 in 6.40387
Created 114451698 elements in 0.039526
to 110130399 in 6.52557
! out of memory
real 1m19.096s
user 6m32.798s
sys 0m3.954s
$ time ./twsearch -g -F -t 23 def_files/2x2x3_DL.tws
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 def_files/2x2x3_DL.tws
Created new moves U2 U' D2 D' R2 R' L2 L' F2 F' B2 B'
State size is about 6.89703 x 10^20 log2 69.2245
Requiring 161 bits 24 bytes per entry; 32 from identity.
Found 7 canonical move states.
Calculated canonical states in 0.000104904
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.00407e-05
Dist 1 cnt 12 tot 13 in 0.00110698
Dist 2 cnt 141 tot 154 in 0.00089407
Dist 3 cnt 1746 tot 1900 in 0.00112987
Dist 4 cnt 20935 tot 22835 in 0.00310898
Dist 5 cnt 243092 tot 265927 in 0.0202291
Dist 6 cnt 2698935 tot 2964862 in 0.217447
Dist 7 cnt 27258179 tot 30223041 in 2.59254
Created 327956814 elements in 2.48277
to 161981611 in 13.4103
Dist 8 cnt 216204042 tot 246427083 in 19.9385
Created 114451704 elements in 0.161602
to 55362262 in 5.89678
Created 114451708 elements in 0.27744
to 80247872 in 6.77853
Created 114451706 elements in 0.172443
to 94441896 in 6.07879
Created 114451704 elements in 0.097373
to 102607206 in 179.863
Created 114451710 elements in 0.061398
to 107380014 in -167.603
Created 114451710 elements in 0.0403171
to 110130402 in 6.35392
! out of memory
real 1m16.860s
user 6m8.993s
sys 0m3.089s
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSZITDDC24MVSBXEC4L2RQOEPAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBQHE4TIOJQGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
So would it be |
Here is a 2x2x3 depth distribution calculated by other cubers years ago. 0 1 |
|
|
|
Either -M 64000 or -M 65536 will be pretty much indistinguishable.
In any case, I think the 721 is definitely either a bug or a hardware issue
(glitch) but I have a hard time believing either. I ran it overnight with
the
"default" -g and didn't see that problem; I get
Dist 10 cnt 36022 tot 72990720 in 32.3631
I'd be interested in seeing you run it again and see if you experience
the problem a second time.
…-tom
On Tue, Feb 25, 2025 at 12:09 AM DougCube ***@***.***> wrote:
So would it be -M 64000 to allow it to use up to 64 GB? Or is it -M 65536?
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS5OZJYXH26M5ECG32L2RQQKNAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGA2DONJWHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
So would it be -M 64000 to allow it to use up to 64 GB? Or is it -M 65536?
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS5OZJYXH26M5ECG32L2RQQKNAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGA2DONJWHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thanks, Chen Shuang, for the information!
BTW I'm (very slowly) enhancing the -g in twsearch to do much larger
and faster searches using a variety of techniques. At the moment twsearch
has several different ways to do God's number searches, but they are
not easy to select and the wrong one may often pop up unexpectedly.
If twsearch can prove (to itself) that a search is small enough, as happens
with the 222 for instance, it can generate move tables and do a quick
two-bit search.
If it can't, normally then it assumes the puzzle is absolutely huge and the
search is not expected to complete, so it uses a canonical search and
sorting/unique approach which requires building an array of full-state
representations; this is useful for getting distance-table prefixes on the
444
for instance, but (as we see here) can be *very* slow for puzzles where
the God's number search can *actually* complete but twsearch doesn't
recognize that.
Because of this I added a very hacky "-F" switch that tells twsearch to use
level-by-level sorted-array God's number searches; this works much better
on searches that can be completed in array mode than the canonical
sequence approach, generally, but is not nearly as memory-efficient as the
two-bit mode.
When I have new code that works better and it's reasonably integrated with
a reasonable way to invoke it, I'll let you guys know.
…On Tue, Feb 25, 2025 at 8:10 AM Tomas Rokicki ***@***.***> wrote:
Either -M 64000 or -M 65536 will be pretty much indistinguishable.
In any case, I think the 721 is definitely either a bug or a hardware issue
(glitch) but I have a hard time believing either. I ran it overnight with
the
"default" -g and didn't see that problem; I get
Dist 10 cnt 36022 tot 72990720 in 32.3631
I'd be interested in seeing you run it again and see if you experience
the problem a second time.
-tom
On Tue, Feb 25, 2025 at 12:09 AM DougCube ***@***.***>
wrote:
> So would it be -M 64000 to allow it to use up to 64 GB? Or is it -M 65536
> ?
>
> —
> Reply to this email directly, view it on GitHub
> <#113 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAMOLS5OZJYXH26M5ECG32L2RQQKNAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGA2DONJWHE>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
> [image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
> <#113 (comment)>
>
> So would it be -M 64000 to allow it to use up to 64 GB? Or is it -M 65536
> ?
>
> —
> Reply to this email directly, view it on GitHub
> <#113 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAMOLS5OZJYXH26M5ECG32L2RQQKNAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGA2DONJWHE>
> .
> 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/
/ -
|
|
Funny thing. I got same isssue but on a different definition file. And thanks to Chen, we know where it diverges from correct. |
|
Then this looks like a bug. I'm trying to reproduce this here. So far no
joy.
Can you attach 2x2x3_DL.tws for me? Thanks!
…On Tue, Feb 25, 2025 at 9:42 AM DougCube ***@***.***> wrote:
Funny thing. I got same isssue but on a different definition file.
And thanks to Chen, we know where it diverges from correct.
In the below, Dist 10 is +1 from the correct value.
It then does weird stuff and runs out of memory.
$ time ./twsearch -g -F -t 23 -M 65536 def_files/2x2x3_DL.tws
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 -M 65536 def_files/2x2x3_DL.tws
Created new moves U2 U' D2 D' R2 R' L2 L' F2 F' B2 B'
State size is about 6.89703 x 10^20 log2 69.2245
Requiring 161 bits 24 bytes per entry; 32 from identity.
Found 7 canonical move states.
Calculated canonical states in 0.000421047
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.48091e-05
Dist 1 cnt 12 tot 13 in 0.00090003
Dist 2 cnt 141 tot 154 in 0.000636101
Dist 3 cnt 1746 tot 1900 in 0.000864029
Dist 4 cnt 20935 tot 22835 in 0.00327301
Dist 5 cnt 243092 tot 265927 in 0.0198879
Dist 6 cnt 2698935 tot 2964862 in 0.224359
Dist 7 cnt 27258179 tot 30223041 in 2.73444
Dist 8 cnt 216204042 tot 246427083 in 30.4197
Created 2619849276 elements in 25.7704
to 694876500 in 125.196
Dist 9 cnt 830686751 tot 1077113834 in 146.079
Created 1816420716 elements in 9.65677
to 233650322 in 97.4081
Created 1816420706 elements in 7.96838
to 332360584 in 81.9052
Created 1816420714 elements in 7.912
to 387056536 in 85.349
Created 1816420714 elements in 7.44941
to 414692315 in 91.7252
Created 1816420715 elements in 7.31139
to 432632488 in 93.8854
Created 1816420702 elements in 7.76155
to 441917062 in 95.9229
Created 1816420714 elements in 7.41433
to 448573938 in 106.248
Created 1816420704 elements in 180.574
to 451076104 in -41.2412
Created 1816420708 elements in 7.79261
to 452503717 in 142.801
Created 1816420705 elements in 6.82965
to 453593933 in 138.601
Dist 10 cnt 453825502 tot 1530939336 in 225.869
Created 1578799242 elements in -165.384
to 1765369 in 69.924
Created 1578799243 elements in 8.14429
to 1864328 in 71.9242
Created 1578799256 elements in 8.15398
to 1865764 in 76.9873
Created 1578799252 elements in 8.18128
to 1865802 in 98.8022
Created 1578799254 elements in 8.8017
to 1865802 in 130.097
Dist 11 cnt 1865802 tot 1532805138 in 22.5837
Dist 12 cnt 244 tot 1532805382 in 2.62979
Dist 13 cnt 3223 tot 1532808605 in 0.00437903
Dist 14 cnt 42225 tot 1532850830 in 0.002949
Dist 15 cnt 542131 tot 1533392961 in 0.032984
Dist 16 cnt 6755688 tot 1540148649 in 0.481853
Dist 17 cnt 79994952 tot 1620143601 in 6.86368
Dist 18 cnt 840537691 tot 2460681292 in 92.5681
Created 1942778862 elements in 10.7022
to 1147085709 in 107.814
Created 1942778859 elements in 4.00402
to 1569478748 in 98.4076
Created 1942778858 elements in 2.03172
to 1753685605 in 101.867
Created 1942778863 elements in 1.0436
to 1846906011 in 111.509
! out of memory
real 42m57.873s
user 264m23.230s
sys 1m26.984s
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS2XQSENAZQWPKKDCVL2RSTRFAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHAZDMMBRHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
Funny thing. I got same isssue but on a different definition file.
And thanks to Chen, we know where it diverges from correct.
In the below, Dist 10 is +1 from the correct value.
It then does weird stuff and runs out of memory.
$ time ./twsearch -g -F -t 23 -M 65536 def_files/2x2x3_DL.tws
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 -M 65536 def_files/2x2x3_DL.tws
Created new moves U2 U' D2 D' R2 R' L2 L' F2 F' B2 B'
State size is about 6.89703 x 10^20 log2 69.2245
Requiring 161 bits 24 bytes per entry; 32 from identity.
Found 7 canonical move states.
Calculated canonical states in 0.000421047
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.48091e-05
Dist 1 cnt 12 tot 13 in 0.00090003
Dist 2 cnt 141 tot 154 in 0.000636101
Dist 3 cnt 1746 tot 1900 in 0.000864029
Dist 4 cnt 20935 tot 22835 in 0.00327301
Dist 5 cnt 243092 tot 265927 in 0.0198879
Dist 6 cnt 2698935 tot 2964862 in 0.224359
Dist 7 cnt 27258179 tot 30223041 in 2.73444
Dist 8 cnt 216204042 tot 246427083 in 30.4197
Created 2619849276 elements in 25.7704
to 694876500 in 125.196
Dist 9 cnt 830686751 tot 1077113834 in 146.079
Created 1816420716 elements in 9.65677
to 233650322 in 97.4081
Created 1816420706 elements in 7.96838
to 332360584 in 81.9052
Created 1816420714 elements in 7.912
to 387056536 in 85.349
Created 1816420714 elements in 7.44941
to 414692315 in 91.7252
Created 1816420715 elements in 7.31139
to 432632488 in 93.8854
Created 1816420702 elements in 7.76155
to 441917062 in 95.9229
Created 1816420714 elements in 7.41433
to 448573938 in 106.248
Created 1816420704 elements in 180.574
to 451076104 in -41.2412
Created 1816420708 elements in 7.79261
to 452503717 in 142.801
Created 1816420705 elements in 6.82965
to 453593933 in 138.601
Dist 10 cnt 453825502 tot 1530939336 in 225.869
Created 1578799242 elements in -165.384
to 1765369 in 69.924
Created 1578799243 elements in 8.14429
to 1864328 in 71.9242
Created 1578799256 elements in 8.15398
to 1865764 in 76.9873
Created 1578799252 elements in 8.18128
to 1865802 in 98.8022
Created 1578799254 elements in 8.8017
to 1865802 in 130.097
Dist 11 cnt 1865802 tot 1532805138 in 22.5837
Dist 12 cnt 244 tot 1532805382 in 2.62979
Dist 13 cnt 3223 tot 1532808605 in 0.00437903
Dist 14 cnt 42225 tot 1532850830 in 0.002949
Dist 15 cnt 542131 tot 1533392961 in 0.032984
Dist 16 cnt 6755688 tot 1540148649 in 0.481853
Dist 17 cnt 79994952 tot 1620143601 in 6.86368
Dist 18 cnt 840537691 tot 2460681292 in 92.5681
Created 1942778862 elements in 10.7022
to 1147085709 in 107.814
Created 1942778859 elements in 4.00402
to 1569478748 in 98.4076
Created 1942778858 elements in 2.03172
to 1753685605 in 101.867
Created 1942778863 elements in 1.0436
to 1846906011 in 111.509
! out of memory
real 42m57.873s
user 264m23.230s
sys 1m26.984s
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS2XQSENAZQWPKKDCVL2RSTRFAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHAZDMMBRHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@cs0x7f It didn't occur to me to google the numbers I'm getting. I should start doing that from now on. There wass only one place I found the information for 2x2x3 and it was posted by Bruce N, someone I used to know! However, my next search is 2x2x3+EO, and those values are not found by Google. |
|
(Changed extension since it won't allow TWS files.) |
|
Not necessarily a bug, it could still be a hardware problem on my end... which would be embarassing for me. It is not even an overclocked system. I asked this question earlier: Does running normal searches to solve scrambles with |
|
Using --maxdepth won't improve search times for normal scrambles.
Here's the numbers I get for the 223DL file:
Dist 0 1 1 in 5.00679e-05
Dist 1 12 13 in 0.174882
Dist 2 141 154 in 0.0995491
Dist 3 1746 1900 in 0.096014
Dist 4 20935 22835 in 0.103636
Dist 5 243092 265927 in 0.114854
Dist 6 2698935 2964862 in 0.278835
Dist 7 27258179 30223041 in 1.05741
Dist 8 216204042 246427083 in 8.81661
Dist 9 830686751 1077113834 in 46.4778
Dist 10 453825501 1530939335 in 26.428
Dist 11 1865784 1532805119 in 0.348093
Dist 12 1 1532805120 in 0.11683
The +1 on that 10 you see is seriously concerning. It could be a
hardware glitch, or it could be I'm doing something in twsearch that
is somehow system-dependent or undefined-behavior.
Would you be willing to run that search again with -t 1 and see what
happens? Maybe I'm doing something wrong in my "parallel sort".
As it turns out, the parallelism helps very little here so the times won't
likely be all that different.
…-tom
On Tue, Feb 25, 2025 at 10:03 AM DougCube ***@***.***> wrote:
Not necessarily a bug, it could still be a hardware problem on my end...
which would be embarassing for me. It is not even an overclocked system.
I asked this question earlier: Does running normal searches to solve
scrambles with --maxdepth N where N is the god's number somehow improve
performance or does it not matter (due to how BFS works)? The main purpose
of my -g runs are to set max depth values.
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSZPSNTRVTJN2TANVUL2RSWADAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHA3TMNZSGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
Not necessarily a bug, it could still be a hardware problem on my end...
which would be embarassing for me. It is not even an overclocked system.
I asked this question earlier: Does running normal searches to solve
scrambles with --maxdepth N where N is the god's number somehow improve
performance or does it not matter (due to how BFS works)? The main purpose
of my -g runs are to set max depth values.
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSZPSNTRVTJN2TANVUL2RSWADAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHA3TMNZSGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I'm running God's Number search on FTO. I googled some values and cannot find anything. Should I have run this one without |
|
@rokicki If I do not give a |
|
If you don't give it a -t, it defaults to whatever the system says the
number
of threads is (as returned by thread::hardware_concurrency()).
…On Tue, Feb 25, 2025 at 10:15 AM DougCube ***@***.***> wrote:
@rokicki <https://github.com/rokicki> If I do not give a -t N, what does
it default to doing?
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS37QTXXBUGOQTXQKVD2RSXKJAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHEYDGMRXHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
@rokicki <https://github.com/rokicki> If I do not give a -t N, what does
it default to doing?
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS37QTXXBUGOQTXQKVD2RSXKJAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHEYDGMRXHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
For full FTO there's no hope of completing a God's number search for the
full
group, so -F is likely the best you're going to be able to do. The next
level
(level 9) just won't fit in your memory. It is likely of size about 12G
entries,
each requiring 16 bytes, so you'd need at least 200GB just for that level,
and
likely you'd need at least 300GB to actually calculate that level since you
need to store that level and the previous two along with extra memory for
the
sorting/uniqifying.
I *might* be able to run this to 10 on my 256GB machine. But really, the
right way to get a little further on this one is to use symmetry. Generate
the
FTO file with rotations and let twsearch take advantage of that.
…On Tue, Feb 25, 2025 at 10:14 AM DougCube ***@***.***> wrote:
I'm running God's Number search on FTO. I googled some values and cannot
find anything.
It crashed from running out of memory and due to the bug under discussion,
I don't know how much I can even trust the results.
Should I have run this one without -F?
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 -M 65536 --moves U,R,L,F,Uw,Rw,Lw,Fw ../twsearch/fto/fto_doug.tws
Created new moves U' R' L' F' Uw' Rw' Lw' Fw' Us' Rs' Ls' Fs'
State size is about 3.14081 x 10^22 log2 74.7336
Requiring 104 bits 16 bytes per entry; 20 from identity.
Found 9 canonical move states.
Calculated canonical states in 0.000156164
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.00407e-05
Dist 1 cnt 16 tot 17 in 0.000580788
Dist 2 cnt 208 tot 225 in 0.000740051
Dist 3 cnt 2688 tot 2913 in 0.00116014
Dist 4 cnt 34752 tot 37665 in 0.00282788
Dist 5 cnt 448336 tot 486001 in 0.0180371
Dist 6 cnt 5772360 tot 6258361 in 0.191999
Dist 7 cnt 74200286 tot 80458647 in 2.49132
Dist 8 cnt 952855390 tot 1033314037 in 36.5187
Created 3267911600 elements in 20.7157
to 2755004926 in 88.2917
Created 3267911598 elements in 2.58311
to 3180184546 in 87.2667
! out of memory
real 3m58.196s
user 38m6.906s
sys 0m24.033s
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSY2DS3AUUCDXUC2SWD2RSXHVAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHEYDCNZYGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
I'm running God's Number search on FTO. I googled some values and cannot
find anything.
It crashed from running out of memory and due to the bug under discussion,
I don't know how much I can even trust the results.
Should I have run this one without -F?
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 -M 65536 --moves U,R,L,F,Uw,Rw,Lw,Fw ../twsearch/fto/fto_doug.tws
Created new moves U' R' L' F' Uw' Rw' Lw' Fw' Us' Rs' Ls' Fs'
State size is about 3.14081 x 10^22 log2 74.7336
Requiring 104 bits 16 bytes per entry; 20 from identity.
Found 9 canonical move states.
Calculated canonical states in 0.000156164
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.00407e-05
Dist 1 cnt 16 tot 17 in 0.000580788
Dist 2 cnt 208 tot 225 in 0.000740051
Dist 3 cnt 2688 tot 2913 in 0.00116014
Dist 4 cnt 34752 tot 37665 in 0.00282788
Dist 5 cnt 448336 tot 486001 in 0.0180371
Dist 6 cnt 5772360 tot 6258361 in 0.191999
Dist 7 cnt 74200286 tot 80458647 in 2.49132
Dist 8 cnt 952855390 tot 1033314037 in 36.5187
Created 3267911600 elements in 20.7157
to 2755004926 in 88.2917
Created 3267911598 elements in 2.58311
to 3180184546 in 87.2667
! out of memory
real 3m58.196s
user 38m6.906s
sys 0m24.033s
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSY2DS3AUUCDXUC2SWD2RSXHVAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHEYDCNZYGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Okay, I just found and fixed a bug that was introduced by me in October
2024.
I think it's highly unlikely this bug is affecting your searches. But I am
letting
you know in the interest of full disclosure. (I think it's unlikely
because, if it
affected your searches, the output format would be significantly different.)
I will continue to dig into this and see if I can replicate the issue you
are seeing.
…-tom
On Tue, Feb 25, 2025 at 10:39 AM Tomas Rokicki ***@***.***> wrote:
For full FTO there's no hope of completing a God's number search for the
full
group, so -F is likely the best you're going to be able to do. The next
level
(level 9) just won't fit in your memory. It is likely of size about 12G
entries,
each requiring 16 bytes, so you'd need at least 200GB just for that level,
and
likely you'd need at least 300GB to actually calculate that level since you
need to store that level and the previous two along with extra memory for
the
sorting/uniqifying.
I *might* be able to run this to 10 on my 256GB machine. But really, the
right way to get a little further on this one is to use symmetry.
Generate the
FTO file with rotations and let twsearch take advantage of that.
On Tue, Feb 25, 2025 at 10:14 AM DougCube ***@***.***>
wrote:
> I'm running God's Number search on FTO. I googled some values and cannot
> find anything.
> It crashed from running out of memory and due to the bug under
> discussion, I don't know how much I can even trust the results.
>
> Should I have run this one without -F?
>
> # This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
> # ./twsearch -g -F -t 23 -M 65536 --moves U,R,L,F,Uw,Rw,Lw,Fw ../twsearch/fto/fto_doug.tws
> Created new moves U' R' L' F' Uw' Rw' Lw' Fw' Us' Rs' Ls' Fs'
> State size is about 3.14081 x 10^22 log2 74.7336
> Requiring 104 bits 16 bytes per entry; 20 from identity.
> Found 9 canonical move states.
> Calculated canonical states in 0.000156164
> Using sorting bfs and arrays.
> Dist 0 cnt 1 tot 1 in 3.00407e-05
> Dist 1 cnt 16 tot 17 in 0.000580788
> Dist 2 cnt 208 tot 225 in 0.000740051
> Dist 3 cnt 2688 tot 2913 in 0.00116014
> Dist 4 cnt 34752 tot 37665 in 0.00282788
> Dist 5 cnt 448336 tot 486001 in 0.0180371
> Dist 6 cnt 5772360 tot 6258361 in 0.191999
> Dist 7 cnt 74200286 tot 80458647 in 2.49132
> Dist 8 cnt 952855390 tot 1033314037 in 36.5187
> Created 3267911600 elements in 20.7157
> to 2755004926 in 88.2917
> Created 3267911598 elements in 2.58311
> to 3180184546 in 87.2667
> ! out of memory
>
> real 3m58.196s
> user 38m6.906s
> sys 0m24.033s
>
> —
> Reply to this email directly, view it on GitHub
> <#113 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAMOLSY2DS3AUUCDXUC2SWD2RSXHVAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHEYDCNZYGA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
> [image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
> <#113 (comment)>
>
> I'm running God's Number search on FTO. I googled some values and cannot
> find anything.
> It crashed from running out of memory and due to the bug under
> discussion, I don't know how much I can even trust the results.
>
> Should I have run this one without -F?
>
> # This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
> # ./twsearch -g -F -t 23 -M 65536 --moves U,R,L,F,Uw,Rw,Lw,Fw ../twsearch/fto/fto_doug.tws
> Created new moves U' R' L' F' Uw' Rw' Lw' Fw' Us' Rs' Ls' Fs'
> State size is about 3.14081 x 10^22 log2 74.7336
> Requiring 104 bits 16 bytes per entry; 20 from identity.
> Found 9 canonical move states.
> Calculated canonical states in 0.000156164
> Using sorting bfs and arrays.
> Dist 0 cnt 1 tot 1 in 3.00407e-05
> Dist 1 cnt 16 tot 17 in 0.000580788
> Dist 2 cnt 208 tot 225 in 0.000740051
> Dist 3 cnt 2688 tot 2913 in 0.00116014
> Dist 4 cnt 34752 tot 37665 in 0.00282788
> Dist 5 cnt 448336 tot 486001 in 0.0180371
> Dist 6 cnt 5772360 tot 6258361 in 0.191999
> Dist 7 cnt 74200286 tot 80458647 in 2.49132
> Dist 8 cnt 952855390 tot 1033314037 in 36.5187
> Created 3267911600 elements in 20.7157
> to 2755004926 in 88.2917
> Created 3267911598 elements in 2.58311
> to 3180184546 in 87.2667
> ! out of memory
>
> real 3m58.196s
> user 38m6.906s
> sys 0m24.033s
>
> —
> Reply to this email directly, view it on GitHub
> <#113 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAMOLSY2DS3AUUCDXUC2SWD2RSXHVAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHEYDCNZYGA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
--
- https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/
<http://golly.sf.net/> - https://alpha.twizzle.net/
/ -
|
|
Rerunning the 2x2x3 case with EDIT: Added remaining output for sake of completeness now that it finished running. |
|
Okay then for Gods number stuff uses -t 1. Threading should be fine for
searches. Pull in the recent change too. I’ll likely disable the parallel
sort stuff as the benefit is top marginal.
- https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/
<http://golly.sf.net/> - https://alpha.twizzle.net/
/ -
…On Tue, Feb 25, 2025 at 11:27 AM DougCube ***@***.***> wrote:
Rerunning the 2x2x3 case with -t 1 fixed it (at least up to Dist 10).
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 1 -M 65536 def_files/2x2x3_DL.tws
Created new moves U2 U' D2 D' R2 R' L2 L' F2 F' B2 B'
State size is about 6.89703 x 10^20 log2 69.2245
Requiring 161 bits 24 bytes per entry; 32 from identity.
Found 7 canonical move states.
Calculated canonical states in 0.000284195
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 8.58307e-05
Dist 1 cnt 12 tot 13 in 3.40939e-05
Dist 2 cnt 141 tot 154 in 6.00815e-05
Dist 3 cnt 1746 tot 1900 in 0.000498772
Dist 4 cnt 20935 tot 22835 in 0.00626612
Dist 5 cnt 243092 tot 265927 in 0.050251
Dist 6 cnt 2698935 tot 2964862 in 0.623706
Dist 7 cnt 27258179 tot 30223041 in 7.66635
Dist 8 cnt 216204042 tot 246427083 in 84.4156
Created 2619849308 elements in 130.896
to 694876506 in 339.87
Dist 9 cnt 830686751 tot 1077113834 in 300.168
Created 1816420736 elements in 85.6516
to 233650324 in 237.069
Created 1816420736 elements in 72.8703
to 332360585 in 235.454
Created 1816420736 elements in 69.3403
to 387056537 in 228.945
Created 1816420736 elements in 65.6055
to 414692316 in 229.096
Created 1816420736 elements in 65.3803
to 432632490 in 229.365
Created 1816420736 elements in 64.6381
to 441917064 in 229.818
Created 1816420736 elements in 63.4875
to 448573939 in 228.338
Created 1816420736 elements in 63.0933
to 451076103 in 228.372
Created 1816420736 elements in 62.3082
to 452503716 in 228.733
Created 1816420736 elements in 64.1557
to 453593932 in 226.665
Dist 10 cnt 453825501 tot 1530939335 in 114.428
Created 1578799277 elements in 72.8051
to 1765369 in 205.557
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS4Q3JDOXUFJKEPL77L2RS723AVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBTGA3DCMBYGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
Rerunning the 2x2x3 case with -t 1 fixed it (at least up to Dist 10).
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 1 -M 65536 def_files/2x2x3_DL.tws
Created new moves U2 U' D2 D' R2 R' L2 L' F2 F' B2 B'
State size is about 6.89703 x 10^20 log2 69.2245
Requiring 161 bits 24 bytes per entry; 32 from identity.
Found 7 canonical move states.
Calculated canonical states in 0.000284195
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 8.58307e-05
Dist 1 cnt 12 tot 13 in 3.40939e-05
Dist 2 cnt 141 tot 154 in 6.00815e-05
Dist 3 cnt 1746 tot 1900 in 0.000498772
Dist 4 cnt 20935 tot 22835 in 0.00626612
Dist 5 cnt 243092 tot 265927 in 0.050251
Dist 6 cnt 2698935 tot 2964862 in 0.623706
Dist 7 cnt 27258179 tot 30223041 in 7.66635
Dist 8 cnt 216204042 tot 246427083 in 84.4156
Created 2619849308 elements in 130.896
to 694876506 in 339.87
Dist 9 cnt 830686751 tot 1077113834 in 300.168
Created 1816420736 elements in 85.6516
to 233650324 in 237.069
Created 1816420736 elements in 72.8703
to 332360585 in 235.454
Created 1816420736 elements in 69.3403
to 387056537 in 228.945
Created 1816420736 elements in 65.6055
to 414692316 in 229.096
Created 1816420736 elements in 65.3803
to 432632490 in 229.365
Created 1816420736 elements in 64.6381
to 441917064 in 229.818
Created 1816420736 elements in 63.4875
to 448573939 in 228.338
Created 1816420736 elements in 63.0933
to 451076103 in 228.372
Created 1816420736 elements in 62.3082
to 452503716 in 228.733
Created 1816420736 elements in 64.1557
to 453593932 in 226.665
Dist 10 cnt 453825501 tot 1530939335 in 114.428
Created 1578799277 elements in 72.8051
to 1765369 in 205.557
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLS4Q3JDOXUFJKEPL77L2RS723AVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBTGA3DCMBYGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Here are the numbers through 9 for FTO with a fixed corner.
Note how the use of symmetry gives us a 4x memory savings.
***@***.***:~/twsearch$ build/bin/twsearch -M 240000 -t 1 -g -F
ftosymmfc.tws # This is twsearch v0.7.0-7-g8041062 (C) 2022 Tomas Rokicki.
# build/bin/twsearch -M 240000 -t 1 -g -F ftosymmfc.tws
Created new rotations D_F_L_BLv2 D_F_L_BLv'
Created new moves F' f' D' d' L' l' BL' bl'
Requiring 147 bits 20 bytes per entry; 24 from identity.
Rotation group size is 4
State size is about 4.45291 x 10^34 log2 115.1
Found 9 canonical move states.
Calculated canonical states in 0.000429153
Using sorting bfs symm and arrays.
Dist 0 cnt 1 tot 1 scnt 1 stot 1 in 0.000104904
Dist 1 cnt 4 tot 5 scnt 16 stot 17 in 2.59876e-05
Dist 2 cnt 52 tot 57 scnt 208 stot 225 in 5.29289e-05
Dist 3 cnt 672 tot 729 scnt 2688 stot 2913 in 0.000519037
Dist 4 cnt 8688 tot 9417 scnt 34752 stot 37665 in 0.00673699
Dist 5 cnt 112084 tot 121501 scnt 448336 stot 486001 in 0.0897801
Dist 6 cnt 1443106 tot 1564607 scnt 5772360 stot 6258361 in 1.22479
Dist 7 cnt 18550093 tot 20114700 scnt 74200286 stot 80458647 in 16.4117
Dist 8 cnt 238213975 tot 258328675 scnt 952855390 stot 1033314037 in 228.431
Dist 9 cnt 3059306582 tot 3317635257 scnt 12237225760 stot 13270539797 in
2786.72\
The ftosymmfc.tws was generated with:
node /Users/rokicki/cubing.js/dist/bin/puzzle-geometry-bin.js --ksolve
--rotations --optimize --fixcorner FTO
although these days I'd recommend using bun instead of node which allows
you to
directly run the source file cubing.js/src/bin/puzzle-geometry-bin.ts.
…-tom
On Tue, Feb 25, 2025 at 10:14 AM DougCube ***@***.***> wrote:
I'm running God's Number search on FTO. I googled some values and cannot
find anything.
It crashed from running out of memory and due to the bug under discussion,
I don't know how much I can even trust the results.
Should I have run this one without -F?
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 -M 65536 --moves U,R,L,F,Uw,Rw,Lw,Fw ../twsearch/fto/fto_doug.tws
Created new moves U' R' L' F' Uw' Rw' Lw' Fw' Us' Rs' Ls' Fs'
State size is about 3.14081 x 10^22 log2 74.7336
Requiring 104 bits 16 bytes per entry; 20 from identity.
Found 9 canonical move states.
Calculated canonical states in 0.000156164
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.00407e-05
Dist 1 cnt 16 tot 17 in 0.000580788
Dist 2 cnt 208 tot 225 in 0.000740051
Dist 3 cnt 2688 tot 2913 in 0.00116014
Dist 4 cnt 34752 tot 37665 in 0.00282788
Dist 5 cnt 448336 tot 486001 in 0.0180371
Dist 6 cnt 5772360 tot 6258361 in 0.191999
Dist 7 cnt 74200286 tot 80458647 in 2.49132
Dist 8 cnt 952855390 tot 1033314037 in 36.5187
Created 3267911600 elements in 20.7157
to 2755004926 in 88.2917
Created 3267911598 elements in 2.58311
to 3180184546 in 87.2667
! out of memory
real 3m58.196s
user 38m6.906s
sys 0m24.033s
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSY2DS3AUUCDXUC2SWD2RSXHVAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHEYDCNZYGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: DougCube]*DougCube* left a comment (cubing/twsearch#113)
<#113 (comment)>
I'm running God's Number search on FTO. I googled some values and cannot
find anything.
It crashed from running out of memory and due to the bug under discussion,
I don't know how much I can even trust the results.
Should I have run this one without -F?
# This is twsearch v0.6.6-143-gd3621b5 (C) 2022 Tomas Rokicki.
# ./twsearch -g -F -t 23 -M 65536 --moves U,R,L,F,Uw,Rw,Lw,Fw ../twsearch/fto/fto_doug.tws
Created new moves U' R' L' F' Uw' Rw' Lw' Fw' Us' Rs' Ls' Fs'
State size is about 3.14081 x 10^22 log2 74.7336
Requiring 104 bits 16 bytes per entry; 20 from identity.
Found 9 canonical move states.
Calculated canonical states in 0.000156164
Using sorting bfs and arrays.
Dist 0 cnt 1 tot 1 in 3.00407e-05
Dist 1 cnt 16 tot 17 in 0.000580788
Dist 2 cnt 208 tot 225 in 0.000740051
Dist 3 cnt 2688 tot 2913 in 0.00116014
Dist 4 cnt 34752 tot 37665 in 0.00282788
Dist 5 cnt 448336 tot 486001 in 0.0180371
Dist 6 cnt 5772360 tot 6258361 in 0.191999
Dist 7 cnt 74200286 tot 80458647 in 2.49132
Dist 8 cnt 952855390 tot 1033314037 in 36.5187
Created 3267911600 elements in 20.7157
to 2755004926 in 88.2917
Created 3267911598 elements in 2.58311
to 3180184546 in 87.2667
! out of memory
real 3m58.196s
user 38m6.906s
sys 0m24.033s
—
Reply to this email directly, view it on GitHub
<#113 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMOLSY2DS3AUUCDXUC2SWD2RSXHVAVCNFSM6AAAAABXYX7ZJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBSHEYDCNZYGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
That is interesting. I don't really know about using symmetry or why it's a good idea to add rotations in definition files yet. I ran the node command given and was able to generate that definition file myself. (I still had to install This definition file uses much different notation than my preferred. Comparing it to the one I created manually, this new one doesn't separate the two orbits of triangles pieces into different piece sets like I did, and I wonder how doing so would impact performance. I've attached my tws file for reference. I defined the middle slice moves, but I always run with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am running this search for god's number for a specific X-Cross (cross + first pair).
However, it has been running for over 6 hours. A similar search for Cross took only a few seconds.
./twsearch -g -t 11 xcross_UFR.twsSo far, it's output these position counts:
However, there are just 4 edge pieces and 1 corner piece involved so the total number of positions is 4,561,920 which I derive from the following product:
CP = 8
CO = 3
EP = 12 * 11 * 10 * 9
EO = 2^4
The problem is that the counts and totals given exceeds this number of positions.
Definition file is on stickers instead of pieces (i.e. no orientations):
The definition file has been throughly tested in solving scrambles and Ihave high confidence in it. But in case needed the ordering is:
The text was updated successfully, but these errors were encountered: