GitHub PushEvent at 2014-11-14 18:55:48
Repository: Stockfish
Actor: joergoster
Payload: {"shas":[["0608d6aaec6fe841550c9fc7142bba1b50d9ead6","693752e72974cd998f518005fa45f4b6dd733542@yahoo.co.in","Add bonuses for each threat instead of max threat value.\n\nUse SPSA tuned values for all threat bonuses\n\nSTC\nLLR: 2.96 (-2.94,2.94) [-1.50,4.50]\nTotal: 6074 W: 1284 L: 1160 D: 3630\n\nLTC\nLLR: 2.97 (-2.94,2.94) [0.00,6.00]\nTotal: 13563 W: 2402 L: 2232 D: 8929\n\nBench: 6981908\n\nResolves #94","Ajith",false],["d29a68f5854d0b529f2e0447fddcc6a61200c5aa","e7366a8c07bfdf2f7115ad219848d448a055b931@gmail.com","Rearrange check_time()\n\nRemove an ugly workaround for a gcc\nwarning while there.\n\nNo functional change.","Marco Costalba",false],["bcbab1937670ca39ddb0a216ff9a787e56b79b3a","e7366a8c07bfdf2f7115ad219848d448a055b931@gmail.com","Assume UCI 'nodes' is int64_t instead of int\n\nUCI specification is not clear on the size of\nintegers that are exchanged in the protocol, so\ninstead of a simple int, assume 'nodes' is a\nint64_t because we need a bigger size to store\nthis value in many real cases, especialy with\nvery long searches.\n\nNo functional change.\n\nResolves #75","Marco Costalba",false],["bc83515c9e821016d2113298ef988e99ceced1af","8ce396f43608b3b27b67158abb0b1885ca05027f@email","Removing some superfluous extern declarations\n\nNo functional change.\n\nResolves #93","mstembera",false],["8e98bd616e33cbe2d5cd7a22867a29d29bd67a1b","4b1bae11f1777a912b0957c30f951f323deff558@gmail.com","Apply King Safety later in the endgame\n\nIdea is to apply king safety later in the endgame. Previously, we didn't\napply KS in a RR vs. Q ending for example, which causes poor play.\nNow we calculate king attacks when the attacking side has a queen or more.\n\nSTC with 8moves_v3\nLLR: 3.06 (-2.94,2.94) [0.00,4.00]\nTotal: 38481 W: 6228 L: 5952 D: 26301\n\nLTC with 2moves_v1\nLLR: 2.95 (-2.94,2.94) [0.00,4.00]\nTotal: 51053 W: 8670 L: 8353 D: 34030\n\nBench: 7514010\n\nResolves #98","lucasart",false],["375797d51c8c18b98930f5e4c404b7fd572f6737","4b1bae11f1777a912b0957c30f951f323deff558@gmail.com","Retire CACHE_LINE_ALIGNMENT\n\nSpeed tests showed no benefit.\n\nNo functional change.\n\nResolves #97","lucasart",false],["7ebb872409d23b7c745d71ce5c21bea786d81aa0","4b1bae11f1777a912b0957c30f951f323deff558@gmail.com","Prune ttMove like any other\n\nThis should reduce search inconsistencies, and doesn't seem to have a measurable ELO Impact:\n\nSTC with Hash=16\nLLR: 2.95 (-2.94,2.94) [-3.00,1.00]\nTotal: 49264 W: 10076 L: 10007 D: 29181\n\nLTC with Hash=64\nLLR: 2.96 (-2.94,2.94) [-3.00,1.00]\nTotal: 82149 W: 14044 L: 14023 D: 54082\n\nPlus an extra test, to make sure it doesn't regress with strong hash pressure:\n\nSTC with Hash=4\nLLR: 2.95 (-2.94,2.94) [-4.00,0.00]\nTotal: 21498 W: 4327 L: 4246 D: 12925\n\nBench: 7302735\n\nResolves #100","lucasart",false],["3d2aab11d89493311e0908a9ee1a8288b9ff9b42","4b1bae11f1777a912b0957c30f951f323deff558@gmail.com","Be more optimistic in aspiration window\n\nBe more optimistic wrt search instability, and set the unviolated bound\nhalf window.\n\nSTC\nLLR: 2.96 (-2.94,2.94) [-1.00,4.00]\nTotal: 16362 W: 3371 L: 3197 D: 9794\n\nLTC\nLLR: 2.94 (-2.94,2.94) [0.00,5.00]\nTotal: 21666 W: 3780 L: 3569 D: 14317\n\nBench: 6807896\n\nResolves #105","lucasart",false],["8631b08d9704dac256462f6b5b885a4d8b0a9165","4b1bae11f1777a912b0957c30f951f323deff558@gmail.com","Codestyle massage Search::init()\n\n* remove some erroneous comments, that were based on the ONE_PLY == 2.\n* rename hd to d, because there's no more half-depth in SF.\n* rescope variables into the for loops.\n* reindent the for loops correctly.\n* add a comment to explain the eval improving part (not so obvious to read\nthis code as array has 4 dimensions).\n\nNo functional change.","lucasart",false],["6fb0a1bc4050dd9b15e9c163c46c60f25c48137d","e7366a8c07bfdf2f7115ad219848d448a055b931@gmail.com","Introduce distance() and unify some API\n\nOriginal work by Lucas.\n\nNo functional change.","Marco Costalba",false],["57fdfdedcf8c910fc9ad6c827a1a4dae372d3606","e7366a8c07bfdf2f7115ad219848d448a055b931@gmail.com","Assorted code-style triviality\n\nNo functional change.","Marco Costalba",false],["1b0df1ae141be1461e3fbe809b5b27c3e360753f","e7366a8c07bfdf2f7115ad219848d448a055b931@gmail.com","Retire pvMove in search()\n\nNow we can directly replace it with\nthe definition resulting in simpler\nand possibly faster code because\nPvNode is evaluated at compile time.\n\nNo functional change.","Marco Costalba",false],["d709a5f1c52f253a09cd931d06b5197dcdafc3ba","4b1bae11f1777a912b0957c30f951f323deff558@gmail.com","Fix bounds of FutilityMoveCounts\n\nThis is a left-over from ONE_PLY == 2.\n\nNo functional change.\n\nResolves #107","lucasart",false],["c6d45c60b516e799526f1163733b74b23fc1b63c","4b1bae11f1777a912b0957c30f951f323deff558@gmail.com","Profile Build with Hash=16\n\n16MB for 1\" searches is more comensurate with the average use case.\n\nAnd 16 is the default used by stockfish bench, so it makes sense to be\nconsistent, if only to have the same minimum memory requirement for using\nSF and compiling it with PGO.\n\nNo functional change.\n\nResolves #109","lucasart",false],["db4b8ee000912f88927757eb8dee255b8d66a4b4","e7366a8c07bfdf2f7115ad219848d448a055b931@gmail.com","Use Depth instead of int in search\n\nAnd make it more ONE_PLY value independent,\nalthough we are not there yet.\n\nNo functional change.\n\nResolves #111","Marco Costalba",false],["b777b17f6ff7fe9670d864cf31106fdefdca3001","e7366a8c07bfdf2f7115ad219848d448a055b931@gmail.com","Use if/else instead of goto\n\nReal men jump/branch by hand...but\nwe prefer the humble way.\n\nMoved also some uci info code where it\nbelongs, while there.\n\nNo functional change.\n\nResolves #110","Marco Costalba",false],["234344500f4d6e35c6992a07e0b1adb59aea209e","4b1bae11f1777a912b0957c30f951f323deff558@gmail.com","Use quiet ttMove in qsearch() (7962287)\n\nDaniel Jose reported that it was an elo gain in his engine:\nhttp://www.talkchess.com/forum/viewtopic.php?t=54290\n\nSTC: Hash=16\nLLR: 2.95 (-2.94,2.94) [-3.00,1.00]\nTotal: 33067 W: 6670 L: 6571 D: 19826\n\nLTC: Hash=64\nLLR: 2.96 (-2.94,2.94) [-3.00,1.00]\nTotal: 41181 W: 7008 L: 6920 D: 27253\n\nAnd another one to verify no regression with hash pressure:\n\nSTC: Hash=4\nLLR: 2.96 (-2.94,2.94) [-4.00,0.00]\nTotal: 25085 W: 5059 L: 4991 D: 15035\n\nVerified that qsearch does not explode after this patch (recapture threshold).\n\nBench 7962287\n\nResolves #112","lucasart",false],["4739037f967ac3c818907e89cc88c7b97021d027","0da429529a7db13f590db06335220b388ae04581@gmail.com","100% accurate PV display\n\nThis gives SF accurate PVs, such that the evaluation of the leaf node in\nthe PV matches the score backed up to the root (99% of the time.\nq-search will use the value stored in the hash table instead of the eval\nvalue sometimes).\n\nOne drawback is that fail-high/low only get a minimal 2 move PV.\n\nIt doesn't add any additional overhead to the non-PV codepath except an\nextra eight bytes to the SearchStack structure in multi-threaded\nsearches.\n\nA core part of this is not pruning based on TT score in PV nodes. This\nwas measured as not being a regression at multiple TCs, except for one\nexception, fast TC with huge hash, which is not realistic for longer\nsearches.\n\nSTC - 1 thread, 128 mb hash\nELO: 1.42 +-3.1 (95%) LOS: 81.9%\nTotal: 20000 W: 4078 L: 3996 D: 11926\n\nSTC - 3 thread, 128 mb hash\nELO: -3.60 +-2.9 (95%) LOS: 0.8%\nTotal: 20000 W: 3575 L: 3782 D: 12643\n\nSTC - 3 thread, 8 mb hash\nELO: 0.12 +-2.9 (95%) LOS: 53.3%\nTotal: 20000 W: 3654 L: 3647 D: 12699\n\nLTC - 3 thread, 32mb hash\nELO: 2.29 +-2.0 (95%) LOS: 98.8%\nTotal: 35740 W: 5618 L: 5382 D: 24740\n\nBench: 6984058\n\nResolves #102","Gary Linscott",false],["d57df009092e34d260fe4fd8105c38a611f5742e","f8b9c0cff2f545eac9a7d41c0869c56ba3ea7e96@googlemail.com","Merge branch 'master' into analyzing\n\nConflicts:\n\tsrc/endgame.cpp","joergoster",true],["289d7fb3569bf12fa3188bb2ddfcd0a92ae13f84","f8b9c0cff2f545eac9a7d41c0869c56ba3ea7e96@googlemail.com","Some maintenance work.\nbench: 7299708","joergoster",true]],"size":20,"ref":"refs/heads/analyzing","head":"289d7fb3569bf12fa3188bb2ddfcd0a92ae13f84"}