Smooth scaling stockfish

[Dann Corbit]

This version of Stockfish:
http://cap.connx.com/chess-engines/new- ... x64_ja.rar

Scales null move smoothly. I get about +150 Elo so far in my testing. How about yours?

[BubbaTough]

This version of Stockfish:
http://cap.connx.com/chess-engines/new- ... x64_ja.rar

Scales null move smoothly. I get about +150 Elo so far in my testing. How about yours?

I am not sure what you mean by smooth scaling, and don't see any attached source code.


-Sam

[Dann Corbit]

This version of Stockfish:
http://cap.connx.com/chess-engines/new- ... x64_ja.rar

Scales null move smoothly. I get about +150 Elo so far in my testing. How about yours?

I am not sure what you mean by smooth scaling, and don't see any attached source code.


-Sam

Here are the changes from version 1.61:
http://cap.connx.com/chess-engines/new-approach/sfc.zip

Note that I do not have the 1.62 sources, which have additional corrections.

I guess that the curve can be greatly improved. It was a first hack eyeball guestimate.

[Dann Corbit]

This version of Stockfish:
http://cap.connx.com/chess-engines/new- ... x64_ja.rar

Scales null move smoothly. I get about +150 Elo so far in my testing. How about yours?

I am not sure what you mean by smooth scaling, and don't see any attached source code.


-Sam

Here are the changes from version 1.61:
http://cap.connx.com/chess-engines/new-approach/sfc.zip

Note that I do not have the 1.62 sources, which have additional corrections.

I guess that the curve can be greatly improved. It was a first hack eyeball guestimate.

I think probably that my MS build will be needed to see the improvement, since it does not come into play unless the macro SMOOTH_SCALING is defined and I neglected to mention it to Jim. My MS build:
http://cap.connx.com/chess-engines/new- ... sh.exe.bz2

The source changes:
http://cap.connx.com/chess-engines/new-approach/sfc.zip
The only thing changed in misc.cpp is the version number (I added an 's' so that the difference would be known).

[BubbaTough]

This version of Stockfish:
http://cap.connx.com/chess-engines/new- ... x64_ja.rar

Scales null move smoothly. I get about +150 Elo so far in my testing. How about yours?

I am not sure what you mean by smooth scaling, and don't see any attached source code.


-Sam

Here are the changes from version 1.61:
http://cap.connx.com/chess-engines/new-approach/sfc.zip

Note that I do not have the 1.62 sources, which have additional corrections.

I guess that the curve can be greatly improved. It was a first hack eyeball guestimate.

Ahh, gotcha. I did something similar in LearningLemming, and I think I got the idea from something Michael Sherwin was trying in Romi (though I think he scaled it differently) so I imagine Romi also does it. Its nice to see it work for someone else too. It always amazes me that some ideas can work so well for some authors, and not for others.

-Sam

[Dann Corbit]

I made two simple changes to the code. First, I used TT entries slightly more (because I figured that a hash table entry with search {no matter how shallow} was better than a quick evaluation estimate. Second, I scale the null move depth as a function of difference between beta and evaluation estimate and also of depth.

Anyway, all significant changes are in this patch of code:

Code: Select all

// search() is the search function for zero-width nodes.

Value search(Position& pos, SearchStack ss[], Value beta, Depth depth,
             int ply, bool allowNullmove, int threadID, Move excludedMove) {

    assert&#40;beta >= -VALUE_INFINITE && beta <= VALUE_INFINITE&#41;;
    assert&#40;ply >= 0 && ply < PLY_MAX&#41;;
    assert&#40;threadID >= 0 && threadID < ActiveThreads&#41;;

    Move movesSearched&#91;256&#93;;
    EvalInfo ei;
    StateInfo st;
    const TTEntry* tte;
    Move ttMove, move;
    Depth ext, newDepth;
    Value approximateEval, nullValue, value, futilityValue, futilityValueScaled;
    bool isCheck, useFutilityPruning, singleReply, moveIsCheck, captureOrPromotion, dangerous;
    bool mateThreat = false;
    int moveCount = 0;
    Value bestValue = -VALUE_INFINITE;

    if &#40;depth < OnePly&#41;
        return qsearch&#40;pos, ss, beta-1, beta, Depth&#40;0&#41;, ply, threadID&#41;;

    // Initialize, and make an early exit in case of an aborted search,
    // an instant draw, maximum ply reached, etc.
    init_node&#40;ss, ply, threadID&#41;;

    // After init_node&#40;) that calls poll&#40;)
    if &#40;AbortSearch || thread_should_stop&#40;threadID&#41;)
        return Value&#40;0&#41;;

    if &#40;pos.is_draw&#40;))
        return VALUE_DRAW;

    if &#40;ply >= PLY_MAX - 1&#41;
        return pos.is_check&#40;) ? quick_evaluate&#40;pos&#41; &#58; evaluate&#40;pos, ei, threadID&#41;;

    // Mate distance pruning
    if &#40;value_mated_in&#40;ply&#41; >= beta&#41;
        return beta;

    if &#40;value_mate_in&#40;ply + 1&#41; < beta&#41;
        return beta - 1;

    // We don't want the score of a partial search to overwrite a previous full search
    // TT value, so we use a different position key in case of an excluded move exsists.
    Key posKey = excludedMove ? pos.get_exclusion_key&#40;) &#58; pos.get_key&#40;);

    // Transposition table lookup
    tte = TT.retrieve&#40;posKey&#41;;
    ttMove = &#40;tte ? tte->move&#40;) &#58; MOVE_NONE&#41;;

    if &#40;tte&#41;
    &#123;
        if  &#40;ok_to_use_TT&#40;tte, depth, beta, ply&#41;)
        &#123;
            ss&#91;ply&#93;.currentMove = ttMove; // Can be MOVE_NONE
            return value_from_tt&#40;tte->value&#40;), ply&#41;;
        &#125;
        else
        &#123;
            approximateEval = value_from_tt&#40;tte->value&#40;), ply&#41;; // Should be a very good estimate
        &#125;
    &#125;
    else
        approximateEval = quick_evaluate&#40;pos&#41;; // only call this if we miss in the TT altogether

    isCheck = pos.is_check&#40;);

    // Null move search
    if (    allowNullmove
            &&  depth > OnePly
            && !isCheck
            && !value_is_mate&#40;beta&#41;
            &&  ok_to_do_nullmove&#40;pos&#41;
            &&  approximateEval >= beta - NullMoveMargin&#41;
    &#123;
        ss&#91;ply&#93;.currentMove = MOVE_NULL;

        pos.do_null_move&#40;st&#41;;

#ifdef SMOOTH_REDUCTION
		double delta = approximateEval - beta;
		delta = max&#40;delta, 1.0&#41;;
		double ddepth = double&#40;depth&#41;;
		double r = 0.18 * ddepth + 3.1 + log&#40;delta&#41;/5.0;
		r = r > ddepth ? ddepth &#58; r;
		int R = int&#40;r&#41;;
#else
        // Null move dynamic reduction based on depth
        int R = &#40;depth >= 5 * OnePly ? 4 &#58; 3&#41;;

        // Null move dynamic reduction based on value
        if &#40;approximateEval - beta > PawnValueMidgame&#41;
            R++;
#endif
		nullValue = -search&#40;pos, ss, -&#40;beta-1&#41;, depth-R*OnePly, ply+1, false, threadID&#41;;

[bob]

This version of Stockfish:
http://cap.connx.com/chess-engines/new- ... x64_ja.rar

Scales null move smoothly. I get about +150 Elo so far in my testing. How about yours?

I never got that idea to work, but I did test it quite a few years ago when depths were not as significant. In fact, Ernst and I developed the "adaptive null-move idea" independently. John Stanback had suggested the basics for the idea around 1995 or so. Initially it was a question of R=1 or R=2, but eventually became R=2 or R=3. I used to have fractional plies, and tried a gradual and continuous (smooth) reduction as it approached the frontier nodes, but never found something that worked any better than the simple R=3 closer to the root, R=2 closer to the leaves.

[Uri Blass]

<snipped>

I made two simple changes to the code. First, I used TT entries slightly more (because I figured that a hash table entry with search {no matter how shallow} was better than a quick evaluation estimate. Second, I scale the null move depth as a function of difference between beta and evaluation estimate and also of depth.

I think that it may be possible to make another improvement.

The idea is that the difference between the quick evaluation and the real evaluation is usually in the same direction and if some side has positional advantage that the quick evaluation does not see then it is going to continue to have the same positional evaluation later.


It may be possible simply to improve the quick evaluation estimate by having an average number for the difference between the real evaluation and the quick evaluation from white point of view and adding this number to the estimate.

I guess that it is not going to be expensive to do quick evaluation every time that you do the expensive evaluation(because the expensive part is the not quick evaluation that you already did).

Uri

[mcostalba]

This version of Stockfish:
http://cap.connx.com/chess-engines/new- ... x64_ja.rar

Scales null move smoothly. I get about +150 Elo so far in my testing. How about yours?

I am not sure what you mean by smooth scaling, and don't see any attached source code.


-Sam

Here are the changes from version 1.61:
http://cap.connx.com/chess-engines/new-approach/sfc.zip

Note that I do not have the 1.62 sources, which have additional corrections.

I guess that the curve can be greatly improved. It was a first hack eyeball guestimate.

Ahaaaaa you changed the indentation of the functions !!!

In a project where more then one people work changing indentation of the whole file is never a good idea. It becomes difficult to spot the real differences for no gain at all.

Anyhow thanks !!! I will test for sure

[zamar]

+150elo???

If we can get even close to this, I think that this is really great news for whole chess community!!

Code: Select all

		double r = 0.18 * ddepth + 3.1 + log(delta)/5.0;

Balancing this equation is perhaps the next challenge? I need to think about this...