silly quiescence search bug

[mar]

Apart from what Alvaro mentioned, I probably wouldn't stand pat when in check, but that's a detail.
Since you get no captures/promotions, your qs should simply return eval for a 1-ply search.
So I would first verify that the code doesn't get inside

Code: Select all

if (m.isCatchMove || m.promoteTo == QUEEN)

block. If not then the bug is most likely unrelated to qs itself.
You said you get different results (depth 1) when using eval instead of qs. I don't see how so I would probably focus on how this can ever happen.

[flok]

Ok I found the problem. Even though I said it wasn't, it was a threading problem.
When going through my notes I noticed discrepancy between my laptop and my server: on my laptop I never had problems with threading, only with quiescence. This laptop is dual-core system. My server on the other hand I did have problems with threading, not depending on quiescence search.
So I added tons of printf-statements and that showed me that the scores returned by the threads were actually not used at all!
Looked at the code and it immediatly was obvious to me: I use atomic-booleans to signal out-of-time and please-stop-calculating (lightweight mutexes so to say). Now my threads get a pointer (not a reference) to some of these booleans. As I kind of use a mix of references and pointers (bad!) I made the mistake to do "if (!stop)" instead of "if (!*stop)". Fixed that and now it plays bit saner than before.

[Henk]

Ok I found the problem. Even though I said it wasn't, it was a threading problem.
When going through my notes I noticed discrepancy between my laptop and my server: on my laptop I never had problems with threading, only with quiescence. This laptop is dual-core system. My server on the other hand I did have problems with threading, not depending on quiescence search.
So I added tons of printf-statements and that showed me that the scores returned by the threads were actually not used at all!
Looked at the code and it immediatly was obvious to me: I use atomic-booleans to signal out-of-time and please-stop-calculating (lightweight mutexes so to say). Now my threads get a pointer (not a reference) to some of these booleans. As I kind of use a mix of references and pointers (bad!) I made the mistake to do "if (!stop)" instead of "if (!*stop)". Fixed that and now it plays bit saner than before.

It is also possible to use pointers in C# but then you have to mark the code as unsafe. Guess why.

[flok]

Ok I found the problem. Even though I said it wasn't, it was a threading problem.
When going through my notes I noticed discrepancy between my laptop and my server: on my laptop I never had problems with threading, only with quiescence. This laptop is dual-core system. My server on the other hand I did have problems with threading, not depending on quiescence search.
So I added tons of printf-statements and that showed me that the scores returned by the threads were actually not used at all!
Looked at the code and it immediatly was obvious to me: I use atomic-booleans to signal out-of-time and please-stop-calculating (lightweight mutexes so to say). Now my threads get a pointer (not a reference) to some of these booleans. As I kind of use a mix of references and pointers (bad!) I made the mistake to do "if (!stop)" instead of "if (!*stop)". Fixed that and now it plays bit saner than before.

It is also possible to use pointers in C# but then you have to mark the code as unsafe. Guess why.

I don't agree with pointers being unsafe. But mixing reference-usage and pointer-usage is not something I would advise.
Maybe when I have time I'll refactor all those references out of it.