This is automatic when you have higher endgame values for the pieces than opening values. Then the leading side can increase its advantage by furthering the game phase (i.e. trading).
It is a bit more subtle than that, however: when ahead you want to trade pieces, but when behind you want to trade Pawns. But the Pawn value has to increase towards the end-game too, to encourage trading pieces when you have a Pawn advantage. This would not affect the eagerness to trade Pawns for the side that is behind in pieces, unless Pawns have a negative weight in the game Phase. (But usually they have zero weight).
So you should have a term in the evaluation that is something like
c*(whitePawns + blackPawns)*materialEval
which biases you against Pawn trading when ahead.
May be a very good idea ...
Moderators: hgm, Dann Corbit, Harvey Williamson
-
hgm
- Posts: 27701
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
op12no2
- Posts: 489
- Joined: Tue Feb 04, 2014 12:25 pm
- Full name: Colin Jenkins
Re: May be a very good idea ...
Ah, I see. I was trying scaling the eval based on material and all sorts of weird and wonderful ideas. I'll give it a whirl; thanks.
-
supersteve3d
- Posts: 30
- Joined: Mon Apr 28, 2008 5:10 pm
Re: May be a very good idea ...
Hi Ferdinand,Ferdy wrote: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.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?
Erik's paper here.
http://talkchess.com/forum/viewtopic.ph ... highlight=
Would you be willing to share your program sometime? I would be interested in trying it also for human play. See how it compares to my existing database.
Regards,
Steve.
-
Ferdy
- Posts: 4833
- Joined: Sun Aug 10, 2008 3:15 pm
- Location: Philippines
Re: May be a very good idea ...
I will share this but not now, I need to check this thoroughly. I also plan to implement other method of complexity measurements and compare with my simple method. Give me around 5 days and I will share the simple method.supersteve3d wrote:Hi Ferdinand,Ferdy wrote: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.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?
Erik's paper here.
http://talkchess.com/forum/viewtopic.ph ... highlight=
Would you be willing to share your program sometime? I would be interested in trying it also for human play. See how it compares to my existing database.
Regards,
Steve.
-
xmas79
- Posts: 286
- Joined: Mon Jun 03, 2013 7:05 pm
- Location: Italy
Re: May be a very good idea ...
this has been another problem in my ngn. despite the higher eg values,sometimes weird thing happen. PST are responsible of such things,since (let's say) if you have a rook in 7th rank you get a bonus for this. if you trade it for a weak opponent rook you will get advantage because the game phase will advance,however your 7th rook advantage evaporates,and of course you "double" lose advantage because your opponent now has no penalty for the bad rook...I still didn't find a way to balance everything. I already started to write my tuner, however I know it will take forever or a very similar time.......hgm wrote:This is automatic when you have higher endgame values for the pieces than opening values. Then the leading side can increase its advantage by furthering the game phase (i.e. trading).
It is a bit more subtle than that, however: when ahead you want to trade pieces, but when behind you want to trade Pawns. But the Pawn value has to increase towards the end-game too, to encourage trading pieces when you have a Pawn advantage. This would not affect the eagerness to trade Pawns for the side that is behind in pieces, unless Pawns have a negative weight in the game Phase. (But usually they have zero weight).
So you should have a term in the evaluation that is something like
c*(whitePawns + blackPawns)*materialEval
which biases you against Pawn trading when ahead.
-
hgm
- Posts: 27701
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: May be a very good idea ...
Well, that sounds normal. If advancing the game stage is an advantage, you will tend to trade other advantages to achieve it. Of course there must still be an advantage left after the trade, or there would be nothing to amplify.
You should not make the engine too impatient. Normally, when ahead, you would get the opportunity to trade sooner or later anyway, so it is not that important to do it right away. You just want to prevent the engine would never trade because it wants to preserve some small and insignificant advantage that won't grow by itself.
You should not make the engine too impatient. Normally, when ahead, you would get the opportunity to trade sooner or later anyway, so it is not that important to do it right away. You just want to prevent the engine would never trade because it wants to preserve some small and insignificant advantage that won't grow by itself.
-
supersteve3d
- Posts: 30
- Joined: Mon Apr 28, 2008 5:10 pm
Re: May be a very good idea ...
Appreciate it..Ferdy wrote:I will share this but not now, I need to check this thoroughly. I also plan to implement other method of complexity measurements and compare with my simple method. Give me around 5 days and I will share the simple method.supersteve3d wrote:Hi Ferdinand,Ferdy wrote: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.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?
Erik's paper here.
http://talkchess.com/forum/viewtopic.ph ... highlight=
Would you be willing to share your program sometime? I would be interested in trying it also for human play. See how it compares to my existing database.
Regards,
Steve.
-
bob
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: May be a very good idea ...
There have been discussions about this in the past. Most were normally centered around computers playing humans, with the keyword being "discernibility". IE given two moves that are close in score, play the one that has the more precise path (many moves that are difficult to find and if not played lead to a loss or much worse position).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 remember Berliner talking about an idea, and I actually implemented it in Cray Blitz (but only enabled against humans) that went something like this:
You search iterations 1 through N and you have a move that looks good, but at iteration N+1 it fails low, significantly, and another move is chosen. Here we would play the original move that failed low. It looked best up until the last very deep search, where all moves look bad at depth N+1 (even though a different one looks a little better). I have seen plenty of cases where the previous best move failed low and dropped something like a knight to a very deep tactic, so the program would just throw the knight away for two pawns, but once the knight capture is made, the reply (recapture) is trivial for the human to find. The idea was to make the human show us he could see the deep tactic that we didn't see until the last minute ourself.
multi-pv is a non-starter of course, in real games. WAY too expensive and it will significantly reduce depth.
Nobody has yet found a way to measure discernibility. It would be a significant thing against humans (not against good programs, obviously as you would have to assume they can discern anything on their move that you saw on yours.
This is simply yet another example where we search an impossibly large tree, and use hardly any of the information that is hidden inside other than the path to the optimal minimax value. Singular extensions touch on the idea, although not as they are typically used. But they do highlight a critical/key move where very precise play is required.
-
supersteve3d
- Posts: 30
- Joined: Mon Apr 28, 2008 5:10 pm
Re: May be a very good idea ...
Thanks Bob.bob wrote:
There have been discussions about this in the past. Most were normally centered around computers playing humans, with the keyword being "discernibility". IE given two moves that are close in score, play the one that has the more precise path (many moves that are difficult to find and if not played lead to a loss or much worse position).
I remember Berliner talking about an idea, and I actually implemented it in Cray Blitz (but only enabled against humans) that went something like this:
You search iterations 1 through N and you have a move that looks good, but at iteration N+1 it fails low, significantly, and another move is chosen. Here we would play the original move that failed low. It looked best up until the last very deep search, where all moves look bad at depth N+1 (even though a different one looks a little better). I have seen plenty of cases where the previous best move failed low and dropped something like a knight to a very deep tactic, so the program would just throw the knight away for two pawns, but once the knight capture is made, the reply (recapture) is trivial for the human to find. The idea was to make the human show us he could see the deep tactic that we didn't see until the last minute ourself.
multi-pv is a non-starter of course, in real games. WAY too expensive and it will significantly reduce depth.
Nobody has yet found a way to measure discernibility. It would be a significant thing against humans (not against good programs, obviously as you would have to assume they can discern anything on their move that you saw on yours.
This is simply yet another example where we search an impossibly large tree, and use hardly any of the information that is hidden inside other than the path to the optimal minimax value. Singular extensions touch on the idea, although not as they are typically used. But they do highlight a critical/key move where very precise play is required.
Yes.. am hoping that we can have ideas to draft out some kind of algorithm for this 'discernibility'.
The use for me is not for live games but rather analysis. Most of us have accumulated significant databases based on minimax evaluations. It would be useful to find moves that offer good practical chances against humans.
I dare say that Chess is a draw.. if I am right.. such tools will become more and more valuable in time to come.
-
Ferdy
- Posts: 4833
- Joined: Sun Aug 10, 2008 3:15 pm
- Location: Philippines
Re: May be a very good idea ...
I forgot, I had already shared this toolsupersteve3d wrote:Appreciate it..Ferdy wrote:I will share this but not now, I need to check this thoroughly. I also plan to implement other method of complexity measurements and compare with my simple method. Give me around 5 days and I will share the simple method.supersteve3d wrote:Hi Ferdinand,Ferdy wrote: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.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?
Erik's paper here.
http://talkchess.com/forum/viewtopic.ph ... highlight=
Would you be willing to share your program sometime? I would be interested in trying it also for human play. See how it compares to my existing database.
Regards,
Steve.
http://www.talkchess.com/forum/viewtopi ... 60&t=57258