Author: Uri Blass
Date: 14:36:53 08/10/04
Go up one level in this thread
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
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.