Engine Feedback :)

[oriyonay]

Hi there!
I've taken all of your advice from my post last night and stripped my engine down to the bare minimum - basic evaluation and nothing too crazy in search - and am starting to slowly test each addition I've made.
I just made my engine's code public on github and would love any feedback/suggestions/bug finds that you could provide me with! From what you've told me, my engine should perform at least in the 2500 CCRL elo range.

Have a blessed day!
- Ori

[Mergi]

Hey! I had just a very quick glance over the search code, and one thing i noticed is that when you are saving/probing from the TT, you don't seem adjust your mate scores to always be of absolute length from the root position you are currently searching. This can lead to some very nasty bugs in the endgame, when you have a mate score in the TT from a previous search, and you might mistakenly think it's x moves long, since that was the length when you put it in your TT in some previous search, but now in fact, it might be of a different length.

[j.t.]

From what you've told me, my engine should perform at least in the 2500 CCRL elo range.

I just want to note that sometimes a lot of the playing strength depends on details. You can find engines with the same features (delta pruning, razoring, singular extensions, futility pruning, LMR, etc.), that perform wildly differently.

[amanjpro]

Hey! I had just a very quick glance over the search code, and one thing i noticed is that when you are saving/probing from the TT, you don't seem adjust your mate scores to always be of absolute length from the root position you are currently searching. This can lead to some very nasty bugs in the endgame, when you have a mate score in the TT from a previous search, and you might mistakenly think it's x moves long, since that was the length when you put it in your TT in some previous search, but now in fact, it might be of a different length.

My engine is doing the same... And I have not seen any strange behavior yet, even though I watch lots of games of my engine.

But I agree with you, this is an issue that needs attention... I hope I fix mine before next release

[Mergi]

My engine is doing the same... And I have not seen any strange behavior yet, even though I watch lots of games of my engine.

But I agree with you, this is an issue that needs attention... I hope I fix mine before next release

The issue with TT mate scores is somewhat alleviated (read: more obscured and harder to debug) if the engine is re-searching PV nodes, like OP does. However in some cases, for example if the PV changes, this can lead to wrong cutoffs in the tree if you have alphas/betas with now incorrect mate score stored in the TT as well.

[oriyonay]

My engine is doing the same... And I have not seen any strange behavior yet, even though I watch lots of games of my engine.

But I agree with you, this is an issue that needs attention... I hope I fix mine before next release

The issue with TT mate scores is somewhat alleviated (read: more obscured and harder to debug) if the engine is re-searching PV nodes, like OP does. However in some cases, for example if the PV changes, this can lead to wrong cutoffs in the tree if you have alphas/betas with now incorrect mate score stored in the TT as well.

Thank you for the response! I'm not sure I'm exactly understanding what the problem is exactly and how to fix it - how should I be handling mate scores?

[Ras]

Thank you for the response! I'm not sure I'm exactly understanding what the problem is exactly and how to fix it - how should I be handling mate scores?

Problem: you store the mate distance relative to your current root node. In the next turn, you are one full move further in the game, and the old mate distance stored in the TT is now wrong. What was a mate-in-6 in the turn before is now a mate-in-4.
Solution: when you store into the TT, you convert from root relative distance to node relative distance, and when reading, you convert from node distance to root distance.

[R. Tomasi]

Thank you for the response! I'm not sure I'm exactly understanding what the problem is exactly and how to fix it - how should I be handling mate scores?

Problem: you store the mate distance relative to your current root node. In the next turn, you are one full move further in the game, and the old mate distance stored in the TT is now wrong. What was a mate-in-6 in the turn before is now a mate-in-4.
Solution: when you store into the TT, you convert from root relative distance to node relative distance, and when reading, you convert from node distance to root distance.

I may be missunderstanding the problem, so don't shoot me if what I say is wrong. But isn't a simple remedy to that problem to implement mate scores in a way that represents the distance of the mate from the the position that corresponds to the score? I simply fail to imagine in what context distances from the root help in any way? Am I overlooking something?

[Ras]

But isn't a simple remedy to that problem to implement mate scores in a way that represents the distance of the mate from the the position that corresponds to the score?

Then how do you propagate a mate score found at the leaves back to the root? Do you change the score at each level?

I simply fail to imagine in what context distances from the root help in any way?

In the end, you need to select a root move in order to continue the game. You'll want to select the shortest mate because otherwise, you may not make progress towards actually delivering checkmate.

[R. Tomasi]

But isn't a simple remedy to that problem to implement mate scores in a way that represents the distance of the mate from the the position that corresponds to the score?

Then how do you propagate a mate score found at the leaves back to the root? Do you change the score at each level?

Yes, that's exactly what I do. My score class has a plyUp() method and a plyDown() method.

I simply fail to imagine in what context distances from the root help in any way?

In the end, you need to select a root move in order to continue the game. You'll want to select the shortest mate because otherwise, you may not make progress towards actually delivering checkmate.

Certainly. The shortest mate gives the highest score. So it get's selected by the AB search automatically.

It looks like that in my source code:

Code: Select all

sc = -subnode.search(-beta.plyDown(), -alpha.plyDown(), depthType(-1), depth + 1, principalVariation, str, allowStoreTT).plyUp();

The methods are implemented that way:

Code: Select all

constexpr auto plyUp() const noexcept
{
	return score(m_Value + ((m_Value < LOSINGVALUE) & (m_Value > MINVALUE)) - ((m_Value > WINNINGVALUE) & (m_Value < MAXVALUE)), 0);
}

constexpr auto plyDown() const noexcept
{
	return score(m_Value - ((m_Value < LOSINGVALUE) & (m_Value > (MINVALUE + 1))) + ((m_Value > WINNINGVALUE) & (m_Value < (MAXVALUE - 1))), 0);
}

[Edit: source code snippets]