Author: Heiner Marxen
Date: 14:58:42 10/28/01
Go up one level in this thread
On October 28, 2001 at 17:23:13, José Carlos wrote:
>On October 28, 2001 at 17:12:30, Heiner Marxen wrote:
>
>>On October 28, 2001 at 15:37:09, José Carlos wrote:
>>
>>>On October 28, 2001 at 14:04:54, Heiner Marxen wrote:
>>>
>>>>On October 28, 2001 at 13:33:17, Robin Smith wrote:
>>>>
>>>>>On October 28, 2001 at 10:55:27, José Carlos wrote:
>>>>>
>>>>>>On October 28, 2001 at 06:53:06, José Carlos wrote:
>>>>>>
>>>>>>> I managed to make EGTB's work properly except in positions with pawn/s. I
>>>>>>>checked the tablebases by making crafty think in some positions; it worked
>>>>>>>perfectly. For example, in the following position it returns draw:
>>>>>>>
>>>>>>>[D]8/7k/5K2/8/2B5/8/7P/8 b - - 0 31
>>>>>>>
>>>>>>> Now, my program says black is checkmated!
>>>>>>> I tested lots of positions without pawns, and worked fine, so I guess I have a
>>>>>>>bug somewhere related to pawns, but tracing the program I can't see anything
>>>>>>>strange.
>>>>>>> Can anyone please try this position and trace it?
>>>>>>> My numbers:
>>>>>>> IDescFindFromCounters (rgiCounters) returns 24
>>>>>>> PfnIndCalc(iTb,side) (psqW,psqB,sqEnP,fInvert) returns 1557728
>>>>>>> L_TbtProbeTable (iTb,side,ind) returns 32766 (the checkmate!!)
>>>>>>>
>>>>>>> Do you guys get the same numbers? Anyone got a clue what I'm doing wrong?
>>>>>>>Should I post some code so you can check?
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> José C.
>>>>>>
>>>>>> As I started the amalisys, the given data is for the position after ...Kh6
>>>>>>
>>>>>> José C.
>>>>>
>>>>>Hi Jose,
>>>>>
>>>>>The position before Kh6 is drawn. The position after Kh6 white wins.
>>>>>
>>>>>For example:
>>>>>
>>>>>1... Kh6?? 2. Bd3 Kh5 3. h3 Kh4 4. Bf5 Kh5 5. Kg7 Kg5 6. Bg4 Kh4 7. Kh6 Kg3 8.
>>>>>Kg5
>>>>>
>>>>>Analyzed without TB's, so there may be a faster win, but you get the idea.
>>>>>
>>>>>Robin
>>>>
>>>>For the position after Kh6:
>>>>[D]8/8/5K1k/8/2B5/8/7P/8 w - -
>>>>Crafty (18.10) with 4-piece EGTBs gives (immediately):
>>>>Black(2): setboard 8/8/5K1k/8/2B5/8/7P/8 w - -
>>>>1. Bd3 Kh5 2. Bf5 Kh4 3. h3 Kh5 4. Kg7 Kg5 5. Bg4 Kf4 6. Kg6 Kg3
>>>>7. Kg5 Kf2 8. Kf4 Ke1 9. Ke3 Kf1 10. Bf3 Ke1 11. h4 Kf1 12. h5 Kg1
>>>>13. Kf4 Kf1 14. h6 Ke1 15. Ke3 Kf1 16. h7 Ke1 17. h8=Q Kf1 18. Qh1#
>>>>
>>>>i.e. Crafty thinks it is a mate in 18. Chest confirms. With debug mode
>>>>enabled it tells some details:
>>>>
>>>>% EGTB found tables for max 4 pieces
>>>>% EGTB uses 1542.1K memory internally
>>>>> eg_probe FEN: 8/8/5K1k/8/2B5/8/7P/8 w - -
>>>>= eg_probe cntarr=1,0,1,0,0,0,0,0,0,0,
>>>>= eg_probe iTb=24
>>>>= eg_probe fInvert=0
>>>>= eg_probe sqarr:
>>>> [0][1] = 17 = 17
>>>> [0][2] = 200
>>>> [0][3] = 164535332 = 32
>>>> [0][4] = 20000000
>>>> [0][5] = 0
>>>> [0][6] = 55 = 55
>>>> [1][1] = 0
>>>> [1][2] = 27777706674
>>>> [1][3] = 1001657427
>>>> [1][4] = 20000000
>>>> [1][5] = 10000263340
>>>> [1][6] = 57 = 57
>>
>>Correction: the above numbers are octal, i.e. 17-->h2, 32-->c4 55->f6 57->h6
>>
>>>>= eg_probe sqep=177
>>>>= eg_probe ind=3398635
>>>>= eg_probe v=32749
>>>>< eg_probe q=39
>>>>
>>>>EGTB value = 39 = #18
>>>>
>>>>[Don't worry about those large numbers above, they are meaningless]
>>>>While our programs agree on the EGTB to use (24) they do not agree about the
>>>>calculated index to use: yours=1557728, mine=3398635.
>>>>[My sqep above is octal, the other values are decimal.]
>>>>
>>>>Hope this helps.
>>>>Heiner
>>>
>>> Yes, you are right. I was hurry to post, because I had to go out of home for a
>>>while and I felt I needed some help for my return.
>>> Of course, after Kh6 the postion is lost, but anyway, I get -mate in 1, which
>>>is not correct.
>>> Additionally, Dieter's post in Winboard Forum shows he gets the same number as
>>>you.
>>> Here my data:
>>>
>>> rgiCounters={1,0,1,0,0,0,0,0,0,0}
>>> psqW={0,55,0,34,0,0,21}
>>> psqB={0, 0,0, 0,0,0,23}
>>
>>Ha! Here is the problem. Assuming that you show decimal numbers, it makes
>>sense, but you got it upside/down, i.e. you count a8 as 0, h8 as 7,
>>a7 as 8 etc, whereas you are supposed to start with a1=0, h1=7, a2=8 etc.
>>
>>What you asked effectively was
>>[D]8/7P/8/2B5/8/5K1k/8/8 w - -
>>
>>which in fact is mate in 1.
>>Just flip the rows, and you should get some correct answers.
>>
>>From your followup I see that you like my coding trick :-)
>>As far as I have tested it with Chest it seems to work quite well,
>>so that should not be the problem.
>>
>>Happy EGTB probing!
>>Heiner
>>
>>
>>> iTb=24
>>> side=0
>>> sqEnP=127 (XX)
>>> fInvert=0
>>> ind=1557728 (?????????????????)
>>> Result=32766
>>>
>>> Correct numbers (before ind)?
>>>
>>> José C.
>
> Thank you Heiner. I solved it looking at your numbers, just a minute after
>posting mine :)
Fine :-)
That upside/down also explains, why you had problems only in the presence
of pawns. Well, with castling you could have problems, too, if only
castling would be handled in the tables :-)
> Yes, I do like your trick. Works nicely. I must admit I didn't understand all
>your code, but it gave me exactly what I needed: a starting point. Something to
>begin with. And in one day (today) I've been able to do what I thought it was
>impossible :)
>
> José C.
I'm glad I could help! :-))
Those are the merits of open source: we learn from each other.
I also did not start with nothing, of course I had a look into Crafty.
But then I insisted to understand every bit of code I write myself.
Quite a usual approach, I suppose.
CU,
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.