May be a very good idea ...

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

neelbasant
Posts: 226
Joined: Sun Apr 01, 2012 7:57 pm

May be a very good idea ...

Post by neelbasant »

Hello all

Here is my suggestion .

when an engine analyses a position and finds 2 or more equally good moves.
Generally engine prefers a move which it can search deeper but does not prefer a move which it can not search deeper ( means the refutation moves or continuation is really hard to find.)
I here suggest engine should play the move whose refutation is slightly or more difficult to find , not the move it can search deeper ( its refutation is easy to find).

A try to explain.

suppose an engine finds equally or slightly less good moves.
let's say moves are a1 , b1 and c1.
1. a1...this has value of 0.23 .
a.engine can search deeper suppose 33 depth in 3 minutes.
b.reply is found in 30 seconds ( not hard to find the reply .means
slightly weaker or weaker engine can find the refutation in time).
c. And the continuation is easy. ( generally all good engines can
find the reply.)

2. b1.... this ha value of 0.22 ( or 0.23 for understanding )

a. engine can not search deeper suppose 30 or 31 depth in 3
minutes.
b. refutation is difficult to find .( say it takes about 2 minutes)
it means even good engines sometime can not find the
refutation.
c. and the continuation is difficult.

3. c1..... not important .


Now my suggestion is to play the b1 move which has better winning chance not the a1 move which the engine can search deeper.

Regards

Neel
User avatar
hgm
Posts: 27703
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: May be a very good idea ...

Post by hgm »

But usually engines do not know whether they have two nearly equal moves. They just know which move is the best, and nothing of the other moves other than that they are weaker. But not howmuch weaker. Fro that the engine would have to run in multi-PV mode. Which is very expensive, and as we know not competitive at all in games.

Neither will they reliably know how long it would take to find a refutation. The second move searched will benefit from what the first move searched will have left in the hash table; many of the variations of the second mide transpose to side branches of the first which have already been refuted sufficiently.

And that engine A has difficulty finding a refutation does not mean that engine B would not already prefer it from ply 1, just because of completely different reasons.
Dann Corbit
Posts: 12482
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: May be a very good idea ...

Post by Dann Corbit »

I have seen a similar idea implemented.
The move order for searching is according to how much time each node took on the previous ply.
The nodes which took the most time were searched first.
Ferdy
Posts: 4833
Joined: Sun Aug 10, 2008 3:15 pm
Location: Philippines

Re: May be a very good idea ...

Post by Ferdy »

neelbasant wrote:Hello all

Here is my suggestion .

when an engine analyses a position and finds 2 or more equally good moves.
Generally engine prefers a move which it can search deeper but does not prefer a move which it can not search deeper ( means the refutation moves or continuation is really hard to find.)
I here suggest engine should play the move whose refutation is slightly or more difficult to find , not the move it can search deeper ( its refutation is easy to find).

A try to explain.

suppose an engine finds equally or slightly less good moves.
let's say moves are a1 , b1 and c1.
1. a1...this has value of 0.23 .
a.engine can search deeper suppose 33 depth in 3 minutes.
b.reply is found in 30 seconds ( not hard to find the reply .means
slightly weaker or weaker engine can find the refutation in time).
c. And the continuation is easy. ( generally all good engines can
find the reply.)

2. b1.... this ha value of 0.22 ( or 0.23 for understanding )

a. engine can not search deeper suppose 30 or 31 depth in 3
minutes.
b. refutation is difficult to find .( say it takes about 2 minutes)
it means even good engines sometime can not find the
refutation.
c. and the continuation is difficult.

3. c1..... not important .


Now my suggestion is to play the b1 move which has better winning chance not the a1 move which the engine can search deeper.

Regards

Neel
I have this method which I use for opening preparation for human tournaments, what it does is given a position what will be the move that I will choose among other alternative moves such that my opponent will experience difficulties.
The move chosen is not really the best move by score but by move_changes and complexity measurements.
Here is how it works.
A. Analyze the given position by multipv 5
B. Make the score of bestmove as ref. score.
C. Assume an eval margin of 50cp
D. Any move in multipv with a score within 50cp from ref. score will be considered as candidate in move selection.
E. For each candidate move, make the move on the board and calculate its move changes and complexity score.
F. The move that will produce high complexity score and high move changes count will be chosen as the bestmove.
G. Calculation of complexity is whenever the pv move changes (during engine analysis), record the iteration depth and sum it. Also record the move changes counter.

Example run.

Code: Select all

Move Complexity Generator v2.0

enter engine filename? sf6.exe
enter pgn filename? blackmove11.pgn
enter number of threads to be used by the engine? 1
enter size of Hash in MB? 128
enter analysis time/pos in ms? 120000
enter color to analyze [w | b]? b
enter the move number to start the analysis? 11
enter the move number to end the analysis? 11
The position under consideration. What will be my move to confuse my opponents, according to stockfish 6 (sf6). At the end of the summary, the move with high complexity value is chosen.
[d]r1bq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R b - - 1 11
The summary.

Code: Select all

Cpu   : Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz

pgn file game 1

Calculate complexity at move no. 11

FEN: r1bq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R b - - 1 11
Player move: Bxd4

engine  : id name Stockfish 6 64 POPCNT
hash    : 128 MB
threads : 1

Top PV at 120s of analysis on multipv 5

1   +0/24 60.9s pv c6d4 e3d4 c5d4 f2d4 b7b5
2   +0/24 68.8s pv c5d4 e3d4 c6d4 f2d4 b7b5
3   +0/24 78.4s pv c5b4 f2e1 c6d4 e3d4 b4c5
4   +0/24 87.0s pv a8b8 c1b1 c5d4 e3d4 c6d4
5   +0/24 95.3s pv d8c7 f1d3 c5d4 e3d4 b7b5

analyze each move at 30s on multipv 1
eval margin   : +50cp
ref. score    : +0cp

multipv num   : 1
old fen       : r1bq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R b - - 1 11
new move      : c6d4
new fen       : r1bq1rk1/1p1n1ppp/p3p3/2bpP3/3n1P2/2N1B3/PPP2QPP/2KR1B1R w - - 0 12
move changes  : 0
complexity    : 0
expected reply: e3d4 c5d4 f2d4 b7b5 c1b1

multipv num   : 2
old fen       : r1bq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R b - - 1 11
new move      : c5d4
new fen       : r1bq1rk1/1p1n1ppp/p1n1p3/3pP3/3b1P2/2N1B3/PPP2QPP/2KR1B1R w - - 0 12
move changes  : 0
complexity    : 0
expected reply: e3d4 b7b5 d4e3 c8b7 c1b1

multipv num   : 3
old fen       : r1bq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R b - - 1 11
new move      : c5b4
new fen       : r1bq1rk1/1p1n1ppp/p1n1p3/3pP3/1b1N1P2/2N1B3/PPP2QPP/2KR1B1R w - - 2 12
move changes  : 3
complexity    : 25
expected reply: f2e1 c6d4 e3d4 b4c5 e1e3

multipv num   : 4
old fen       : r1bq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R b - - 1 11
new move      : a8b8
new fen       : 1rbq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R w - - 2 12
move changes  : 3
complexity    : 27
expected reply: c1b1 c6d4 e3d4 c5d4 f2d4

multipv num   : 5
old fen       : r1bq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R b - - 1 11
new move      : d8c7
new fen       : r1b2rk1/1pqn1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R w - - 2 12
move changes  : 1
complexity    : 18
expected reply: f1d3 c5d4 e3d4 b7b5 c1b1

The move that will generate the most complex position is: a8b8
From the engine log, here is the complexity and move changes calculation, after executing a8b8. Changes in pv move are bolded. If these changes happened at higher depths, complexity value will be high as the depths are added.
If the engine does not change its pv move that would mean it is an easy move, and will only get a low complexity score and low move changes counts.
>> position fen 1rbq1rk1/1p1n1ppp/p1n1p3/2bpP3/3N1P2/2N1B3/PPP2QPP/2KR1B1R w - - 2 12
>> go movetime 30000
info depth 1 seldepth 1 multipv 1 score cp -1 nodes 101 nps 50500 tbhits 0 time 2 pv f1e2
info depth 2 seldepth 2 multipv 1 score cp 3 nodes 212 nps 106000 tbhits 0 time 2 pv f1e2 c6d4
info depth 3 seldepth 3 multipv 1 score cp 3 nodes 365 nps 182500 tbhits 0 time 2 pv f1e2 c6d4 e3d4
info depth 4 seldepth 5 multipv 1 score cp 5 nodes 709 nps 354500 tbhits 0 time 2 pv f1e2 h7h6 d4c6 c5e3 f2e3
info depth 5 seldepth 6 multipv 1 score cp 5 nodes 1075 nps 358333 tbhits 0 time 3 pv f1e2 h7h6 d4c6 c5e3 f2e3 b7c6
info depth 6 seldepth 7 multipv 1 score cp 10 nodes 1722 nps 574000 tbhits 0 time 3 pv f1e2 h7h6 d4c6 c5e3 f2e3 b7c6 a2a3
info depth 7 seldepth 8 multipv 1 score cp 12 nodes 5079 nps 725571 tbhits 0 time 7 pv f1e2 c5d4 e3d4 b7b5 a2a3 c6d4 f2d4
info depth 8 seldepth 8 multipv 1 score cp 21 nodes 7342 nps 815777 tbhits 0 time 9 pv c1b1 c5d4 e3d4 b7b5 c3e2 c8b7 g2g3 c6d4 e2d4
info depth 9 seldepth 12 multipv 1 score cp 24 nodes 13109 nps 873933 tbhits 0 time 15 pv f1e2 c5d4 e3d4 b7b5 a2a3 b5b4 a3b4 b8b4 d4e3
info depth 10 seldepth 12 multipv 1 score cp 24 nodes 20551 nps 893521 tbhits 0 time 23 pv c1b1 c5d4 e3d4 c6d4 d1d4 b7b5 a2a3 c8b7 f1e2 h7h6 h1d1

info depth 11 seldepth 13 multipv 1 score cp 33 nodes 35011 nps 921342 tbhits 0 time 38 pv c1b1 c5d4 e3d4 b7b5 c3e2 b5b4 g2g4 a6a5 d4e3 c8b7 f1g2 a5a4 e2d4 c6d4
info depth 12 seldepth 14 multipv 1 score cp 14 nodes 60763 nps 964492 tbhits 0 time 63 pv c1b1 c5d4 e3d4 c6d4 d1d4 b7b5 a2a3 c8b7 g2g3 d8a5 f1g2 f8c8 c3e2 a5b6
info depth 13 seldepth 18 multipv 1 score cp 21 nodes 110483 nps 969149 tbhits 0 time 114 pv c1b1 c6d4 e3d4 c5d4 d1d4 b7b5 a2a3 c8b7 f1e2 d8b6 h2h4 h7h6 g2g3 b8c8 h1d1
info depth 14 seldepth 19 multipv 1 score cp 14 nodes 183601 nps 981823 tbhits 0 time 187 pv c1b1 c6d4 e3d4 c5d4 d1d4 b7b5 a2a3 c8b7 f1e2 d8b6 h1d1 f8c8 g2g3 c8c3 b2c3 b6c5
info depth 15 seldepth 20 multipv 1 score cp 20 nodes 256354 nps 985976 tbhits 0 time 260 pv c1b1 c6d4 e3d4 c5d4 d1d4 b7b5 a2a3 c8b7 f1e2 d8b6 h1d1 f8c8 g2g3 h7h6 f2f3 b6c5 h2h4
info depth 16 seldepth 20 multipv 1 score cp 15 nodes 352665 nps 1049598 tbhits 0 time 336 pv c1b1 c6d4 e3d4 c5d4 d1d4 b7b5 a2a3 c8b7 f1e2 d8e7 h1d1 f8c8 f2e3 h7h6 g2g3 e7c5 g3g4 c5b6
info depth 17 seldepth 20 multipv 1 score cp 16 nodes 467409 nps 1029535 tbhits 0 time 454 pv c1b1 c6d4 e3d4 c5d4 d1d4 b7b5 a2a3 c8b7 f1e2 d8e7 g2g3 b8c8 f2e3 h7h6 h2h4 e7c5 h1d1 f8e8 e3f3
info depth 18 seldepth 23 multipv 1 score cp 17 nodes 1138834 nps 1013197 tbhits 0 time 1124 pv c1b1 c6d4 e3d4 c5d4 d1d4 b7b5 a2a3 c8b7 f1e2 d8a5 h1d1 f8c8 f2e3 a5b6 e3g3 b6c5 h2h4 c5e7 h4h5
info depth 19 seldepth 25 multipv 1 score cp 6 nodes 2172631 nps 1016197 tbhits 0 time 2138 pv c1b1 c6d4 e3d4 c5d4 d1d4 b7b5 a2a3 c8b7 f1e2 d8a5 h1d1 f8c8 f2g3 a5b6 h2h4 d7c5 g3e3 b7c6 f4f5 a6a5 f5e6 f7e6
info depth 20 seldepth 27 multipv 1 score cp 0 upperbound nodes 3467657 nps 1015716 tbhits 0 time 3414 pv c1b1 c6d4
info depth 20 seldepth 27 multipv 1 score cp 0 nodes 4396944 nps 1016164 tbhits 0 time 4327 pv c1b1 c6d4 e3d4 c5d4 f2d4 b7b5 g2g3 d8a5 f1g2 c8b7 d4d2 f8c8 a2a3 a5b6 d2d4 b6a5 d4d2
info depth 21 seldepth 28 multipv 1 score cp 6 lowerbound nodes 4621639 nps 1015968 tbhits 0 time 4549 pv c1b1
info depth 21 seldepth 28 multipv 1 score cp 6 nodes 5380370 nps 1012680 tbhits 0 time 5313 pv c1b1 c6d4 e3d4 c5d4 f2d4 b7b5 g2g3 d8a5 f1g2 c8b7 d4d2 f8c8 h1e1 b5b4 c3e2 a5b6 e2d4 a6a5 f4f5 b7a6 f5e6 f7e6 d2g5
info depth 22 seldepth 29 multipv 1 score cp 0 upperbound nodes 8333092 nps 991562 tbhits 0 time 8404 pv c1b1 c6d4
info depth 22 seldepth 29 multipv 1 score cp 6 lowerbound nodes 8854774 nps 990245 tbhits 0 time 8942 pv c1b1
info depth 22 seldepth 29 multipv 1 score cp 0 upperbound nodes 8984191 nps 991194 tbhits 0 time 9064 pv c1b1 c6d4
info depth 22 seldepth 29 multipv 1 score cp 0 nodes 9943533 nps 989997 tbhits 0 time 10044 pv c1b1 c6d4 e3d4 c5d4 f2d4 b7b5 a2a3 d8e7 d4b4 e7d8 b4d4
info depth 23 seldepth 31 multipv 1 score cp 6 lowerbound nodes 11432123 nps 998351 tbhits 0 time 11451 pv c1b1
info depth 23 seldepth 31 multipv 1 score cp 0 upperbound nodes 12097422 nps 998713 tbhits 0 time 12113 pv c1b1 c6d4
info depth 23 seldepth 31 multipv 1 score cp 0 nodes 13716475 nps 992940 tbhits 0 time 13814 pv c1b1 c6d4 e3d4 c5d4 f2d4 b7b5 h2h4 b5b4 c3e2 a6a5 d4g1 a5a4 e2d4 d8c7 h4h5 a4a3 h5h6 g7g6 d4b5 c7c6 b5d4 c6c7
info depth 24 seldepth 31 multipv 1 score cp 0 nodes 16244815 nps 987466 tbhits 0 time 16451 pv c1b1 c6d4 e3d4 c5d4 f2d4 b7b5 a2a3 d8e7 d4b4 e7d8 b4d4
info depth 25 seldepth 31 multipv 1 score cp 0 nodes 18586019 nps 985734 tbhits 0 time 18855 pv c1b1 c6d4 e3d4 c5d4 f2d4 b7b5 a2a3 d8e7 d4b4 e7d8 b4d4
info depth 26 seldepth 31 multipv 1 score cp 0 nodes 23435764 nps 989268 tbhits 0 time 23690 pv c1b1 c6d4 e3d4 c5d4 f2d4 b7b5 a2a3 d8e7 d4b4 e7d8 b4d4
<< bestmove c1b1 ponder c6d4
>> quit
supersteve3d
Posts: 30
Joined: Mon Apr 28, 2008 5:10 pm

Re: May be a very good idea ...

Post by supersteve3d »

Very interesting.. I have been wanting to post regarding something similar.. trying to generate a opening repertoire for 'practical' chances .vs actual evaluation.

Ferdinand, is this complexity generator something you created yourself?
Ferdy
Posts: 4833
Joined: Sun Aug 10, 2008 3:15 pm
Location: Philippines

Re: May be a very good idea ...

Post by Ferdy »

supersteve3d wrote:Very interesting.. I have been wanting to post regarding something similar.. trying to generate a opening repertoire for 'practical' chances .vs actual evaluation.

Ferdinand, is this complexity generator something you created yourself?
Yes I created it, but the idea of complexity calculation is based from that of Bratko and Guid where there is something going on in the position when the engine changes its best move often. They use difference in evaluation score between bestmove and second bestmove in multipv mode whenever there are move changes, and sum it to get the complexity value while I only use the depth. I am still experimenting on different ways of calculating complexity. At some point I will also try their method. There is also a method used by Erik Varend and D. R. Ferreira. But it is interesting to see the actual position and move recommendation based from these different methods of calculation. Somehow I will implement these methods and compare their move recommendations.

Erik's paper here.
http://talkchess.com/forum/viewtopic.ph ... highlight=
User avatar
stegemma
Posts: 859
Joined: Mon Aug 10, 2009 10:05 pm
Location: Italy
Full name: Stefano Gemma

Re: May be a very good idea ...

Post by stegemma »

With humans, if you're in a bad position you should try to complicate, to let your opponent fall in error. With engines I don't think that it would work.

Choosing a complex move just to hope that opponent engine is weaker and could not find it have low sense, IMHO, because if you're playing against a weaker engine then you don't need this and if your opponent is stronger then it can look more deeper than your engine.

Of course, you only have to try, to see what happens.
Author of Drago, Raffaela, Freccia, Satana, Sabrina.
http://www.linformatica.com
Volker Annuss
Posts: 180
Joined: Mon Sep 03, 2007 9:15 am

Re: May be a very good idea ...

Post by Volker Annuss »

neelbasant wrote: Generally engine prefers a move which it can search deeper but does not prefer a move which it can not search deeper ( means the refutation moves or continuation is really hard to find.)
I here suggest engine should play the move whose refutation is slightly or more difficult to find , not the move it can search deeper ( its refutation is easy to find).
That means, when there is not a big difference in evaluation, the engine should always chose the transition to a pawn endgame by exchanging the last piece, because pawn endings always can get searched deeper than other positions.
User avatar
hgm
Posts: 27703
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: May be a very good idea ...

Post by hgm »

Well, actually the entire statement seems kind of weird. As far as I know engines do not prefer moves they can search deeper at all. They might search moves that they prefer more deeply, but that is something entirely different.
op12no2
Posts: 489
Joined: Tue Feb 04, 2014 12:25 pm
Full name: Colin Jenkins

Re: May be a very good idea ...

Post by op12no2 »

To try and make Lozza play more positionally I tried the following: when checking score > alpha, I extended it to >= alpha if the move was a slide and the current best move was a capture.

It didn't work. :)

I have yet to implement material imbalance because I'm not sure I 'get it' yet and. I want to encourage captures when ahead and discourage them when behind.