Author: Robert Hyatt
Date: 20:39:01 08/10/04
Go up one level in this thread
On August 10, 2004 at 22:08:15, Stuart Cracraft wrote:
>On August 10, 2004 at 18:50:14, Robert Hyatt wrote:
>
>>On August 10, 2004 at 17:36:53, Uri Blass wrote:
>>
>>>On August 10, 2004 at 14:47:02, Robert Hyatt wrote:
>>>
>>>>On August 10, 2004 at 13:42:24, Eric Oldre wrote:
>>>>
>>>>>On August 10, 2004 at 12:52:28, Robert Hyatt wrote:
>>>>>
>>>>>>On August 10, 2004 at 10:59:29, Tord Romstad wrote:
>>>>>>
>>>>>>>On August 10, 2004 at 10:35:29, Anthony Cozzie wrote:
>>>>>>>
>>>>>>>>Plus, if you have only PST eval you should be getting 3-4M nps, so SEE probably
>>>>>>>>slows you down a _lot_.
>>>>>>>
>>>>>>>Yet another proof of how bad my programming skills are. With PST eval and
>>>>>>>nothing
>>>>>>>else, I get about 800,000 nps (on a PIV 2.4 GHz). Adding SEE slowed me down to
>>>>>>>around 750,000 nps.
>>>>>>>
>>>>>>>Tord
>>>>>>
>>>>>>
>>>>>>SEE slowed me down by 10%. Move ordering improved to speed me up 10%. Washed
>>>>>>out to no advantage, _until_ I added the stuff about tossing out captures that
>>>>>>can't bring the score back to within the alpha/beta window. That made me about
>>>>>>2x faster overall, which is a _big_ gain. Stuart isn't getting all the
>>>>>>advantages of SEE yet, and, in fact, It isn't necessary to use SEE on _every_
>>>>>>capture. IE for PxQ there is no need to see if that is +9 or +8. Either is
>>>>>>good enough and there MVV/LVA is faster.
>>>>>
>>>>>
>>>>>
>>>>>Robert,
>>>>>I haven't done any extensive testing to see if SEE pruning would improve the
>>>>>strength of my engine. but i was worried that pruning moves in qsearch based on
>>>>>a weak see score would eliminate moves where there would be additional
>>>>>discovered attacks.
>>>>>
>>>>>For now I settled on the following. Over time i'll be able to tune the 2 const
>>>>>values of 75 and 200 to more appropriate levels. I'm guessing evenutally they
>>>>>will be lowered, but for now i'm trying to be "safer".
>>>>>
>>>>>
>>>>>//get the see value of the move
>>>>>move_estval = movestack->estscore[movestack->orderedmove[imove]];
>>>>>
>>>>>//get the captured piece
>>>>>chesspiece captured_piece = MoveTaken(move);
>>>>>
>>>>>//find value of the captured piece
>>>>>int captured_piece_val = evalterms.material_vals[captured_piece];
>>>>>
>>>>>bool can_gain_mater = true;
>>>>>//init_score is the static eval before moving
>>>>>if(captured_piece&&((captured_piece_val+init_score+75)<alpha)){can_gain_mater=false;}
>>>>>if(captured_piece&&((move_estval+init_score+200)<alpha)){can_gain_mater=false;}
>>>>>if(can_gain_mater){should_do_move=true;}
>>>>>
>>>>>In your opinion, is there any truth to my concerns about not discovering attacks
>>>>>because of a see score that couldn't reach alpha?
>>>>>
>>>>>Eric
>>>>
>>>>
>>>>I consider SEE scores to be simply estimates, since they do not worry about
>>>>pinned pieces and the like. But then the entire q-search is only an estimate
>>>>since it doesn't consider anything but captures (in Crafty). There are enough
>>>>errors in only looking at captures to make your hair stand on end. Compounding
>>>>this with SEE pruning doesn't change much at all.
>>>>
>>>>Best test is to try it. IE don't prune losing captures, and run a big test set.
>>>> Then prune them and run it again. You will probably get almost a ply deeper by
>>>>pruning, and your scores should go up, not down as a result (at least when I
>>>>tested this it did. I've been doing this since the late 70's, with reasonable
>>>>results. Others such as Bruce (Ferret) Stanback (Zarkov) and so forth have had
>>>>the same results).
>>>>
>>>>The right thing to do is shrink the q-search, where the errors are, and make
>>>>your normal search bigger where there is none of this highly selective pruning
>>>>(ie looking at nothing but captures is _really_ selective) and its associated
>>>>errors.
>>>
>>>I think that the right thing to do is to be more selective in the last plies.
>>>
>>>It does not mean to do the qsearch smaller.
>>>You can start with more selective search than normal search but less selective
>>>search than your qsearch in the first plies by including checks and captures and
>>>only later to consider only good captures(I include queen promotions in the word
>>>capture).
>>>
>>>Uri
>>
>>I don't disagree. Cray Blitz did that. It had a normal full-width part of the
>>search, then a "tactical phase" that included captures, checks and some moves
>>with significant threats, then only captures/checks, and finally tapering off to
>>only captures.
>>
>>I may try that again one day as I did play with it in early versions of Crafty
>>but decided to "keep it simple" for a while...
>
>Sounds like a great idea to do it that way. Surprised you gave it up.
>Surely it can't be hard to throw something together with Crafty to
>test out the CB idea.
It would not be that hard, but I like the idea of trying to keep all the error
stuff held to a minumum, which means miniumal q-search...
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.