That happens, but it's certainly the exception. Typically fixing a bug will increase playing strength. If not immediately, then after you correctly tune evaluation parameters that were trying to compensate for the bug.noobpwnftw wrote: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.
This is not obvious. Can you proof this?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.
There is a distinction to be made between speculative search techniques and bugs.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".
At the very least, the first are by design (the design may or may not be any good, but poor design is not the same as a bug).
This is a poor analogy. Key collisions cannot help, and since they cause an incorrect evaluation to be returned when they do happen, they have to hurt the program. The question is: how much? As it turns out, very little.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.
If you can eliminate hash collisions for free (ie, without increasing the size of a TT entry), it will improve the program (but very little, since the effect is small).
Yeah. Again, that has nothing to do with "helpful bugs".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.
You can be smart and never generate under promotions. Most of the time these are useless anyway. The question is whether you want your program to handle problems where the solution involves an under promotion. If you do, then not generating them doesn't just sound dumb.Someone may say it is "dumb" not using the robust version, but in fact it just sounds "dumb".
In the same way: do you want to detect repetitions correctly, or not? If you do, then there is no short-cut, it has to do it correctly.
I could speed up my in-check detection by storing the in-check result in the transposition table (and skip it the second time a position is entered). However, I know that my program will blow up if it ever reaches a position where it incorrectly thinks that it is (or is not) in check. Do I think that is acceptable? Well, I don't, but someone else might make a different decision.
In short, not fixing bugs because they lose Elo is stupid. Accepting side-effects of a design intended to increase Elo is not necessarily stupid (but might be considered a mis-feature).