Author: Heiner Marxen
Date: 09:09:16 11/18/01
Go up one level in this thread
On November 16, 2001 at 22:35:48, leonid wrote:
>On November 16, 2001 at 11:45:03, Heiner Marxen wrote:
>
>>On November 16, 2001 at 07:55:30, leonid wrote:
>>
>>>On November 15, 2001 at 20:23:02, Heiner Marxen wrote:
>>>
>>>>On November 15, 2001 at 12:05:46, Paul wrote:
>>>>
>>>>>On November 15, 2001 at 11:45:39, leonid wrote:
>>>>>
>>>>>>On November 15, 2001 at 09:44:55, Paul wrote:
>>>>>>
>>>>>>>On November 15, 2001 at 09:09:08, leonid wrote:
>>>>>>>
>>>>>>>>[D]2nkN3/2nqN3/2rrbb2/RBqQQqQQ/RBqNPqPQ/2qpqp2/3B4/3K4 w - -
>>>>>>>>
>>>>>>>>Please indicate your result.
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>Leonid.
>>>>>>>
>>>>>>>Hi Leonid,
>>>>>>
>>>>>>Hi!
>>>>>>
>>>>>>>Haha! .. that was a surprise when I saw what Pretz came up with:
>>>>>>>
>>>>>>>1. Nexc6+ Qcxc6 2. Qgxf6+ Qxf6 3. Qexf6+ Qxf6 4. Qxf6+ Qe7 5. Qxe7+ Nxe7 6.
>>>>>>>Nxe6+ Nxe6 7. Ra8+ Nc8 8. Rxc8+ Kxc8 9. Nxd6+ Kd8 10. Ra8+ Qxa8 11. Qxa8+ Qc8
>>>>>>>12. Qe8+ Kc7 13. Qexc8+ Kb6 14. Qa5#
>>>>>>>
>>>>>>>So a mate in 14! I think I must have a bug ...
>>>>>>
>>>>>>I don't think so. It is mate in 13. Verified it 12 moves deep by brute force to
>>>>>>be sure. Easy branching factor. Found mate in 13 by selective. Your, probably,
>>>>>>went just one move deper to find its mate. Good result.
>>>>>
>>>>>Just after I posted my message mine also found a mate in 13 ... I was just too
>>>>>quick, but I had to laugh out loud because I know you don't post mates over 13
>>>>>moves deep! I thought maybe you had changed your solver.
>>>>>
>>>>>>I see that you have almost no competition here. Your selective look like to be
>>>>>>very effective. I still hope that somebody will come with Chess Master solution
>>>>>>to see better your and mine position.
>>>>>>
>>>>>>What was your time here?
>>>>>
>>>>>07:28 WM13 13 Nexc6+ Qcxc6 Qgxf6+ Qxf6 Qexf6+ Qxf6 Qxf6+ Ne7 Ra8+ Nxa8 Rxa8+
>>>>>Qxa8 Qxa8+ Qcc8 Ba5+ Qcc7 Bxc7+ Qxc7 Nxe6+ Rxe6 Qhd5+ Rd6 Qfxd6+ Qxd6 Qxd6#
>>>>>
>>>>>So no bug, mine just took the long way home first ...
>>>>
>>>>Hi,
>>>>
>>>>Chest confirms the above: #13 with a unique key move:
>>>>
>>>>PV: Nexc6+ Qcxc6 Qgxf6+ Qxf6 Qhxf6+ Qxf6 Qxf6+ Qe7 Qxe7+ Nxe7 Nxe6+ Nxe6 Ra8+
>>>>Nc8 Rxc8+ Kxc8 Nxd6+ Kd8 Nxc4+ Qxd5 Qxd5+ Kc8 Ba6+ Kb8 Qb7#
>>>>
>>>>(K7/600, 30MB hash, 57.2 minutes)
>>>># 1 0.00s 0kN 0.87 1- 0
>>>># 2 0.00s 0kN 1.00 1- 0
>>>># 3 0.01s 0kN [ 7.42] 0.92 63- 0
>>>># 4 0.03s [ 3.00] 2kN [ 3.71] 1.12 190- 0
>>>># 5 0.09s [ 3.00] 6kN [ 3.29] 1.53 348- 0
>>>># 6 0.25s [ 2.78] 18kN [ 3.12] 2.03 861- 0
>>>># 7 0.83s [ 3.32] 63kN [ 3.43] 2.51 2897- 0
>>>># 8 1.98s [ 2.39] 155kN [ 2.46] 3.12 6827- 0
>>>># 9 6.11s [ 3.09] 489kN [ 3.17] 3.69 22121- 0
>>>># 10 23.47s [ 3.84] 1850kN [ 3.78] 3.87 100289- 1
>>>># 11 112.24s [ 4.78] 8475kN [ 4.58] 4.60 516316- 6868
>>>># 12 501.96s [ 4.47] 31935kN [ 3.77] 4.53 3036282- 2249851
>>>># 13 3434.74s [ 6.84] 208426kN [ 6.53] 4.69 20984850- 20198419
>>>>
>>>>>>Mine by brute force took 1 hour and 50 min for 12 moves to say "No". Selective
>>>>>>in 13, took 9 seconds.
>>>>>
>>>>>That's pretty fast ... :)
>>>>
>>>>... but not yet optimal :-))
>>>
>>>Hi, Heiner!
>>>
>>>It was very interesting for me in this position see your and mine program do
>>>work without hash on the same computer. Everything went actually in almost twin
>>>brothers indentical way.
>>
>>That is in fact quite interesting!
>>Note also, that completely without hash Chest does some not so clever
>>things. Especially when the EBF is small, the compeletely recursive
>>iterative deepening at all levels can be bad. In this case it may not
>>hurt so much, but last time I tried completely without hash I was
>>somewhat disappointed.
>>
>>But then... hash is in there for a long time now, and even with very low
>>memory a small hash does help a lot. So I decided not to change the
>>program just for the case that we work without hash. That is more of
>>a debugging help than a real feature.
>
>Trying your program without hash have for me very practical interest. I expected
>to see where really my program must be speeded up. Now I see, for sure, that it
>is where I found it even when you came with hash result - specialized moves.
>Trying without hash have also second reason that you mentioned - hash could be
>sometime reason for loosing speed when number of moves is limited. This I was
>able to observe before with Rebel by putting his hash "on" and "off". When
>number of moves is below 5, intensive hard disk usage can make loose some time.
Small depths do not gain from the hash table. From Chest:
static Bool
job_dep_wants_acm( int jt, int depth )
{
/*
* For a repeated position we need at least 4 plies (two full moves).
* Since we ask at the start of "do_ana()", where the attacker is
* to move, an additional preply turns out to make no difference.
*/
switch( jt ) {
default:
case JT_normal:
case JT_stalemate:
case JT_selfmate:
case JT_selfstalemate:
break; /* take default rule below */
case JT_helpmate:
case JT_helpstalemate:
return depth >= 3; /* since storing jobs of depth >= 1 */
}
return depth >= 4; /* since storing jobs of depth >= 2 */
}
>I needed as much, as possible to speed my solver since this could give me some
>ideas for my chess playing part. Mate solver is not my goal. Already, after
>writing my chess playing part, I went back to my solver and speeded it up. It
>could be that other way around exist. Speeding first mate solver and later
>speeding chess program with found recipies. And beyond this, it is only mate
>solving part that can give exact idea of where raw speed of given program stays.
>If raw speed is too low there are no visible incentive to even go into
>finalizing and refining initially weak program.
Hmm... according to my experience, there is a ping/pong game going on.
Some initial speed is needed to make experiments about the properties of
larger searches, and what can help there. Improving that way results
in better speed and/or a different search tree, and the game starts over.
>>> Your had only advantage in branching factor just after
>>>9 move. When mine was already 11.6 between 11 and 12 move, your was still very
>>>stable and around 5.
>>
>>And just after that point your NPS seems to jump up by a factor around 2.
>>Indicating more searching, and less "whatever else the program does".
>>
>>> Time for 12 moves was practially the same considering 12
>>>move depth. Mine 1 hour and 49 min and your 3h 54 min. Considering that my
>>>program is done on Assembler your went just slightly better that mine.
>>
>>Yeah, sure. Even in C I still could do a lot of micro optimization,
>>e.g. to speed up the execution of moves. Since you are even assembler,
>>a better basic speed at your side is logical and expected.
>>[Since Chest still is "experimental" I do not do much micro-optimization,
>>since that tends to fix the design, and I like it to be flexible.]
>
>I doubt very much that you even need right now to change something in your
>program. You can do all this later.
I agree completely! That was the basic idea: work/experiment with the
algorithms and data structures, first. Optimize later (or when felt
necessary). Currently I have more than enough ideas to experiment with.
> Program is already well beyond of everything
>that I tried. It should be only made accessible and find it way into every
>existing chess program. Its compatibility and versatility make it ideal to be
>used immediately.
>
>Only because I don't want to denigrate somebody else work that I don't want to
>name other mate solving engin that I have inside of one of my professional
>program. So, when last position I tried only 4 moves deep that engin took 44
>seconds to respond. Given engin use 1 M of memory. Your, without hash, took 0.17
>sec. Huge difference! It will only grow if search will go deeper.
Yes, huge indeed. What you see there most probably is a "trivial design",
containing just the absolutely necessary ingrediants, and not much more.
That is the classic starting point: a "working" program.
>>That Chest even without hash can do better is due to the non-trivial
>>features based on its attack information, where Chest tries to replace
>>search by other arguments. Well, that is a guess, of course.
>>
>>The increased EBF deeper in the tree normally is due to "better chances"
>>to mate, i.e. more check moves around etc. Chest is quite good in
>>detecting when there _really_ are mates around, or, to be exact,
>>when they not really are there, and still avoiding search in the last plies.
>>
>>>My time was:
>>>
>>>Depth in moves Time Branching factor. NPS
>>>
>>>4 moves 0,05 sec
>>> 2
>>>5 moves 0.10 sec 44k
>>> 2.8
>>>6 moves 0.27 sec 39k
>>> 2.8
>>>7 moves 0.769 sec 42k
>>> 2.64
>>>8 moves 2.03 sec 57k
>>> 4.16
>>>9 moves 8.46 sec 74k
>>> 6.4
>>>10 moves 54.78 sec 101k
>>> 10.5
>>>11 moves 9 min 27 sec 116k
>>> 11.6
>>>12 moves 1 h 49 min 32 sec 118k
>>
>>Now, if you could say, what makes the EBF deeper in the tree so large,
>>while it is small near the root... you may find an idea how to speed up.
>>
>>Also, according to this data, your program, extended by a hash,
>>may be a real contender to Chest, if not even faster... huh, did I really
>>say that? :-))
>
>Forget about contenders, you don't have them! Only try to make your engin
>accessible for everyone.
Yes! Sir! :-))
Skøl,
Heiner
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.