Losing by draw

Code, algorithms, languages, construction...

Losing by draw

Postby Hamfer » Fri Mar 17, 2017 3:45 pm

8/1p4bP/2k5/P1P1pp2/2K5/5p2/5P2/2B5 w - - 37 85

My engine considers this position as a wining with +1.81.

After many moves, and near the 50 moves (without captures nor pawn moves), it sacrifies de the c4 pawn to preserve its advantage and the score drops to 0.62.

Bis repetita, after many moves, and near the 50 moves (without captures nor pawn moves), it sacrifies de the a4 pawn to preserve its advantages and the score drops to 0.18.

After many moves, it loses the game.

How resolve ths problem of draw by 50 moves.

Thank you for your help...
Hamfer
 
Posts: 11
Joined: Wed Dec 19, 2012 5:37 pm

Re: Losing by draw

Postby H.G.Muller » Sat Mar 18, 2017 12:00 pm

I noticed long ago that paying attention to the 50-move rule only serves to unnecessarily lose games, in exactly the way you describe. So none of my engines pays attention to the 50-move rule in its search.

The point is that engines should be programmed to like progress. (I.e. sufficient bonus for advancing Pawns, or trading material when they are ahead.) If they did not manage to make any progress in 50 moves in spite of a large positive evaluation, it is the best proof you can imagine that this imagined lead is a pure misevaluation, and that in reality they are not ahead at all. Blackmailing them to reset the ply counter through a sacrifice is a very bad idea in such a situation.

If your engine needs 50-move blackmail to convert a genuine won position into a win, there is something fundamentally wrong with its evaluation. (E.g. it might not award a delayed-loss bonus.)
H.G.Muller
 
Posts: 167
Joined: Sun Jul 14, 2013 10:00 am

Re: Losing by draw

Postby thevinenator » Wed Mar 22, 2017 4:31 pm

Good points H.G, so I thought I would consider removing it in my engine's code to see what happens.

Opening the unforeseen consequences door, I realized that I'm using the 50 rule counter as part of the 3-fold repetition test. the 50 move counter limits how far "back" I need to test for repeating positions. without it, the 3-fold would take longer each time it is called. considering the little amount of code needed to implement the 50 rule test, in my case, it is better to leave it in.

other engine developers can make their own determination.

most engines can't "see" 50 moves ahead and will probably never have to worry about it, and I'm sure that some kind of progress will have been made long before that, if not, then the position deserves to be halted after 50 moves. 3-move rep is far more likely to come into play in most deadlocked positions.
"An Engine's strength flows from the Search. But beware, pruning, extensions, reductions; the dark side of the Search are they. Once you start down the dark path, it will dominate and consume you, as it has to so many developers before.” -- Yoda
thevinenator
 
Posts: 65
Joined: Tue Jun 02, 2015 11:02 pm

Re: Losing by draw

Postby H.G.Muller » Wed Mar 22, 2017 11:12 pm

Indeed, one does need a counter to indicate how far back repetions could still occur. Even in drop games like Crazyhouse, where there are no irreversible moves, you don't want to search back beyond a null move. So what I meant by 'not paying attention to it' is that you shouldn't prune a node with score 0 if you detect that this counter gets above 100. If the engine is blissfully unaware that it nearly reached 50 moves, it won't panic, and won't make unsound sacrifices just to reset the counter.

Btw, what did work pretty well in my engine Joker in connection with the 50-rule move was to switch to an evaluation that awards Pawn advance more after the ply counter exceeds 40 or so. Then if it cannot make progress in 20 moves, the engine switches to plan B, where its efforts will be mainly directed towards pushing Pawns in a sound way.
H.G.Muller
 
Posts: 167
Joined: Sun Jul 14, 2013 10:00 am


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 2 guests

cron