Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Easy mate

Author: Dieter Buerssner

Date: 12:28:07 09/14/03

Go up one level in this thread


On September 14, 2003 at 05:31:11, Rafael Andrist wrote:

>On September 13, 2003 at 18:20:56, Dieter Buerssner wrote:
>
>
>>My TB-generator does confirm this more or less. It minimaxes the distance
>> to the next pawn push or capture, and the result is: lost in 52
>> (which will be set to draw, when my testing phase is finished).
>
>The DTZ depth is 51 according to the tables I use, but maybe you just count the
>depth differently.

Indeed, I was counting different. Actually I have 51 in the TB, but I used for
some reason a macro to convert the intrinsic TB-score to some better readable
score. This macros sets "LOST_IN_ZERO" to -1 (because draw will get zero). This
explains my wrong number. In the lines we posted (I did not check, if they are
identical) the pawn push was at the same move.

>In a pawnless endgame with DTM-optimal = DTC-optimal play
>with two DTC phases the sum of DTC at the beginning of each phase should equal
>DTM. Similar for DTZ, but more difficult to check.

I read this a few time, but did not get it. With "DTM-optimal = DTC-optimal": Do
you only want to consider positions, where this really gives the same line?
Seems not so easy to see, when this is the case - because often, you will have
several equal good alternatives with any metrics, and one would need to check
all? Or do I misunderstand much more.

What do you exactly mean by the two DTC phases?

>I'm sure you aware of this, but note that setting DTZ>50 to a draw after the
>generation process is not very useful as you miss the biggest number of draws,
>because they have DTZ<=50.

Don't be sure, that I am aware of it :-( Actually, I don't understand what you
mean. How could one miss draws? Of course, probing is a little bit trickier with
the DTZ (especially, when one takes into account, that the opponent will not
play optimal). One has to look at the 50 moves rule counter as well, in
positions, where it is not zero. But at the conversion points (including pawn
pushes) it will always be zero (so, for the generation process, this should be
no problem).

>Here, Black can even allow a pawn push at move 7 (see my other post) and still
>draw in the next phase.
>
>>BTW. Generating the knnkp database took 15 minutes and used less than 40 MB of
>>RAM. When I wrote up a bit more code, I can show the line.
>
>This is very impressive! You must have found an interesting trick to generate
>the database in 15 minutes only.

No real tricks, I think. I am using a method simiar to the one published by Wu
and Beal. The article is available on the Web somewhere (it was mainly focussing
on Chinese chess).

The longest (time used) TB I generated was KQPKQ, which took a bit over one
hour. There, most time was used in initialization phases. I think it could be
speeded up by a very significant amount by more efficient lookup of the
conversion (and this includes pawn pushes for me) cases.

>I'm basically using the Nalimov code, with modifications by Marc Bourzutschky.
>This has the advantage of compatibility. With some minor changes (pawn
>push/capture recognition) all engines will be able to use the database.

Indeed, that is a big advantage. I had the ambition, to do it fully with own
code. Now my HD is totally overfilled, and my experiments stopped for a while.
The generator code is rather general - for new TBs I have to mainly write two
functions for index calculation and reversing it. The functions are parameters
to the generator code using them via pointers. But for example, I have not
decided yet, how to index ep. Also, lookup, caching, etc. are not there at all
yet, or very basic. But it was fun until now, to try it. The main motivation was
the 50 moves rule, that is ignored by all other currently available TBs to my
knowledge.

Regards,
Dieter






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.