Search bug? (Stockfish)

[UncombedCoconut]

I'm trying to debug or explain strange behavior by Stockfish in this position:
[D]8/1B6/8/5k2/7P/8/5K2/8 w - - 0 1

SF has code to recognize drawn wrong-rook-pawn endings, and usually gets this right.
But in a parallel search, it will sometimes display a huge plus score for a while (depth in the 20s). This happened 7/50 times with a git-20111127 build and Threads=2.

SF's drawing condition is: the defending K is either next to the queening square, or within 1 file of the P and on an equal or greater rank. This has its false positives and negatives, but even shallow minimax should cure them. So I suspect a bug in the search. Any other explanation?

(This is rarer in SF 2.11-ja. One can trigger this behavior more frequently, but after more nodes, by starting with the BK farther from the h file.)

Here's an especially bad example, with SF confused for quite a while. In other cases, SF comes to its senses sooner but prints PVs where Black never leaves the g/h files.

Code: Select all

29   +0.00   00:00   1086K  h5 Kg5 h6 Kxh6 
30   +0.00   00:00   1253K  h5 Kg5 h6 Kxh6 
31   +8.69   00:00   3310K  h5 Kf6 Bh1 Kg7 Bc6 Kf7 Bb5 Kg7 Be8 Kh6 Ke3 Kg5 Kf3 
                            Kh6 Kg4 Kg7 Kg5 Kh7 Bc6 Kg7 Bb5 Kg8 Ba4 Kf8 
32   +7.31   00:05  26431K  h5 Kf6 Bh1 Kg7 Bc6 Kh7 Be8 Kh6 Ke3 Kg5 Kf3 Kh6 Kf4 
                            Kg7 Kg5 Kh7 Bb5 Kg8 Be2 Kh7 h6 Kh8 Bd3 Kg8 Bc2 Kh8 
                            Kf4 Kg8 Be4 Kh8 Ke3 Kg8 Kd2 Kh8 Bd3 Kg8 Kd1 Kf7 Bh7 
                            Kf6 Be4 Kf7 Kd2 Kg8 Bd3 Kh8 Ke1 Kg8 Kd1 
33   +7.31   00:07  34180K  h5 Kf6 Bh1 Kg7 Bc6 Kh7 Be8 Kh6 Ke3 Kg5 Kf3 Kh6 Kf4 
                            Kg7 Kg5 Kh7 Bb5 Kh8 h6 Kg8 Bc4+ Kh8 Be6 Kh7 Ba2 Kh8 
                            Bd5 Kh7 Bb3 Kh8 Be6 
34   +7.39   00:08  42248K  h5 Kf6 Bh1 Kg7 Bc6 Kh7 Be4+ Kh6 Bg6 Kg7 Kg3 Kh8 h6 
                            Kg8 Be4 Kh8 Kg4 Kg8 Kf3 Kh8 Kg2 Kg8 Kg3 
35   +7.39   00:11  58251K  h5 Kf6 Bh1 Kg7 Bc6 Kh7 Be4+ Kh6 Bg6 Kg7 Kg3 Kh8 h6 
                            Kg8 Be4 Kh8 Bg6 
36   +0.00   01:17 442625K  h5 Kf6 Bh1 Kg7 Bc6 Kh7 Be4+ Kh6 Bg6 Kg7 Bf5 Kh6 Bg6 
37   +0.00   01:17 443049K  h5 Kf6 Bh1 Kg7 Bc6 Kh7 Be4+ Kh6 Bg6 Kg7 Bf5 Kh6 Bg6 

[zamar]

Any other explanation?

Late move pruning. It might be that for example black's moves Kf6, Kf7, Kf8 have a high history score (Because we have a position where almost any move draws such oddities may happen). Now if black's king is on g7, it may happen that the search will only consider moves Kf6, Kf7, Kf8 and prunes the rest. And because history scores are global this may occur in practically every branch of the tree. [In reality I assume it is more complicated than this, fx. razoring might give a big boost to this behaviour, but you get the idea]

P.S. Again this is only a guess

[MikeGL]

[D]8/k2b4/p1b1b3/p2b1b2/2b1b3/8/8/K7 w - - 0 1

What's strange with this type of positions is that other
engines keeps on searching, while Rybka 4 is
just giving 0.00 from depth 1 without doing any searches.
Seems like a hardwired knowledge or pattern inside Rybka eval.

All other engines are giving a huge plus score for black.

[Eelco de Groot]

[D]8/k2b4/p1b1b3/p2b1b2/2b1b3/8/8/K7 w - - 0 1

What's strange with this type of positions is that other
engines keeps on searching, while Rybka 4 is
just giving 0.00 from depth 1 without doing any searches.
Seems like a hardwired knowledge or pattern inside Rybka eval.

All other engines are giving a huge plus score for black.

Rybka can, I think, code this a little easier because it already separates the white squared and the black squared bishop as two different piecetypes everywhere, at least if that is still the same as in the time Larry was doing the evaluation tuning (Rybka 3). With Rainbow Serpent I don't think I can handle that many bishops as in your position but after a lot of added code, the same colored bishops positions are not a complete unknown phenomenon anymore. Probably I'm not being very efficient in coding it but all that new stuff with templates is just too complicated for a C amateur. If Marco types something like

Code: Select all

/// Endgames class stores in two std::map the pointers to endgame evaluation
/// and scaling base objects. Then we use polymorphism to invoke the actual
/// endgame function calling its apply() method that is virtual.

I'm completely lost there It must be C+++ or something? But anyway this Rainbow Serpent can do now:


[D]8/k7/4b3/3b4/8/8/8/K7 w - -

Engine: Stockfish Kingdefender (Rainbow Serpent, Build 107, Athlon 2009 MHz, 48 MB, using "critical node" singular extensions combined with suppression of LMR in the child ALL node) by Tord Romstad, Marco Costalba and Joona Kiiski

1/01 0:00 0.00 1.Kb1 (11) 0

2/02 0:00 0.00 1.Kb1 Bh3 (43) 0

3/03 0:00 0.00 1.Kb1 Bh3 2.Kb2 (176) 2

4/04 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 (856) 13

5/05 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 (2.735) 44

6/06 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 (4.108) 52

7/07 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 (7.090) 90

8/08 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 (13.619) 174

9/09 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 (22.211) 284

10/10 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 (35.834) 381

11/11 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (52.774) 561

12/12 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (80.464) 738

13/13 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (106.986) 855

14/14 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (144.124) 1029

15/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (191.077) 1110

16/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (248.170) 1327

17/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (316.193) 1443

18/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (399.979) 1599

19/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (502.423) 1691

20/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (625.665) 1742

21/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (766.263) 1815

22/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (928.040) 1856

23/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (1.106.378) 1914

24/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (1.306.306) 1943

25/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (1.540.872) 1972

26/15 0:00 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (1.802.157) 2022

27/15 0:01 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (2.064.969) 2002

28/15 0:01 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (2.379.137) 2004

29/15 0:01 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (2.738.258) 2037

30/15 0:01 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (3.181.788) 2036

31/15 0:01 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (3.670.630) 2042

32/18 0:02 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (4.160.850) 2048

33/18 0:02 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (4.756.610) 2043

34/18 0:02 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (5.402.637) 2045

35/18 0:03 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (6.160.802) 2042

36/18 0:03 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (7.007.915) 2038

37/18 0:03 0.00 1.Kb1 Bh3 2.Kb2 Bf1 3.Ka1 Be2 4.Kb2 Bh1
5.Ka1 Bf1 6.Kb2 Bh3 7.Ka1 Bf1 (7.979.527) 2034

best move: Ka1-b1 time: 0:04.188 min n/s: 2.034.555 nodes: 7.979.527


And this is also a bit more like Rybka Cluster would output it I hope, the difference being that Rainbow Serpent runs on just one processor:

[D]8/k7/p3b3/p2b4/8/8/8/K7 w - -

Engine: Stockfish Kingdefender (Rainbow Serpent, Build 107, Athlon 2009 MHz, 48 MB, using "critical node" singular extensions combined with suppression of LMR in the child ALL node) by Tord Romstad, Marco Costalba and Joona Kiiski

1/01 0:00 0.00 1.Kb1 (12) 0

2/02 0:00 0.00 1.Kb1 a4 (44) 1

3/03 0:00 0.00 1.Kb1 a4 2.Kb2 (179) 5

4/05 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 (873) 28

5/06 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 (2.800) 59

6/07 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 (3.793) 80

7/08 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1 (9.264) 197

8/09 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 (22.468) 478

9/11 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 (40.764) 647

10/12 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 (76.219) 977

11/13 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 (132.696) 1217

12/14 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 (223.349) 1431

13/15 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 (358.434) 1636

14/16 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (548.586) 1752

15/17 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (816.732) 1802

16/18 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (1.199.085) 1870

17/19 0:00 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (1.687.333) 1893

18/20 0:01 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (2.381.179) 1929

19/21 0:01 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (3.226.862) 1929

20/21 0:02 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (4.285.904) 1918

21/21 0:02 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (5.576.761) 1919

22/22 0:03 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (6.863.556) 1893

23/23 0:04 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (8.329.345) 1883

24/23 0:05 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (10.165.806) 1858

25/24 0:06 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (12.608.349) 1842

26/26 0:08 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (15.812.000) 1826

27/27 0:11 0.00 1.Kb1 a4 2.Kb2 a3+ 3.Kxa3 a5 4.Kb2 Bh1
5.Ka1 a4 6.Kb2 a3+ 7.Kxa3 Bg2 8.Kb2 Bh1
9.Ka3 (19.890.482) 1805

best move: Ka1-b1 time: 0:12.969 min n/s: 1.805.599 nodes: 19.890.482

I think it is nice that same colored bishops seem to get a bit more correctly evaluated now (these are just some first tests I made, there could well be hidden bugs in all the added lines even if most of it is re-used KBPsK endgame code, from the case with just one bishop of the wrong color). Also it will not add any elo and the added code is hard to avoid, even if it would be coded more efficiently by not re-using <KBPsK> code but calling it as a function. If I missed an easy way to do that it is because those C++ classes are too complex for me..

Eelco

[MikeGL]

Is Rainbow serpet available somewhere?
Where can I download this version of Stockfish?

[Eelco de Groot]

Is Rainbow serpet available somewhere?
Where can I download this version of Stockfish?

Hi Mike, well the last version of Rainbow Serpent was not strong I think, so I can't really recommend it for serious use. And only the last build 107 knows about bishops of the same colour but there is no public compile of it yet. I also have not yet tested it in matches because I don't have the hardware for that at the moment. Denis Mendoza made a compile of the testversion of a couple of weeks ago and there is even a 64 bit version of that, but still probably extremely weak compared to Stockfish for instance. That version can be found on the Toga forum

http://www.computerchess.info/tdbb/phpBB3/

Look for the Ferrarifish I am grateful for the compiles that Denis made I believe that last version was build 50, or close to that, and there have been changes to king safety since that I hope are a bit better than what was in KingDefender. That is also why I have not yet uploaded a new version of the code, I think Rainbow serpent was still very weak with its high selectivity, futility pruning in the last 24 plies etc. But I am working on it! Just minimal changes from Stockfish is also not the goal, being different is maybe just as important at the moment as improving it again...

Regards, Eelco

[Houdini]

[D]8/k2b4/p1b1b3/p2b1b2/2b1b3/8/8/K7 w - - 0 1

What's strange with this type of positions is that other
engines keeps on searching, while Rybka 4 is
just giving 0.00 from depth 1 without doing any searches.
Seems like a hardwired knowledge or pattern inside Rybka eval.

All other engines are giving a huge plus score for black.

It's very trivial to code, but for Houdini I didn't consider it useful to include the case with a/h-pawn and multiple wrong-colored bishops. This NEVER occurs in real games.

Robert

[MikeGL]

Thanks for the info regarding Rainbow Serpent, Eelco.

Robert, I agree it won't happen in real games,
I just increased the number of bishops for curiosity's sake.

[bob]

Thanks for the info regarding Rainbow Serpent, Eelco.

Robert, I agree it won't happen in real games,
I just increased the number of bishops for curiosity's sake.

It can happen in rare cases. There was a test position for this at one point in time, where a pawn was on the 7th and if it promoted to a R/Q it would stalemate the opponent, if it promoted to a B it would be of the same color as the other bishop. A knight was good enough (it didn't check, but it also didn't stalemate.) I think that generated a discussion here although I do not remember how far back it was. But several years at least...

[mcostalba]

If Marco types something like

Code: Select all

/// Endgames class stores in two std::map the pointers to endgame evaluation
/// and scaling base objects. Then we use polymorphism to invoke the actual
/// endgame function calling its apply() method that is virtual.

I'm completely lost there It must be C+++ or something?

There is admittedly some magic there, but is used to make life easier for people that wants to add new endgame knowledge. Mainly you just need to add the new type of endgame and register it in with add():

Code: Select all

--- a/src/endgame.h
+++ b/src/endgame.h
@@ -43,6 +43,7 @@ enum EndgameType {
   KBBKN, // KBB vs KN
   KNNK,  // KNN vs K
   KmmKm, // K and two minors vs K and one or two minors
+  KBBPK, // Eelco tests with king and two bishops+pawn against king
 

--- a/src/endgame.cpp
+++ b/src/endgame.cpp
@@ -112,6 +112,7 @@ Endgames::Endgames() {
   add<KRKN>("KRKN");
   add<KQKR>("KQKR");
   add<KBBKN>("KBBKN");
+  add<KBBPK>("KBBPK");
 

Then you just need to write your special function for that endgame, like the one below:

Code: Select all

/// King and two same colored bishops and a pawn against a king
template<>
Value Endgame<KBBPK>&#58;&#58;apply&#40;const Position& pos&#41; const &#123;

  Value result = VALUE_KNOWN_WIN;
  Square bishop1Square = pos.piece_list&#40;strongerSide, BISHOP&#41;&#91;0&#93;;
  Square bishop2Square = pos.piece_list&#40;strongerSide, BISHOP&#41;&#91;1&#93;;

  if (!opposite_colors&#40;bishop1Square, bishop2Square&#41;)
  &#123;
      // ....
  &#125;

  return result;
&#125;

The magic (that I suggest to read for people that wants to familiarize with medium/ advanced use of templates) makes your function to be called automatically whenever SF evaluates a position with that material combination, both for white and black.