OpenChess

Jeremy Bernstein wrote:Here's an OSX version, too, if you want to complete your collection. Intel-only 32/64-bit fat binary.

Fat binary?! How fat are these Mac binary ?

Thanks for all your compiles Jeremy.

Hi Jeremy

Since you keep calling these new SF something else, how come when I open the file, it displays the original SF 2.0.1 JA ??

Can you fix this please ? It is kinda annoying for me to delete and reinstall the original SF 2.01 JA each and every time on my comp...

Regards

Damir

Jeremy Bernstein wrote: Stockfish_201_PA_GTB_Gran2c_x64 174,0/300 ···································································································· 0001==0111111101101010100010000001011010001010011110110101010100000001110=11010010=10111110000000011

Hi Jeremy,
Why are there practically no draws?...

I've been using Stockfish PA GTB Gran2 all day and I think it's got the best hashing implementation I've ever seen! I've been running it at regular depth, at short depth, at high depth when I was away, and I've been all over the place, yet Stockfish has been remembering fine the moves I analyzed in the morning!

It very impressive the was it catches transpositions and gets up to known score and depth, after I've been focusing on really different positions than the current ones, very long time after I go back to them!

Terrific job guys!

ernest wrote:

Jeremy Bernstein wrote: Stockfish_201_PA_GTB_Gran2c_x64 174,0/300 ···································································································· 0001==0111111101101010100010000001011010001010011110110101010100000001110=11010010=10111110000000011

Hi Jeremy,
Why are there practically no draws?...

Because those were probably solutions to some endgames, where it was either White/Black win. Amazing to what conclusion you can come to, if you just use your brain a little more...

After 5811 games Mod- Orig: 1037 - 902 - 3872 +8 ELO (+- 3.6) LOS 97%
error bar comes from: 40 / sqrt($wins + $losses + $draws) * 7

This is where the discrepancy was. The standard deviation from the actual data is only 2.6 Elo (that is, 51.16 ±0.38%), and the formula you applied understates it, likely because the draw ratio here is a bit high.

Damir Desevac wrote:

ernest wrote:

Jeremy Bernstein wrote: Stockfish_201_PA_GTB_Gran2c_x64 174,0/300 ···································································································· 0001==0111111101101010100010000001011010001010011110110101010100000001110=11010010=10111110000000011

Hi Jeremy,
Why are there practically no draws?...

Because those were probably solutions to some endgames, where it was either White/Black win. Amazing to what conclusion you can come to, if you just use your brain a little more...

I think it has more to do with the very fast time control, 5 seconds with a 1 millisecond increment (the increment is mostly to eliminate certain types of time loss). At this speed, though, one of the engines typically makes a blunder and gets crushed. At longer time controls, there will be more draws. The tablebases might influence the results to a certain extent, as well.

We're essentially looking at engines of identical strength. The fast time control tests more or less ensure that nothing has changed which drives the strength of the engine down. As for changes which increase the engine strength, I think longer time control tests are necessary to determine that (unless the change results in wildly faster searching, you won't see it at these speeds). I doubt that any of the changes made so far have a significant effect on Stockfish's strength, except in the very late endgame, and that improvement would be common to any engine which can use tablebase results in forming evaluation.

Jeremy

5 seconds with a 1 millisecond increment (the increment is mostly to eliminate certain types of time loss).

Can the OS always change processes (GUI to engine) in 1ms? I think the standard Linux latency is ~10ms, though it could depend on other factors. I usually have 20ms as my minimal increment. Maybe you are getting a bunch of time losses. I don't think my draw rates (at 1s+20ms) drop below 40% between "equal" engines.

BB+ wrote:

5 seconds with a 1 millisecond increment (the increment is mostly to eliminate certain types of time loss).

Can the OS always change processes (GUI to engine) in 1ms? I think the standard Linux latency is ~10ms, though it could depend on other factors. I usually have 20ms as my minimal increment. Maybe you are getting a bunch of time losses. I don't think my draw rates (at 1s+20ms) drop below 40% between "equal" engines.

The 10 ms is just the interval in which processes will be preempted. If the GUI was single threaded, and it did a blocking read for each engine move, it would yield to the operating system, and presumably the engine would be scheduled next, since it has bytes in its input buffer. So the minimal time to change processes is probably much lower than 10 ms.

It's certainly the case, however, that there's much more randomness the faster you get.

Damir Desevac wrote:if you just use your brain a little more...

Look at Jeremy's answer, seems your brain is somewhat damaged!...