Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Very easy mate to solve.

Author: leonid

Date: 16:46:41 12/24/01

Go up one level in this thread


On December 24, 2001 at 16:27:29, Heiner Marxen wrote:

>On December 24, 2001 at 15:09:45, leonid wrote:
>
>>On December 24, 2001 at 13:30:10, Heiner Marxen wrote:
>>
>>>On December 24, 2001 at 06:47:47, leonid wrote:
>>>
>>>>On December 23, 2001 at 11:51:53, Heiner Marxen wrote:
>>>>
>>>>>On December 23, 2001 at 08:18:16, leonid wrote:
>>>>>
>>>>>[snip]
>>>>>
>>>>>>Probably our chess solving part is very close in response, even if your initial
>>>>>>speed is much better. How we ever come to this closeness is a mystery for me.
>>>>>>Few times I tryed to find some visible explanation for this but each time I
>>>>>>could see later that my explanation was wrong. Fact is that our two solvers
>>>>>>stays completely aside from main part of mate solvers in "heavy positions".
>>>>>
>>>>>That is not so much of a mystery to me:  our two programs are the only
>>>>>non-trivial, brute-force, full-width mate solvers I know of.  I.e. these two
>>>>>programs share a certain approach/algorithm which others don't do.
>>>>>[Alybadix may be an exception (I just don't know)]
>>>>
>>>>I am not that sure about this since I used special mate solver inside of Hiarcs
>>>>package. I presume that this specialized engin use brute force and full-width
>>>>search. It have nothing like selective search. Its work also give impression
>>>>that it make its hunt for mate in the same way like your program do. It look for
>>>>it at constantly growing depth. In the same time, I found no visible difference
>>>>between this engin branching factor for heavy positions and some other good
>>>>chess programs, like Genius, when those programs explicitly look for mate.
>>>
>>>(I do not have Hiarcs and have never used its mate solver, so I'm guessing)
>
>
>Hello Leonid!

Hello, Heiner!

>>I bought my Hiarcs around 2 years ago and it went with many engins inside. One
>>of those engins is Mate 2.0. It cold be that you will be able to find this
>>program on Web.
>
>Since I have a Linux-only box I suspect it will not run here.
>Most commercials only have Windows versions.  From the icdchess store I see
>that Hiarcs 7.32 is avalaible for Windows 95, Windows 98, or Windows NT 4.0.
>Since I'm not going to install any Windows on my box, I'm not able to
>try Hiarcs myself.  Such is life ;-)
>
>>It is after seeing mate solving engin that I was puzzled why your is not there.
>>Your is already compatible in many ways and you can ajuste even farther if this
>>will be needed.
>
>I don't know why nobody appears to be interested to integrate Chest.
>Maybe they just do not know about it, or dislike the non-commercial nature
>of it, or maybe just do not care enough about mate solving to even try.

I don't know for sure but I think there exist two reasons :

1) Not that big interest in solving mate positions.

2) Your mate solver is almost unknown because of its complex speech manner.

Still, I am sure that once your engin will become more graphic oriented, or
integrated into some chess progam with graphics it will become gradually
permanent component of every respectable chess program. Interest in solving mate
position is not big but it is permanent. Inclusion of mate solving engin in
leading Hiarcs program, two years ago, is visible prove to this obvious truth.

>>>So the Hiarcs mate solver is "brute-force" and "full-width".  I suspect it is
>>>not non-trivial, i.e. not many hours of programming/testing/development
>>>have been spent to speed it up.
>>>
>>>Whether this is correct or not should be possible to decide by the "basic speed"
>>>(time needed for say a mate in 4) and the EBF, as compared to your and my
>>>values.  If the basic speed of off by a factor of 10 or more... there surely
>>>is something to improve easily.  And if the EBF is consistently say twice as
>>>large, dito.
>>
>>
>>Today I looked into one position where I could see that our programs do quit
>>differently its inner work. In it your program went almost instantly where mine
>>was slow in responding.
>>
>>[D]RqqkqqqR/QPqbbqPQ/rNPBBPNr/PnpQKpnP/8/8/8/8 w - -
>>
>>8 moves deep mine took already 11 min and 28, when you only 8.62 seconds.
>>Conditions and computer are identical.
>
>Interesting!  A factor of 79.8!
>
>On my K7/600 I did some experiments with this position:
>
>Chest 3.19 without hash:   8.44 secs
>Chest 3.19 with 42MB hash: 3.49 secs  (says speed=2.15, really is 2.418)
>Chest 3.23 without hash:   7.55 secs
>Chest 3.23 with 42MB hash: 3.24 secs  (says speed=2.13, really is 2.33)
>
>42 MB was not necessary, 1MB would have been enough.
>3.23 is my current development version.
>
>Why Chest here is much faster than your program I can only guess.
>For version 3.19 without hash (what you most probably did use),

Yes, I tried your program without any hash. Result was excellent.

>which is most comparable to your own program, I will give some
>info (statistics) and some comments,
>so you may come up with an idea, what could be improved for you.

>Timing info for 3.19:
>#  1     0.00  1.00          0-        0
>#  2     0.00  1.00          0-        0
>#  3     0.00  1.00          0-        0
>#  4     0.02  1.00          0-        0
>#  5     0.08  1.00          0-        0
>#  6     0.36  1.00          0-        0
>#  7     1.65  1.00          0-        0
>#  8     8.44  1.00          0-        0
>
>Timing info for 3.23 contains more details (that may help):
>#  1      0.00s                 0kN           1.00          0-         0
>#  2      0.00s                 0kN [ 25.00]  1.00          0-         0
>#  3      0.01s                 0kN [  5.54]  1.00          0-         0
>#  4      0.02s [  2.00]        1kN [  4.42]  1.00          0-         0
>#  5      0.09s [  4.50]        5kN [  4.17]  1.00          0-         0
>#  6      0.33s [  3.67]       22kN [  4.24]  1.00          0-         0
>#  7      1.48s [  4.48]       97kN [  4.48]  1.00          0-         0
>#  8      7.55s [  5.10]      482kN [  4.95]  1.00          0-         0
>
>The refutation table for 3.19 (command line option "-r") shows the top two
>plies, and the computed sub-result:
>
>refu  1: gxf8=Q  Qxf6+   [  7-]
>refu  2: gxf8=R  Qxf6+   [  7-]
>refu  3: fxe7+   Qf8xe7  [  7-]
>refu  4: bxc8=Q+ Qcxc8   [  7-]
>solu          1: Bxc8    [  1+]
>refu  5: bxc8=R+ --      [  7-]   prom beaten
>refu  6: Bxc7+   Qbxc7+  [ 63-]
>refu  7: gxf8=N  Qxf6+   [  7-]
>refu  8: gxf8=B  Qxf6+   [  7-]
>refu  9: cxd7    Qxf6+   [  7-]
>refu 10: bxc8=N  Qxf6+   [  7-]
>refu 11: bxc8=B  Qxf6+   [  7-]
>refu 12: Nxe7    Qxf6+   [  7-]
>refu 13: Nxf8    Qxf6+   [  7-]
>refu 14: Nf4     Qxf6#   [ 63-]
>refu 15: Nh4     Qxf6+   [  7-]
>refu 16: Na4     Qxf6+   [  7-]
>refu 17: Nxc8    Qxf6+   [  7-]
>refu 18: Nc4     Qxf6+   [  7-]
>refu 19: Nxd7    Nf3+    [  7-]
>refu 20: Bxf7    Nf3+    [  7-]
>refu 21: Bxf5    Qxf6+   [  7-]
>refu 22: Bxd7    Qxf6+   [  7-]
>refu 23: Rxg8    Qxf6+   [  7-]
>refu 24: Rxb8    Qxf6+   [  7-]
>refu 25: Qxh6    Qxf6+   [  7-]
>refu 26: Qxg8    Qxf6+   [  7-]
>refu 27: Qxc5    Qxe6+   [  7-]
>refu 28: Qd4     Qxe6+   [  7-]
>refu 29: Qd3     Qxe6+   [  7-]
>refu 30: Qd2     Qxe6+   [  7-]
>refu 31: Qd1     Qxe6+   [  7-]
>refu 32: Qc4     Qxd6+   [ 63-]
>refu 33: Qb3     Qxd6+   [ 63-]
>refu 34: Qa2     Qxd6+   [ 63-]
>refu 35: Qe4     Qxe6+   [  7-]
>refu 36: Qf3     Qxe6+   [ 63-]
>refu 37: Qg2     Qxe6+   [  7-]
>refu 38: Qh1     Qxe6+   [ 63-]
>refu 39: Qxa6    Qxf6+   [  7-]
>refu 40: Qxb8    Qxf6+   [  7-]
>refu 41: Kxf5    Qxf6+   [  7-]
>refu 42: Kf4     Bxd6+   [  7-]
>
>Move counts and EBFs from top down (indexed by depth to go):
>mvx  8:        37        38  [37.000  1.027]      4
>mvx  7:       147       151  [ 3.868  1.027]     15
>mvx  6:       685       703  [ 4.536  1.026]     53
>mvx  5:      3362      3409  [ 4.782  1.014]    241
>mvx  4:     14940     15275  [ 4.383  1.022]    716       3
>mvx  3:     69781     71058  [ 4.568  1.018]
>mvx  2:    254941     22806  [ 3.588  0.089]
>mvx  1:     24154         0  [ 1.059       ]
>
>Black's EBF is only slightly greater than 1, i.e. the selected defense moves
>were mainly successful.
>White's EBF is consistently smaller than 5, indicationg that black's defense
>moves not only are successful, but also restrict white's set of legal moves
>quite nicely, most probably by checks.
>
>Also, blacks EBF inside the mate-in-2 is below 0.1, indicating quite efficient
>"answer heuristics" especially for that level.
>
>Finally, white's EBF for the mate-in-1 is unusually large (1.059).  Of these
>nearly 13% really are mate moves.  I'm not sure whether Chest here is doing
>well or not.
>
>Statistics for "normal" move generator calls (not for mate move search):
>mg     90247 W; inchk:      4616 none     85451 one       180 double
>mg    259688 B; inchk:    217411 none     41468 one       809 double
>As already suspected, white is in check most of the time (94.9%),
>while black is in check only 16.3%.
>
>Otherwise I did not note anything unusual in Chest's statistics.
>Name the missing info and I will try to provide it :-)


I actually looked into all useful data of your program before even putting this
positions here. Was very surprise in finding that time of search for 5 moves was
less that time for 4 moves. Your time for 4 moves was 0.11 sec and for 5 only
0.05 sec. Also big difference in our time is due to some sudden jump in
branching factor that happened in mine after move 6. Move 6 was still 1.5 sec.
for my program

The most curious in this position was also the fact that it was not so much
lowers specialised plies that gave you advantage but your branching factor in
upper plies. Your time for 4 move was 0.11 sec, when mine was 0.05 sec.

Cheers,
Leonid.

>Cheers,
>Heiner



This page took 0.19 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.