I read the following comment in stockfish(lines 1335-1336 of search.cpp):
// Logically we should return (v + razor_margin(depth)), but
// surprisingly this did slightly weaker in tests.
I see no reason why logically you need to return a different number than the number that you got by search.
It is correct that v is based on search to reduced depth but it is still result based on search.
When you do reductions you do not store different value than the value that you got by search so I see no reason why it should be different for pruning.
I wonder if it is not better to replace
return refinedValue - futility_margin(depth, 0);
by return refinedValue in step 7.
Did you test and find that refinedValue-futility_margin(depth,0) is better?
Uri
about stockfish and logic
Moderators: hgm, Rebel, chrisw
-
- Posts: 10282
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
-
- Posts: 613
- Joined: Sun Jan 18, 2009 7:03 am
Re: about stockfish and logic
It was tested and written by me.Uri Blass wrote:I read the following comment in stockfish(lines 1335-1336 of search.cpp):
// Logically we should return (v + razor_margin(depth)), but
// surprisingly this did slightly weaker in tests.
It's a common practice when doing a futility pruning (and there is a good reason for it). IMO razoring is just futility pruning "other way around".I see no reason why logically you need to return a different number than the number that you got by search.
Reductions are invariant to static value, so this is a completely different thing. For futility pruning/razoring, It's important to understand the interactions through TT and what happens when parent node gets probed from TT with different beta.When you do reductions you do not store different value than the value that you got by search so I see no reason why it should be different for pruning.
No we haven't tested it, but I'd bet that it's not a big deal, hard to measure.I wonder if it is not better to replace
return refinedValue - futility_margin(depth, 0);
by return refinedValue in step 7.
Did you test and find that refinedValue-futility_margin(depth,0) is better?
Uri
If you have extra time, please test If you are interested in this, I can give instructions through pm. Proper testing of the patch will take 24-30h.
Joona Kiiski
-
- Posts: 408
- Joined: Sat Mar 06, 2010 9:28 am
Re: about stockfish and logic
I also have a question regarding step 6: razoring.
In case the razoring conditions are true the qsearch value v is returned. Shouldn't refinedValue be more accurate than v, in case refinedEval would come from a TT entry with depth>0?
In case the razoring conditions are true the qsearch value v is returned. Shouldn't refinedValue be more accurate than v, in case refinedEval would come from a TT entry with depth>0?
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: about stockfish and logic
Could you please post the code you mean to change and the change you are suggesting ? It is not clear to me from the above what is the idea.Ralph Stoesser wrote:I also have a question regarding step 6: razoring.
In case the razoring conditions are true the qsearch value v is returned. Shouldn't refinedValue be more accurate than v, in case refinedEval would come from a TT entry with depth>0?
Thanks
Marco
-
- Posts: 10282
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: about stockfish and logic
I understand that the idea is simply to return tranposition table score instead of doing qsearch in case that there is information in the hash.mcostalba wrote:Could you please post the code you mean to change and the change you are suggesting ? It is not clear to me from the above what is the idea.Ralph Stoesser wrote:I also have a question regarding step 6: razoring.
In case the razoring conditions are true the qsearch value v is returned. Shouldn't refinedValue be more accurate than v, in case refinedEval would come from a TT entry with depth>0?
Thanks
Marco
I guess that the idea is not good because qsearch already call the tranposition table so you earn nothing from it.
Uri
-
- Posts: 408
- Joined: Sat Mar 06, 2010 9:28 am
Re: about stockfish and logic
I was thinking about something like thisUri Blass wrote:I understand that the idea is simply to return tranposition table score instead of doing qsearch in case that there is information in the hash.mcostalba wrote:Could you please post the code you mean to change and the change you are suggesting ? It is not clear to me from the above what is the idea.Ralph Stoesser wrote:I also have a question regarding step 6: razoring.
In case the razoring conditions are true the qsearch value v is returned. Shouldn't refinedValue be more accurate than v, in case refinedEval would come from a TT entry with depth>0?
Thanks
Marco
I guess that the idea is not good because qsearch already call the tranposition table so you earn nothing from it.
Uri
Code: Select all
// Step 6. Razoring
if ( refinedValue < beta - razor_margin(depth)
&& ttMove == MOVE_NONE
&& ss[ply - 1].currentMove != MOVE_NULL
&& depth < RazorDepth
&& !isCheck
&& !value_is_mate(beta)
&& !pos.has_pawn_on_7th(pos.side_to_move()))
{
if (refinedValue == ss[ply].eval) // refinedValue is static eval score
{
Value rbeta = beta - razor_margin(depth);
Value v = qsearch(pos, ss, rbeta-1, rbeta, Depth(0), ply, threadID);
if (v < rbeta)
// Logically we should return (v + razor_margin(depth)), but
// surprisingly this did slightly weaker in tests.
return v;
}
else // refinedValue is TT score
{
return refinedValue;
}
}
So we would only save a TT query and a call to qsearch in this case.
It's probably not worth to do so.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: about stockfish and logic
I think so too.Ralph Stoesser wrote: Yes, Uri, qsearch would retrieve the better score from TT.
So we would only save a TT query and a call to qsearch in this case.
It's probably not worth to do so.
Instead a possible optimization that I didn't make because of didn't find a nice way to do it (read "without changing qsearch() call parameters") is to pass the static position evaluation to qsearch when we razor.
IOW we have already called the costly evaluate() few lines before:
Code: Select all
ss[ply].eval = evaluate(pos, ei, threadID);
Someone has hints (read "a patch") to how to do it ?
-
- Posts: 2272
- Joined: Mon Sep 29, 2008 1:50 am
Re: about stockfish and logic
going to call _again_ evaluate() on the same position,
Isn't this exactly what an evaluation cache is for? So that you don't have to think about such things.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: about stockfish and logic
Do we have an evaluation cache ?Michel wrote:going to call _again_ evaluate() on the same position,
Isn't this exactly what an evaluation cache is for? So that you don't have to think about such things.
BTW, I _want_ to think about such things because I want to always have very clear the impact of a change against the benefit....if you are suggesting to implement an evaluation cache to optimize the qsearch call in razoring _perhaps_ you don't have clear such cost/benefit relation.
...and I think we all agree that a possible answer like: "but there are other places where an evaluation cache could be useful" has _absolutely_ no meaning as is, i.e. without evidences support (it would be just a no-content discussion like the one on object oriented languages taking place in the main forum)...sorry to point out this obvious point but you know, better safe then sorry
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: about stockfish and logic
You do not need a full blown hash table. You just need to remember one entry with last_eval and last_hashsignature. This approach could also be useful with pawn scores (before even going to a hash pawn table).mcostalba wrote:Do we have an evaluation cache ?Michel wrote:going to call _again_ evaluate() on the same position,
Isn't this exactly what an evaluation cache is for? So that you don't have to think about such things.
BTW, I _want_ to think about such things because I want to always have very clear the impact of a change against the benefit....if you are suggesting to implement an evaluation cache to optimize the qsearch call in razoring _perhaps_ you don't have clear such cost/benefit relation.
Miguel
...and I think we all agree that a possible answer like: "but there are other places where an evaluation cache could be useful" has _absolutely_ no meaning as is, i.e. without evidences support (it would be just a no-content discussion like the one on object oriented languages taking place in the main forum)...sorry to point out this obvious point but you know, better safe then sorry