Stockfish Questions

[cdani]

Whay should I help you? you are just a troll pretending to be an engine author when you even didn't know what an engine is (very possibly you even don't know how to program). I don'tunderstand what's the point of posting nonsense here, if you would be interested in the subject probably you would try to mock up something, like a legal move generator, just to start, so I think you are not even interested in the subject, you post just for trolling.

Yes and I am a liar too. Please don't waste your time on me. I also only want to talk to troll friends.

At some point I was also doing basic questions or affirmations that sure seemed stupid, and may be from time to time it happens again. I did not follow the bottom line of Henk's posts, but it's difficult to me to assume that someone likes to troll so many times. With time and effort one can improve and becomes more moderated.

[Sven]

Sorry I didn't do any speed test, also because you version is not functionally equivalent with original (bench signature of 7657127 instead of 8285241)

Thanks, Marco, for even trying it, which is more than I could expect! In the first moment I was really surprised about your result since I had done intensive testing before posting. Now I found the problem in my test, it is caused by calling backmost_sq() with an empty bitboard in certain cases (e.g. when examining a white pawn on b2: white pawn a7 and/or c7, black pawn anywhere on b-file). This leads to undefined behaviour of lsb() resp. msb(), resulting in an unexpected value of RANK_8 for "theirRank" which flags the pawn as backward although it isn't. My test missed that by not enumerating pawn positions on b-file, I only enumerated all pawn positions on a- and c-file. It is very interesting, though, that the SF benchmark test finds that kind of problem, very impressive!

I could fix that problem somehow but then both elegance and speed will certainly be lost. Therefore I withdraw my proposal, thanks for considering it at least.

[Lars]

No it is not zero. It is Score(PawnValueMg,PawnValueEg).

[vittyvirus]

No it is not zero. It is Score(PawnValueMg,PawnValueEg).

As far as I know, the 'to' squares in case of promotions are RANK_1 or RANK_8. No pawn can practically be on those ranks. And the version of SF6 I've uses Score (0,0) in the PSQ tables for squares where a pawn can't be. See file psqtab.h. That said, if the original code is used with non-zero score for those squares, it will be a serious bug.

[Lars]

Yes they are zero there. But they are changed in Position::init.
Run "bench" in debug and put a breakpoint on the statement and you will see it.
Lars

[Sven]

Yes they are zero there. But they are changed in Position::init.
Run "bench" in debug and put a breakpoint on the statement and you will see it.
Lars

The "psq" array combines material values of pieces with the piece-square table PSQT. The combination of both is done in Position::init() as you say. Incremental score updates use "psq". PSQT is zero for pawns on 8th rank, but their piece value is non-zero.

So you are completely right (apart from the nitpicking detail that PSQT is not "changed" in Position::init() but it is used to initialize "psq"), and the SF code mentioned by Syed is indeed correct since its purpose is an incremental score update of both material and piece-square scores in one step.

Not easy to see, though.