Fat binary?! How fat are these Mac binary ?Jeremy Bernstein wrote:Here's an OSX version, too, if you want to complete your collection. Intel-only 32/64-bit fat binary.
Thanks for all your compiles Jeremy.
Fat binary?! How fat are these Mac binary ?Jeremy Bernstein wrote:Here's an OSX version, too, if you want to complete your collection. Intel-only 32/64-bit fat binary.
Hi Jeremy,Jeremy Bernstein wrote: Stockfish_201_PA_GTB_Gran2c_x64 174,0/300 ···································································································· 0001==0111111101101010100010000001011010001010011110110101010100000001110=11010010=10111110000000011
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...ernest wrote:Hi Jeremy,Jeremy Bernstein wrote: Stockfish_201_PA_GTB_Gran2c_x64 174,0/300 ···································································································· 0001==0111111101101010100010000001011010001010011110110101010100000001110=11010010=10111110000000011
Why are there practically no draws?...
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.After 5811 games Mod- Orig: 1037 - 902 - 3872 +8 ELO (+- 3.6) LOS 97%
error bar comes from: 40 / sqrt($wins + $losses + $draws) * 7
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.Damir Desevac wrote: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...ernest wrote:Hi Jeremy,Jeremy Bernstein wrote: Stockfish_201_PA_GTB_Gran2c_x64 174,0/300 ···································································································· 0001==0111111101101010100010000001011010001010011110110101010100000001110=11010010=10111110000000011
Why are there practically no draws?...
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.5 seconds with a 1 millisecond increment (the increment is mostly to eliminate certain types of time loss).
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.BB+ wrote: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.5 seconds with a 1 millisecond increment (the increment is mostly to eliminate certain types of time loss).
Look at Jeremy's answer, seems your brain is somewhat damaged!...Damir Desevac wrote:if you just use your brain a little more...