some very strange behavior of SF

[lech]

I think that what you are observing is just expected behaviour!

As the depth grows, negamax prunings kick in more and more (compared to minimax) and values of all moves get closer to alpha.

If it is expected I think it is possible to use it.
All moves are going to alpha, thus I changed root_search (SF 1.8).

Code: Select all

// Step extra. pv search
                // We do pv search for first moves (i < MultiPV)
                // and for fail high research (value > alpha)
                if (i < MultiPV || value > alpha || rml.get_move_score(i) >= rml.get_move_score(0))

I tested it by:

Code: Select all

cutechess-cli -fcp name=sfx cmd=sfx.exe -scp name=sf cmd=sf.exe -both proto=uci option.Ponder=false tc=/0:50+0.2 

-pgnin gaviota-starters.pgn -resign 3 700 -games 300 -repeat -recover -concurrency 1 -pgnout games.pgn min

(the same size of both exe)

And I received the (expected ) result after 130 games (sorry, I had to stop it ):
sfx - sf: +40 -22 =68
It is a huge (stable ) advantage, but it would be good to check it by specialized computers.

[mcostalba]

It is a huge (stable ) advantage, but it would be good to check it by specialized computers.

Could you please post your code somewhere, as example here:

http://www.mediafire.com/

it is enough you post file search.cpp

Sorry but from your post I am not able to understand what you have changed exactly.

I'll be happy to verify your patch with proper testing and report the result.

Thanks
Marco

[lech]

is only changed (root):

Code: Select all

// Step extra. pv search
                // We do pv search for first moves (i < MultiPV)
                // and for fail high research (value > alpha)
                if (i < MultiPV || value > alpha)

to:

Code: Select all

// Step extra. pv search
                // We do pv search for first moves (i < MultiPV)
                // and for fail high research (value > alpha)
                if (i < MultiPV || value > alpha || rml.get_move_score(i) >= rml.get_move_score(0))

Of course, for this idea, it would be good to change the score of root moves (no -VALUE_INFINITE, if a move is not over alpha) to the original score (value). But it is another story. I did not test it.
I understand that the result of test seems to be too hight, but I can't see a mistake in my work. I think that reductions are very useful, but sometimes it can be good to check moves by PVnodes immediately. Specially, if the main move failed ( value < alpha).

[mcostalba]

is only changed (root):

Code: Select all

// Step extra. pv search
                // We do pv search for first moves (i < MultiPV)
                // and for fail high research (value > alpha)
                if (i < MultiPV || value > alpha)

to:

Code: Select all

// Step extra. pv search
                // We do pv search for first moves (i < MultiPV)
                // and for fail high research (value > alpha)
                if (i < MultiPV || value > alpha || rml.get_move_score(i) >= rml.get_move_score(0))

After 7985 games

Your version - Original: 1217 - 1305 - 5463 ELO -3 (+- 3.1)

So it seems unfortunatly the idea does not work.

[lech]

is only changed (root):

Code: Select all

// Step extra. pv search
                // We do pv search for first moves (i < MultiPV)
                // and for fail high research (value > alpha)
                if (i < MultiPV || value > alpha)

to:

Code: Select all

// Step extra. pv search
                // We do pv search for first moves (i < MultiPV)
                // and for fail high research (value > alpha)
                if (i < MultiPV || value > alpha || rml.get_move_score(i) >= rml.get_move_score(0))

After 7985 games

Your version - Original: 1217 - 1305 - 5463 ELO -3 (+- 3.1)

So it seems unfortunatly the idea does not work.

1) I think that after this change (only) it was possible to test the same versions of SF only.
It needs some additional changes to get the proper idea.

Code: Select all

 (SF 2.0)
// Step 17. Check for new best move
            if (value <= alpha && i >= MultiPV)
                rml[i].pv_score = value ;  // in original: = -VALUE_INFINITE;
            else
            {
                // PV move or new best move!

                // Update PV
                ss->bestMove = move;
                rml[i].pv_score = value + 1;  // in original: = value;
                rml[i].extract_pv_from_tt(pos);

Now it is possible to test the main idea: “all moves (i>0) which reach alpha
(rml.pv_score >= alpha) are tested by pv search (root) too”.

2) There is another possibility to use this idea (all moves are going to alpha) separately.
The better moves go (reach alpha) faster than the worse and we can use it in sorting (root).

Code: Select all

// Step 17. Check for new best move
if  (value => alpha )  rml[i].count_alpha(); // it does: mp.countAlpha++;

and modify the sort of root Moves:

Code: Select all

bool operator<(const RootMove& m) const {
      return pv_score != m.pv_score ? pv_score < m.pv_score : countAlpha != m.countAlpha ?      countAlpha < m.countAlpha  : non_pv_score < m.non_pv_score;

instead of:

Code: Select all

bool operator<(const RootMove& m) const {
      return pv_score != m.pv_score ? pv_score < m.pv_score
                                    : non_pv_score < m.non_pv_score;

Sorry, but I haven’t a sterile computer and my tests are not sure.