Development of Shen Yu

[hgm]

Indeed, that sounds like QS explosion. In the Mailbox Trials I got 84% QS nodes from KiwiPete at d=10. That was with futility pruning, but without pruning bad captures.

Are you sure you increase alpha to static eval before searching any moves?

[JVMerlino]

Indeed, that sounds like QS explosion. In the Mailbox Trials I got 84% QS nodes from KiwiPete at d=10. That was with futility pruning, but without pruning bad captures.

And now I'm concerned that my QS count is too low? But at d=10 Myrddin has 64% QS nodes. And I see that you weren't pruning bad captures. So that makes sense.

But I wonder why the percentage drops as Myrddin got deeper, since it was only 42% at d=20...

[AAce3]

I found the issue - two of them actually.
Firstly, I put bad captures towards the front instead of the back during QS. I didn't notice this because it still was SEE pruning captures.

Secondly, I messed up my zobrist key checking, so the TT was useless. Awkward...

Anyway, after I fixed those issues I seem to be getting better speeds (700ms for depth 9 startpos).

Buuuuut there's a big issue. I think I'm getting weird hash collisions, because from startpos my program thinks that white is +500 cp.

[algerbrex]

I found the issue - two of them actually.
Firstly, I put bad captures towards the front instead of the back during QS. I didn't notice this because it still was SEE pruning captures.

Secondly, I messed up my zobrist key checking, so the TT was useless. Awkward...

Anyway, after I fixed those issues I seem to be getting better speeds (700ms for depth 9 startpos).

Buuuuut there's a big issue. I think I'm getting weird hash collisions, because from startpos my program thinks that white is +500 cp.

One thing I did that was helpful in debugging Zobrist hashing in Blunder was to utilize perft. Firstly, make sure you use Zobrist hashing to run your perft tests and that you get the correct node counts. Second, if you do find an issue, generate the Zobrist hash for a position from scratch for each recursive perft call you make (after you make a move). Assuming you're incrementally updating the hash, this should pretty quickly reveal any issues you have when you're updating the hash in make move or restoring it in unmake move.

I remember most of my hashing bugs were because of casting and me not considering all the cases that would change the casting rights.

With all that said, what I would do too is go into your quiescence search and every time the evaluation function is called, I'd log any positions that are above +100 cp, so you can look at them more closely. This might also be an issue with your evaluation. Because that score of +500 isn't coming from nowhere.

The only time I've gotten weird bugs like this with Blunder was either an evaluation issue or hashing issue, so I do think you're on the right track.

[AAce3]

I briefly pasted the generate zobrist function into my makemove, and it didn't seem to find anything wrong. Probably should have taken the time to run perft with hashing too

Definitely should check the evaluation function. Almost forgot about that.

I've been meaning to put logging functionality for awhile now, but never seemed to remember.. maybe that will help find out what's wrong.

Anyway, the moves seem sensible. It seems like every little thing I change has a huge effect on the nodecount and eval... maybe because of evaluation issues, maybe because of hashing issues.

[JVMerlino]

Also, is the score exactly +500, or just near that? If the former, then I can only assume that you currently have a material-only evaluation, and perhaps some final score from a QS is filtering up to your PV. Otherwise, I would make sure that all of the terms in your search and eval are signed correctly (meaning, plusses and minuses). At some point we've all had the bug where some term for Black's eval was added instead of subtracted.

[algerbrex]

I briefly pasted the generate zobrist function into my makemove, and it didn't seem to find anything wrong. Probably should have taken the time to run perft with hashing too

Definitely should check the evaluation function. Almost forgot about that.

I've been meaning to put logging functionality for awhile now, but never seemed to remember.. maybe that will help find out what's wrong.

Anyway, the moves seem sensible. It seems like every little thing I change has a huge effect on the nodecount and eval... maybe because of evaluation issues, maybe because of hashing issues.

If all else fails, strip everything out and start with just plain negamax + qsearch, alpha-beta in both, and a material only eval. Make sure that's bug free and you're getting a score that makes sense from the startpos. I would say any score above +70-100 cp is suspect, especially if you're engine has a quiescence search and decent evaluation. Maybe even play a couple of blitz games. Then add back in a feature one at a time. And for each feature test and make sure the engine still works how you'd expect, and it gains the expected amount of Elo.

This is of course assuming you've already run your movegen through its paces and there aren't any movegen bugs. Because if there were, all bets would be off, as one illegal move being allowed in a certain position could make an otherwise equal position seem like it's great for white.

[hgm]

Just print the PV, look to wvhich position it leads, and what evaluation that position has.

[AAce3]

Also, is the score exactly +500, or just near that? If the former, then I can only assume that you currently have a material-only evaluation, and perhaps some final score from a QS is filtering up to your PV. Otherwise, I would make sure that all of the terms in your search and eval are signed correctly (meaning, plusses and minuses). At some point we've all had the bug where some term for Black's eval was added instead of subtracted.

I'm currently using PESTO tables. It worked fine I think, when I did pure minimax/alpha beta and move ordering without any TT or QS.

I briefly pasted the generate zobrist function into my makemove, and it didn't seem to find anything wrong. Probably should have taken the time to run perft with hashing too

Definitely should check the evaluation function. Almost forgot about that.

I've been meaning to put logging functionality for awhile now, but never seemed to remember.. maybe that will help find out what's wrong.

Anyway, the moves seem sensible. It seems like every little thing I change has a huge effect on the nodecount and eval... maybe because of evaluation issues, maybe because of hashing issues.

If all else fails, strip everything out and start with just plain negamax + qsearch, alpha-beta in both, and a material only eval. Make sure that's bug free and you're getting a score that makes sense from the startpos. I would say any score above +70-100 cp is suspect, especially if you're engine has a quiescence search and decent evaluation. Maybe even play a couple of blitz games. Then add back in a feature one at a time. And for each feature test and make sure the engine still works how you'd expect, and it gains the expected amount of Elo.

This is of course assuming you've already run your movegen through its paces and there aren't any movegen bugs. Because if there were, all bets would be off, as one illegal move being allowed in a certain position could make an otherwise equal position seem like it's great for white.

I have debugged movegen fully. I tested it on leorik's perft suite and it completed it without issue.
I will try stripping TT, I think it was fine when that wasn't working. (Although after I finish the logging stuff...)
Still haven't implemented UCI. I want to get a basic search down first.

Just print the PV, look to wvhich position it leads, and what evaluation that position has.

I'm not actually tracking pv right now, mainly because Shen Yu is going to be a MCTS engine. If nothing else works maybe I'll try that.

[AAce3]

I genuinely cannot find out what's wrong. I think I may have to rewrite the search routine.
What I ended up doing was stripping my search down to a beancounter and a basic alpha beta search. Nothing fancy.
It ended up outputting that white was a knight up from startpos.
This is awkward...