Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: SEE for forward pruning in Q. Search and nullmove cooking problems

Author: blass uri

Date: 22:10:14 08/11/99

Go up one level in this thread


On August 11, 1999 at 13:36:53, Vincent Diepeveen wrote:

>On August 10, 1999 at 21:55:29, Robert Hyatt wrote:
>
>>On August 10, 1999 at 18:42:58, Tom King wrote:
>>
>>>On August 09, 1999 at 20:41:50, Robert Hyatt wrote:
>>>
>>>>On August 09, 1999 at 17:51:01, Tom King wrote:
>>>>
>>>>>On August 08, 1999 at 21:35:46, Robert Hyatt wrote:
>>>>>
>>>>>[snip]
>>>>>>
>>>>>>
>>>>>>I've been doing a 'hybrid' for nearly a year...  R=3 fairly close to the
>>>>>>root, R=2 beyond some threshold that I don't remember what it is...
>>>>>>
>>>>>>
>>>>>
>>>>>Interesting.. better than pure R=2 or pure R=3? I did some experiments a while
>>>>>back, using R=3 on the opponent's move, and R=2 on the computers move (idea
>>>>>being - let's not cover up the opponent's threats, and if we miss some of our
>>>>>threats, well, so be it). But it was more or less a 'wash'.
>>>>
>>>>
>>>>I started playing with this after Paris, as someone said that Frans (or someone)
>>>>was fiddling around with R=3.  Bruce and I played a few games one night with
>>>>Ferret vs Crafty, with bruce using R=3, and we saw _no_ gross mistakes on his
>>>>part.  In fact, we couldn't tell the difference (at least R=3 was not making
>>>>mistakes that R=2 wasn't).
>>>>
>>>>But I never felt comfortable with raw R=3, as R=2 causes more than enough
>>>>problems already, thank you very much.  :)
>>>>
>>>>Ernst is writting an ICCA paper describing some experiments he did with this
>>>>(totally unconnected with my tests).  Wait for his paper to hit the journal as
>>>>he has some good data...  And I am not yet sure that this is a good idea, but I
>>>>have been running it a good while and it has been in the distributed Crafty for
>>>>quite a while as well and no one has complained.  Of course, now that everyone
>>>>knows, look out.  :)
>>>
>>>One thing's for sure - I'm sure there's a lot more we could all be doing with
>>>the null move. Playing around with different values of R, depending on depth in
>>>the tree, alpha and beta etc. etc. I look forward to this paper. Ernst has been
>>>productive of late..I'm sure I'm not the only one to enjoy reading his articles.
>>>[even if his damn program does kill mine at the WCCC ;-)]
>>>
>>>Cheers,
>>>Tom.
>>
>>
>>If you want to play around, here's another idea I have on my 'to-do' list:
>>
>>at present I 'break' the search into two 'chunks'.  the part near the root
>>uses R=3, the rest uses R=2. Something tells me this might be made much more
>>dynamic than that...  ie R=4, then 3, and finally 2.  But rather than some
>>static divisor as I have now, make this dynamic so as you go deeper, you use
>>bigger R values near the root, etc...
>>
>>Seems reasonable.  Whether it will work or not, we won't know until we try
>>it...
>
>It works great for testsets, but i care shit for those now.
>I've thrown such tricks completely out of my DIEP now,
>and the reason is that hashtable makes thing hazardeous:
>some positions it will not nullmove until it gets there, then
>score based upon a R=4 will be stored in position X.
>Now suppose in an important line we get to that position X
>using transposition, then first nullmove we use R=4, where
>we would *expect* it to find it a ply sooner.
>
>I go think then there is a bug in my DIEP, but there isn't, you
>just depend upon happiness of hashtable, and that idea sucks for me,
>so i left the idea of solving testsets.
>
>Good example is in the BS2830 test set: Kg3.
>Of course not with the best will in the world a program will get with
>transposition to the position where the king is at h6 and position
>the same. Not a single program will search so many BS that it gets
>to that position at a lower depth, and then by means of transposition
>finds it at a smaller depth than possible.
>
>2r2rk1/1bpR1p2/1pq1pQp1/p3P2p/P1PR3P/5N2/2P2PPK/8 w - - 0 2 Kg3 15
>
>what nullmove programs need to see here:
>
>Kg3
>NULL
>Kf4
>NULL
>Kg5
>NULL
>Kh6
>..
>qg7 mate in qsearch.
>
>Now programs not doing checks in qsearch will null also at the '..'
>programs having mating extensions will extend after Kh6 will be made.
>
>Yet programs need to survive 3 nullmoves.
>So without cooking for this you need:
>Kg3 NULL Kf4 NULL Kg5 NULL Kh6 ..
>1    2    3   4    5   6    7   8
>
>so 8 ply + 3*r = 14 ply at least.

This example shows that the null move is not a very good idea.
If you need more 3*2=6 plies to see the right move and there is no
zunzwnag(playing no move cannot help black) then you are not close to see
everything to depth n-r with null move.

I thought depth n when you use null move with R=2 means that except for
zunzwangs you analyse everything to depth n-2 and I see that it is not the case.

Uri



This page took 0.01 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.