TalkChess.com

Thank you to inform me of this problem. I have very few time now but I will see in the next days what's the reason of that issue.

I have released a new version of my engine. The changes: Android executable Max Threads set to 128 Simplify king safety and increased sensivity Improved threatened pieces evaluation Tuning Added some more endgame knowledge Tuned reductions Improved history heuristic Tuned iid reduction formula Some ...

In search and qsearch I probe only wdl. Syzygy are compressed. I haven't tried with a shorter time control, I think that with a short tc there wouldn't be much improvement.

In my engine I probe syzygy also in qs, it's a little improvement at tc=5:00

How do you use this big amount of data?

During search I handle only "isready", "ponderhit" and "stop". Handle the options would add more complexity to the engine. It's better for the engine to receive the other commands while it's not searching.

I think it's a good idea that can worth a try. In my engine I use the zobrist hashing that is not really expensive because with the key I have also to incrementaly update the material+pst scores. I use a struct that contains all like this: typedef struct { uint64_t Hash; int16_t ScoreMg; int16_...

Of course less weights are easier to tune, but even if they are well tuned they can't express all the knowledge of a more complex evaluation.
So the answer is not so easy.

In the evaluation function is it better to have a few weights but well tuned or more weights not well tuned?
What does your experience say?

I have just released a new version of my engine. These are the changes: Bug fixes Default Drawscore is set to -5 MultiPV mode Improved history heuristic Halved the pawns hash table size (now it's 1/16 of the Hash size) Tuning Added bonus/malus for the distance of the kings from candidate passers Imp...