I have the following comments:mcostalba wrote:Joona, I think we should give a kind of "clean solution" definition to our friends herezamar wrote:I understand, but we need a clean solution to fix this. About the practical cases: I don't know
Clean solution: a solution is considered clean _only_ when
1) It removes more lines of code then it adds
2) Is supported by strong and serious testing evidence
It is interesting to note that Uri's suggestions although always imaginative and creative consistently fail both the above points. I have since long abandoned the wishful thinking of point 2, but at least point 1 _could_ be honored once in a while.
Uri, just to be clear. Read my lips: "No Hacks !"
The secret of SF quick improvments is that we try our best to stay away from tricks, hacks, shortcuts and all that kind of garbage because they are no way out roads, you go along that line hoping it brings you sometime and suddendly you find out the engine is a mess and you cannot no more progress on that.
If implementation is simple and clear it can be improved further, otherwise you are at the end of the road.
1)Note that in stockfish1.7 you added more lines then the lines that you deleted relative to stockfish1.6 because
I read the following:
58 files changed, 2136 insertions(+), 1901 deletions(-) so it seems that you do not do only changes that removes more lines of code then adding lines of codes.
2)My exeperience with the fail high fail low behaviour is clearly unstable.
In one of my correspondence games I got the following scores(with the same first pv move) and in previous analysis that I did stockfish simply crashed after more than 24 hours of search and I do not know if it is related to fail low fail high problem(in this case I decided to stop stockfish and make it analyze from clear hash after the first move because I suspect that there may be a bug).
I do not give the moves because this games is still not over.
36 08:12 1.531.788.082 3.109.219 -0.64
37- 08:42 1.622.035.970 3.105.456 -0.76
37- 10:12 1.891.115.130 3.087.439 -0.88
37+ 13:21 2.473.535,745 3.085.694 -0.52
37 14:01 2.603.596,766 3.093.676 -0.64
38- 19:00 3.523.314,284 3.090.093 -0.72
38- 23:17 4.320.447,937 3.092.595 -0.80
38- 25:58 4.808.657,047 3.085.470 -0.96
38+ 27:44 5.126.212,642 3.080.585 -0.56
38+ 33:08 6.124.192,272 3.080.214 -0.48
38 35:43 6.592.299,159 3.075.585 -0.76
39- 41:54 7.724.662,632 3.071.714 -0.88
39- 44:57 8.271.452,842 3.066.131 -1.01
39+ 49:13 9.025.704,344 3.056.351 -0.64
39+ 51:36 9.472.362,932 3.059.438 -0.52
39- 59:40 10.973.719,229 3.064.694 -1.25
39+ 1:17:41 14.236.335,495 3.054.021 -0.28
3)thinking about what you can change without adding more lines
I have no good idea but I think that maybe it is better to use
researchCountFH and researchCountFL in the size of the aspiration window
In the relevant case the score at depth 36 and at depth 37 is the same
but depth 37 had fail low and fail high.
I suggest that you may try to define
researchCountFH and researchCountFL as global variable like aspiration_delta when you can add to aspiration_delta some number like
1<<(researchCountFL+researchCountFH)
It seems to be slightly more code but not by much.