Author: Miguel A. Ballicora
Date: 12:20:58 05/19/01
Go up one level in this thread
On May 18, 2001 at 16:40:43, Gian-Carlo Pascutto wrote:
>On May 18, 2001 at 14:23:01, Miguel A. Ballicora wrote:
>
>>Of course, I just threw some ideas that might be considered to determine
>>if the algorithm it is worth to be triggered. In the case of mate threats
>>or checks to extend more than one ply (maybe),
>
>I went back and forth on this and have it as a settable option, to
>allow more than 1 ply of extensions per nodes.
>
>Standard Crafy does not allow more than 1 ply per node of extensions.
>
>A system like maximum 2 ply per 2 nodes, as described in the DB papers,
>would work much better. It would not blow up the search so much like my
>methode now does.
>
>>I agree, it has to be statically determined.
>
>You will have to use an advanced form of SEE in that case.
What I have in mind is static features of the position. For instance,
What I am trying now is do singularity test only when I am in check and
there is more than one response.
If I am succesful with this, I might try to do the test when the
king safety of the side on the move is terrible.
I just got an idea, but this is not static. Test singularity if the
previous move was singular (will make the side that is attacking to
continue the hunt of the opposite king).
>>>of nearly 2 ply. In the LCT2 which I used that lost many other solutions.
>>
>>2 ply? ouch. My intuition was not bad. How does it play overall?
>
>I have not tested actual gameplay.
>
>>The latter is a nice trick. Similar to R.H. suggestions some time ago to
>>use as negative extensions (reduce depth after several moves have been tried).
>>Kind of risky though.
>
>We will only extend too much, so there is no risk involved at all.
>
>>
>>What I did so far it is very simple. It is the most limited case I could
>>imagine: I triggered SE when in check (after it was extended already)
>>This is the pseudocode:
>>
>>if (incheck) {
>> depth +=1;
>> if (1==moves_available) {
>> depth += 1; /* single response extension */
>> } else {
>> enable_SE = TRUE; /* it will test a singular check evasion */
>> }
>>}
>>
>>generate_moves();
>>bestmove = loop_moves(&best);
>>
>>if (enable_SE && best > original_alpha) {
>> SE_alpha = lower_of (original_alpha, best-PAWN_VALUE);
>> secondbest = research_moves_but_bestmove (depth-2, SE_alpha, SE_alpha+1)
>> if (secondbest > original_alpha) {
>> best = research (bestmove, depth+1);
>> }
>>}
>>
>>return best;
>
>Don't you mean depth-3, assuming you already do depth-1 on normal moves?
Yes and no, I meant what you have in mind, though :-)
In this pseudocode, inside the function it is reduce depth-1 again after each
makemove.
>You dont want to research if SE_alpha < original_alpha, because you will
>not do anything with the secondbest value anyway.
>
>Another nitpick is that you should research _all_ moves and not only
>the best move. If it fails low because of the extension you have to
>pick up a new best one, and if needed, start the process all over again.
>This is how SE detects horizon type moves.
I will consider this carefully and test it. Thanks.
Miguel
>
>--
>GCP
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.