AndrewGrant wrote:
The overhead of handling this issue is so small it should not be able to account for the drop of at least 3. Not to mention, that in theory, fixing this bug should be an elo gain.
I guess the reason is although the overhead is relatively small, the circumstances that having these information accurate would improve your search is even smaller.
I know it sounds dumb but sometimes I have bugged code in my evaluation code but it performs better than me doing it right.
I would just make a note and keep it as is.
AndrewGrant wrote:I had posted the upper bounds of the elo difference,
IE the elo was -7 +- 4
The overhead of handling this issue is so small it should not be able to account for the drop of at least 3. Not to mention, that in theory, fixing this bug should be an elo gain.
Even for an Elo ~2600 engine like Ethereal I would *never* refrain from fixing obvious bugs even if that appears to cost less than 10 Elo points. It may strike back later on when you don't expect it.
AndrewGrant wrote:I had posted the upper bounds of the elo difference,
IE the elo was -7 +- 4
The overhead of handling this issue is so small it should not be able to account for the drop of at least 3. Not to mention, that in theory, fixing this bug should be an elo gain.
Even for an Elo ~2600 engine like Ethereal I would *never* refrain from fixing obvious bugs even if that appears to cost less than 10 Elo points. It may strike back later on when you don't expect it.
I would also be interested in the following more realistic strength comparison:
Version A = after correcting the move generation issue regarding castling with a rook that has already moved,
vs.
Version B = A + incorporating castling rights and EP into the hash key
Sven is right: don't introduce a bug even if it supposedly gains 3 Elo. It will block certail useful developements later on (like castling rights evaluation). Three or four such decisions will eventually force You to rewrite the engine from scratch.
noobpwnftw wrote:
I know it sounds dumb but sometimes I have bugged code in my evaluation code but it performs better than me doing it right.
I would just make a note and keep it as is.
That doesn't just sound dumb, that is dumb.
In fact, I never bother to test what a bug fix does for playing strength, since I will apply the fix regarless and I often test changes by self-play.
If you think it the other way, you will figure out that some of these "bugs" are just a way to achieve better strength but you just don't yet know why.
First of all, Zorbist keys itself collides, although it happens very very very rare. Censoring en-passant & castling gives them more chances to collide, this is all I think of it. If you consider every "incorrectness" a bug then things like LMR and ProbCut shouldn't exist, similar to TT hash keys colliding since the ways they work are based on statistic results rather than being "right".
Then, there are other cheap ways to work around such colliding keys, i.e. you can verify that a TT move is indeed valid during search, if it gives better performance after all.
Lastly, search & evaluation cannot be exactly precise, there are many trade-offs between performance & precision, you may write an evaluation function that gives you results 10x more precisely or use no pruning strategies that introducing loss of information and you might find that it hurts your elo rather than improving it, simply because it runs slower.
Someone may say it is "dumb" not using the robust version, but in fact it just sounds "dumb".
Above said, you must ensure that at least perft reports correct nodes.
There are some fundamental rules that you cannot break, and you must know what shortcuts you took and handle their consequences properly.
Don't worry about doing something that seems unwise, like we've been using YBWC for years and now under the right circumstances the old-school lazy SMP does better and gaining over 30 elo on SF.
noobpwnftw wrote:Above said, you must ensure that at least perft reports correct nodes.
There are some fundamental rules that you cannot break, and you must know what shortcuts you took and handle their consequences properly.
And considering two identical positions different or two different positions identical only based on their hash key, as used in repetition detection, is certainly a fundamental rule that you cannot break.
Sven Schüle wrote:
And considering two identical positions different or two different positions identical only based on their hash key, as used in repetition detection, is certainly a fundamental rule that you cannot break.
I don't think repetition detection problem when disregarding EP can exist.
If one simply verify that the repeated positions didn't make a castling move, then no rule is broken.
Sven Schüle wrote:
And considering two identical positions different or two different positions identical only based on their hash key, as used in repetition detection, is certainly a fundamental rule that you cannot break.
I don't think repetition detection problem when disregarding EP can exist.
You don't *think* it can but you are wrong. Simply imagine a position where White has just made a pawn double step and the pawn is now left or right to a black pawn (and no pin would prevent EP). Then make two white and black moves after which all pieces return to their original squares. Identical position to the one four plies before? Nope, since now the EP target square is no longer set, even if all piece positions are the same.
noobpwnftw wrote:If one simply verify that the repeated positions didn't made a castling move, then no rule is broken.
"If one simply ..." is not what engines do if they want to implement repetition detection efficiently. In addition to the simple and fast comparison of two 64-bit numbers you would have to analyze the moves that were made in order to check whether these were castling moves or not. And also what you propose does not work. That no castling move was made does not tell *anything* about castling rights, therefore you can't derive the decision whether two positions are identical or not from the information whether castling moves were made.
