Engine Feedback :)

[R. Tomasi]

Technically, I could move the sign-flip into the plyUp() and plyDown() methods. I do not want to do so however, because the framework is intented to be usable for board games with more than 2 players. In that case the sign-flip will have to be replaced by a function that makes the score "subjective", i.e. scoring from the perspective of the player that is on the move. Which is exactly what a sign-flip does in case of 2 players. With more players it get's slightly more complicated, but can be abstracted in the same fashion.

[Ras]

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

The problem here is that you call this for every move you make in a node. The standard way calls such an adjustment only once before the current node is examined (in the hash table lookup), and once for hash table store when the current node examination is finished.

[R. Tomasi]

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

The problem here is that you call this for every move you make in a node. The standard way calls such an adjustment only once before the current node is examined (in the hash table lookup), and once for hash table store when the current node examination is finished.

That is true. I do doubt that it makes any measurable difference, though. Especially since it is branchless.

Edit: thinking about it, I think actually the adjustments get called exactly the same amount of times in both variants: you will also have to do it for every move in a node, since (I presume) you will have to lookup up the position after the move was made from the TT.

[Ras]

That is true. I do doubt that it makes any measurable difference, though. Especially since it is branchless.

Branchless? Isn't it somewhat different for positive and negative mate scores? At least, the conversion between node relative and root relative needs that distinction.

you will also have to do it for every move in a node, since (I presume) you will have to lookup up the position after the move was made from the TT.

No, the latter is already down in the child node. Since I don't use the TT in QS, it means that this last level (at depth==0) doesn't have any TT lookups. Also, the score conversion upon TT lookup is only done if the stored depth draft is sufficient. Otherwise, only the stored hash move (if any) is retrieved.

[R. Tomasi]

That is true. I do doubt that it makes any measurable difference, though. Especially since it is branchless.

Branchless? Isn't it somewhat different for positive and negative mate scores? At least, the conversion between node relative and root relative needs that distinction.

Take a look at the code I posted. I assure you that it is branchless.

No, the latter is already down in the child node. Since I don't use the TT in QS, it means that this last level (at depth==0) doesn't have any TT lookups. Also, the score conversion upon TT lookup is only done if the stored depth draft is sufficient. Otherwise, only the stored hash move (if any) is retrieved.

Let me get this straight: you are definitely right, that I will call the methods at least as often as you, maybe even more often. I really doubt that will have any measurable impact on ELO. I guess at the end of the day it is a matter of philosophy and how you define the "score of a position". In my world-view the score of a position should reflect it's score as if I had to play it now, not some moves later in the game.

[Edit: less often => more often]

[Ras]

I assure you that it is branchless.

At the price of quite some additional operations though. I'm also surprised that you don't get compiler warnings for using binary & on boolean expressions.

I guess at the end of the day it is a matter of philosophy and how you define the "score of a position".

It's also about consistency for me. I'm using distance penalty for positive scores and distance reward for negative scores also on normal eval, not just on mate. Normal positions don't require that score adjustment because their reported score is somewhat arbitrary anyway, unlike mate distances which are an objective score.

[R. Tomasi]

I assure you that it is branchless.

At the price of quite some additional operations though. I'm also surprised that you don't get compiler warnings for using binary & on boolean expressions.

Well, when I wrote that code I profiled it extensively, actually. It's still faster than any implementation using branches. Concerning the bitwise & operator: it is actually not required to do the adjustments. It's purpose in my code is to make sure that +/- infinity scores do not get adjusted the same way mating scores would.