Shuffling Pieces

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, bob, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
lauriet
Posts: 198
Joined: Sun Nov 03, 2013 8:32 am
Contact:

Shuffling Pieces

Post by lauriet » Sat Apr 25, 2020 4:44 am

Hey all,
I have been playing my program again my Novag table top machine and BOTH programs seem to get to a middle game position
and then just shuffle pieces backwards and forwards. I suppose their Eval function is in balance and other moves are seen as not as
good. But a lot of these games end in a draw.
Maybe that's the way it should be, as a lot of GM games end in a draw, but I would like my program to have a bit more fight.

Is this a common thing?
Is there a way to fix this ? (I already have 3 fold draw code)

Thanks
Laurie (LTchess)

Dann Corbit
Posts: 11627
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: Shuffling Pieces

Post by Dann Corbit » Sat Apr 25, 2020 5:15 am

There are two common places where programs shuffle pieces (and it seems aimless).
One common place is when there is a large percentage of locked pawns forming a wall that is impenetrable or nearly impenetrable.
Often, even when there is something to do, it is far over the horizon, so the programs make silly, aimless moves.

Another one is when the aimless looking moves are really there because other moves will lose the game and they are trying to force a stalemate.

I imagine there are other reasons also. If you can give an example position, it might help.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
Evert
Posts: 2929
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Shuffling Pieces

Post by Evert » Sat Apr 25, 2020 5:32 am

You need to add an evaluation term so the program can see progress.
Programs start shuffling pieces if the evaluation is stuck in a local optimum. The program tries to maximise its score by staying close to this position.
A trick that may help is to drag the score closer to 0 as the half-move clock runs out (“tapered evaluation”), which may kick it out of the local optimum and onto a path where it can make progress. It doesn’t address the real issue though, and randomly pushing pawns to reset the half-move clock isn’t making progress. Worse, the program is wasting precious tempi, which is bad against stronger opponents.

So to fix it properly, the program needs to differentiate between moves that advance some goal, and moves that do not. In other words, it needs an evaluation term that can differentiate between child positions. Some sort of progressive evaluation term like king safety, pressure on a weak pawn or square or even progressive scoring of (candidate) passed pawns may help. You’ll probably have to look at the positions it gets stuck in to figure out what would work. If you don’t see it, feed the position into a strong program and see what plan it comes up with.

Oh, by the way: increased search depth will also help, but just like fiddling with the score based on the half move clock it doesn’t address the root cause of the problem.

Post Reply