Stockfish 1.2

[swami]

Stockfish 1.2 by Marco Costalba

Windows x64/win32 pgo builds.

http://www.mediafire.com/?5z2iyoznijm

Jim.

Thanks Jim and Marco!

[beachknight]

Thank you both of you.

Best,

[mcostalba]

For now, I have a few small questions:

Is it correct that the only difference between "Default" and "Optimistic" is the razoring conditions?

Hi Tord,

merry Christmas and happy new year!

How fast are you at reading the code! I am impressed

Yes you are right, it seems very strange but also a small difference like that gives very different results in my tests.

Regarding razoring the novelity here, as you have noticed for sure, is that I don't razor at depth one. This seems counterintuitive at first glance because razoring is a technique born to be applied near the leafs nodes, and only there.

I have found that at depth one, given the very low score, futility prune already will do the job and will discard with very small extra cost all the moves apart from the ones that you _really_ want to test: promotions, moves with good history and so on. Also captures and checks are tested, but there is no extra cost because you call qsearch() also from razoring anyway.

So the bottom line is: avoid razoring at depth one you remove a source of (horizont effect) errors with very small extra cost. First tests seem to validate this.

Is your new formula for futilityValue in search() really correct? It looks a little fishy (no pun intended) to me:

Code: Select all

                  futilityValue =  evaluate(pos, ei, threadID)
                                 + FutilityMargins[int(depth)/2 - 1]
                                 + 32 * (depth & 1);

The term "32 * (depth & 1)" looks very strange. You add 32 to futilityValue when the remaining search depth is an odd number. Is this really what you intended? If yes, what's the idea behind the formula? If the formula is correct, I would suggest simplifying the code by indexing FutilityMargins[] by depth-2 rather than depth/2-1, remove the term 32*(depth&1), and adjust the contents and size of the FutilityMargins[] array accordingly.

Tord

Yes this is what I intend. It happend that int(OnePly) == 2 and int(2*OnePly) == 4, so when I have a depthX so that int(depthX) == 3 then the futility margin used is instead that of depth == OnePly, but I want to take in account that actually we are at an higher depth then OnePly.

Your suggestion is right, I could do like this by I end up with a futility margin array of doubled size and where half of the content is redundant: when i is odd then futilityMargin == futilityMargin[i-1] + 32

But perhaps is more clear and better self documenting, as you suggest.

Marco

[mcostalba]

Does this mean I should wait for a Stockfish 1.2a?

No more releases after this, I promise!!!!!

Marco


P.S: At least for this year

[mcostalba]

Stockfish 1.2 by Marco Costalba

Windows x64/win32 pgo builds.

http://www.mediafire.com/?5z2iyoznijm

Jim.

Thanks Jim. Happy new year !!!