Archived from groups: rec.games.chess.computer (
More info?)
You would do a 8 ply search only, when you are in an actual KPPKPP
position.
To make it more clear: only do a 8 ply search if your root is an KPPKPP
position, and only in actual gameplay.
So you may have to do that 30 times per game, not 5 trilion.
If you use the tablebases in game, to replace evaluation, to wouldn't do a
8 ply search for position. You just trust the tablebase at face value.
Since it is right about 99% or so, it would outperform any evaluation
function.
The point is not to create a perfect tablebase, but one that outperforms
an evaluation based approach.
To reiterate the advantages:
- You only compute KPPKPP, KQPKPP, KQQKPP, KQPKQP, KQQPQP, KQQKQQ, and the
relevant 5 men databases, instead of the hunderds of K**K**. This saves an
enormous amount of computing and storage requirements.
- Except for KQQKQQ (which is highly symmetric) one could decompose the
pawn based tablebases into smaller ones (KQp[a3]KQQ), which reduces RAM
requirements. (making even KPPPKPP a possibility someday)
As a disadvantage, the resulting tablebases are less accurate, which may
or may not need to be compensated by a small amount of in game search.
Michel
ps: i mailed you by mistake, but you can find my email at:
http://www.xs4all.nl/~mdgsoft/email.gif
On Sun, 01 May 2005 18:59:51 +0200, Vincent Diepeveen <diep@xs4all.nl>
wrote:
> hello Michel,
>
> I understand you very correctly.
>
> There is in total in diep format 5T entries for the 6 men EGTB (includes
> also 5 vs 1).
>
> If you do 5,220,000,000,000 times a search of 8 ply, then you will need
> another 5 million years to perform that search. In fact that's 5 million
> years without i/o lookups in EGTBs.
>
> The time you spend at 1 position in an EGTB is real important.
> Performing a
> search at each position is just too slow.
>
> Vincent
>
> p.s. your email adress doesn't work, therefore i reply here.
>
>
> "Michel Grim" <asdfasfaa.n0spam@hotmail.com> wrote in message
> news
😱p.sp3t53un41cu7y@newszilla.xs4all.nl...
>> Hi Vincent,
>>
>> I think you misunderstood my point. The only heuristic i talked about,
>> is
>> that a pawn always promotes to a queen. Run the tablebase generator, and
>> most (99+ percent??) positions will have a higly accurate distance to
>> promotion evalution.
>>
>> You would only need to check if the database evalutation is actually
>> correct, when the position arises in actual gameplay. Doing a 8 ply
>> search will probably figure out if the database is correct. If the
>> search
>> doesn't find a win, but the tablebases do, trust the tablebase.
>>
>> Sure this will fail occassionaly, but think about what needs to happen
>> before it fails; for example, in case the tablebases indicate white has
>> a
>> win in say 9 ply. Then black should have a defense where promoting (9
>> plies away) to a lesser piece would cause the position to draw. White
>> would not have a way to prevent this promotion.
>>
>> Anyway, this is testable on smaller tablebases, but i don't have the
>> time.
>> So I was hoping somebody else would try
🙂
>>
>> Michel
>>
>> On Sun, 01 May 2005 13:49:21 +0200, Vincent Diepeveen <diep@xs4all.nl>
>> wrote:
>>
>>> It is the last 33p egtb that gets generated the KPPKPP obviously.
>>>
>>> Heuristics are too slow for EGTB generation. A single 6 men has many
>>> positions.
>>>
>>> Please note that KPPKPP is very easy to generate in comparision to
>>> other
>>> 6
>>> men,
>>> like KRPKBN for example.
>>>
>>>
>>> "Michel Grim" <asdfasfaa.n0spam@hotmail.com> wrote in message
>>> news
😱p.spwupbvj41cu7y@newszilla.xs4all.nl...
>>>> Actually, it is not that obvious that is it should be last; one could
>>>> produce a tablebase with the restriction that pawns can only promote
>>>> to
>>>> queens.
>>>>
>>>> While this not the true thing, and i am sure you can find thousands of
>>>> positions where there will be trouble, i believe this will work very
>>>> well
>>>> in practise. Shallow ab-search would find most situation where
>>>> promoting
>>>> to knight results in different evaluation.
>>>>
>>>> It is an order of magnitude less work.
>>>>
>>>> One could test this theory by comparing a true KPPKP against a
>>>> heuristic
>>>> KPPKP.
>>>>
>>>> Michel
>>>>
>>>> On Mon, 18 Apr 2005 23:03:47 +0200, Anders Thulin
>
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Facebook
Twitter
Instagram