Strange results after change in positional representation

[Fguy64]

OK, I have rewritten my engine to use a 10 x 10 board, instead of a 8x8 board, in order to speed up moveGen.

For crude testing I just run WAC positions and measure time and leaf nodes.

Ok in testing the same moves are found with the same eval, which is good. Also, leaf nodes per second is up significantly, which is also good.

However, leaf node count is up significantly for these positions, even though there was no meaningful change to alphaBeta and move ordering algorithms.

For the purpose of these particular tests, it is straight up alphaBeta withMVV/LVA move ordering on captures, no qSearch, material evaluation only, and no hash table. Once I can explain my results, I'll expand the scope of my testing.

Anyways, I am at a loss to explain why leaf nodes are up so much. I suppose it has to be a change in move ordering, or alphaBeta pruning, but i don't see any such change.

Anyone have any suggestions on this? I can post before and after engine code if desired, but I thught I'd ask first.

Thanks,
Fred.

[hgm]

If you merely change board representation, everything should be exacty the same, also the node counts, to the very last node. If not, you messed up. Did you properly adapt the layout o Piece-Square and Zobrist Tables to the new board format? Also in the initialization code for these tables?

[Fguy64]

If you merely change board representation, everything should be exacty the same, also the node counts, to the very last node. If not, you messed up. Did you properly adapt the layout o Piece-Square and Zobrist Tables to the new board format? Also in the initialization code for these tables?

Thanks, your response is more or less what I expected. There should be no change in node counts. In my initial tests, piece/square and zobrist tables aren't used, it's just bare bones alphaBeta.

I guess I'll have to employ my fine-tooth comb. I'll let you know how it goes.

[metax]

Did you change the position evaluation or do the changes in board representation affect your evaluation in some way? If the eval changes, the node count may also change.

I also want to assure that the node counts for a given DEPTH increase. If the node counts for a given TIME increase, that's only what you want, because then your nps went up. Am I right that you measured the node counts for the depths (I know that question is pretty stupid, but I just want to assure this)?

You say there were no significant changes to move ordering and search. But also seemingly insignificant changes can affect the node count. You are sure that there ere absolutely NO changes to move ordering and search.

What could also be the case is that there is simply a bug in your board representation so that for example the MVV/LVA move ordering does not work properly.

[Fguy64]

Did you change the position evaluation or do the changes in board representation affect your evaluation in some way? If the eval changes, the node count may also change.

I also want to assure that the node counts for a given DEPTH increase. If the node counts for a given TIME increase, that's only what you want, because then your nps went up. Am I right that you measured the node counts for the depths (I know that question is pretty stupid, but I just want to assure this)?

You say there were no significant changes to move ordering and search. But also seemingly insignificant changes can affect the node count. You are sure that there ere absolutely NO changes to move ordering and search.

What could also be the case is that there is simply a bug in your board representation so that for example the MVV/LVA move ordering does not work properly.

Thanks Luca, there was no change to the evaluate() function, touch wood. I did make some changes to array indexing, nothing more. All I am using for this test is a straightforward material evaluation. But I'll double check for typos.

Also, I neglected to mention that these tests use only fixed depth search, with no qSearch.

But yeah, like you say there must be some kind of a change in search or move ordering, I just haven't found it yet. I'll let you know.

[hgm]

Well, use the lowest depth where you see any difference in node count at all, and then zoom in on the branch with the difference by printing node counts of sub-trees at ply=1, ply=2, etc. Just like you would do with split perft.

[bob]

OK, I have rewritten my engine to use a 10 x 10 board, instead of a 8x8 board, in order to speed up moveGen.

For crude testing I just run WAC positions and measure time and leaf nodes.

Ok in testing the same moves are found with the same eval, which is good. Also, leaf nodes per second is up significantly, which is also good.

However, leaf node count is up significantly for these positions, even though there was no meaningful change to alphaBeta and move ordering algorithms.

For the purpose of these particular tests, it is straight up alphaBeta withMVV/LVA move ordering on captures, no qSearch, material evaluation only, and no hash table. Once I can explain my results, I'll expand the scope of my testing.

Anyways, I am at a loss to explain why leaf nodes are up so much. I suppose it has to be a change in move ordering, or alphaBeta pruning, but i don't see any such change.

Anyone have any suggestions on this? I can post before and after engine code if desired, but I thught I'd ask first.

Thanks,
Fred.

Did you change the order in which you generate moves? That will make a difference.

One bit of advice. Do not assume "cosmic rays" or something else will explain this. Debug it down to the last node. Most likely, you will find bugs in the original and the new version. But once you make them match, you are that much closer to a reliable engine.

[MattieShoes]

Did you change the order in which you generate moves? That will make a difference.

One bit of advice. Do not assume "cosmic rays" or something else will explain this. Debug it down to the last node. Most likely, you will find bugs in the original and the new version. But once you make them match, you are that much closer to a reliable engine.

I had that happen so many times -- while searching for one elusive bug, I'd find and fix a couple minor ones I didn't even know about.

[bob]

Did you change the order in which you generate moves? That will make a difference.

One bit of advice. Do not assume "cosmic rays" or something else will explain this. Debug it down to the last node. Most likely, you will find bugs in the original and the new version. But once you make them match, you are that much closer to a reliable engine.

I had that happen so many times -- while searching for one elusive bug, I'd find and fix a couple minor ones I didn't even know about.

Happened to me in the 22.0 rewrite using the new bit numbering. As I made errors in re-coding the various masks, and then tracked them down, I also found a bug here and there in the old version as well.

As I said, take _nothing_ for granted, and you end up with a stronger and more robust program. I have seen _lots_ of programmers say "they only differ by a few hundred nodes out of 50 million, that's not a problem. It might be a _serious_ problem since it is unknown.

[Fguy64]

OK, I discovered that increasing the board size disrupted my move ordering.

In the old system, I had managed to cram information on source square, destination square, promotion piece, and a sort key for move ordering all into one 32 bit integer, and I forgot that I only had 1 bit to spare.

By moving to a larger board, I added an extra bit to source and destination square indexes, and this pushed the most significant bit of my sort key off of the left end.

I'll have to rethink my scheme for storing move information during moveGen.

Thanks for all the suggestions.