Uri Blass wrote:I can explain the reason for my confidence that my theory is right and not because of hard max ply limit and not only because of zugzwang.
Let think about an extreme case.
You think too much about extreme cases. Considering extreme cases can be useful to determine the limits of general rules, but they are not good at all for showing that a theory is right.
Suppose that we have hardware that is strong enough to search to depth 1000.
1. We don't.
2. If we get 1000 plies deep with selectivity, we maybe get 30 plies deep without.
3. If we get 1000 plies deep without selectivity, we can search till the end of the game. Obviously there is then no need to get deeper by selectivity.
The whole assumption is ill-defined and completely irrealistic.
You CANNOT reason about 1000 plies and then conclude something about the real world today.
Uri Blass wrote:I did not find positions from practical games when the maximal number of recursions was bigger than 100 but I found a case when it was 86 after some minutes.
So there you go, 100 plies is enough. And it has now been increased to 120 plies.
Positions where it reaches 86 ply most likely are endgames that the search manages to completely solve using its hashtable. Searching deeper wouldn't help. (But there are probably cases where the solution is incorrect due to nullmove problems.)
Uri Blass wrote:I can explain the reason for my confidence that my theory is right and not because of hard max ply limit and not only because of zugzwang.
Let think about an extreme case.
You think too much about extreme cases. Considering extreme cases can be useful to determine the limits of general rules, but they are not good at all for showing that a theory is right.
Suppose that we have hardware that is strong enough to search to depth 1000.
1. We don't.
2. If we get 1000 plies deep with selectivity, we maybe get 30 plies deep without.
3. If we get 1000 plies deep without selectivity, we can search till the end of the game. Obviously there is then no need to get deeper by selectivity.
The whole assumption is ill-defined and completely irrealistic.
You CANNOT reason about 1000 plies and then conclude something about the real world today.
I found that the branching factor of stockfish is still small if I disable null move pruning at high depths(depth>20) because of late move reductions so it is not 30 instead of 1000 but maybe 900 instead of 1000 and I think even more than 900 and I feel that I prefer 900 plies without null move pruning and not 1000 plies with null move pruning.
Late move reduction can reduce some plies in every move but they never reduce so much so the program will certainly see everything 32 plies forward even at depth 500 and probably also at depth 100.
Again, it makes no sense whatsoever to reason based on such far out scenarios.
If you mean you prefer 27 plies selective search without nullmove over 30 plies selective search with nullmove, you can quite easily locally test whether nullmove really only adds 3 plies and you can quite easily locally test whether disabling nullmove hurts Elo.
Of course, also if you test locally you should be ready to accept that your ideas may just be completely wrong and not just reason any counterevidence away using strange examples and arguments. Be objective.
syzygy wrote:Again, it makes no sense whatsoever to reason based on such far out scenarios.
If you mean you prefer 27 plies selective search without nullmove over 30 plies selective search with nullmove, you can quite easily locally test whether nullmove really only adds 3 plies and you can quite easily locally test whether disabling nullmove hurts Elo.
Of course, also if you test locally you should be ready to accept that your ideas may just be completely wrong and not just reason any counterevidence away using strange examples and arguments. Be objective.
I did not compare 27 and 30 but 900 with 1000
When I use null move pruning with depth bigger than 20 I do not get 27 instead of 30 and get something that is clearly bigger at the same time.
syzygy wrote:Again, it makes no sense whatsoever to reason based on such far out scenarios.
If you mean you prefer 27 plies selective search without nullmove over 30 plies selective search with nullmove, you can quite easily locally test whether nullmove really only adds 3 plies and you can quite easily locally test whether disabling nullmove hurts Elo.
Of course, also if you test locally you should be ready to accept that your ideas may just be completely wrong and not just reason any counterevidence away using strange examples and arguments. Be objective.
I did not compare 27 and 30 but 900 with 1000
When I use null move pruning with depth bigger than 20 I do not get 27 instead of 30 and get something that is clearly bigger at the same time.
Wat sense does it make to talk about 900 and 1000 plies. Have you asked yourself?
syzygy wrote:Again, it makes no sense whatsoever to reason based on such far out scenarios.
If you mean you prefer 27 plies selective search without nullmove over 30 plies selective search with nullmove, you can quite easily locally test whether nullmove really only adds 3 plies and you can quite easily locally test whether disabling nullmove hurts Elo.
Of course, also if you test locally you should be ready to accept that your ideas may just be completely wrong and not just reason any counterevidence away using strange examples and arguments. Be objective.
I did not compare 27 and 30 but 900 with 1000
When I use null move pruning with depth bigger than 20 I do not get 27 instead of 30 and get something that is clearly bigger at the same time.
Wat sense does it make to talk about 900 and 1000 plies. Have you asked yourself?
To explain why I think that in theory my idea is going to work at time control that is long enough.
I do not claim to know if the time control that we use today is long enough.
I ran bench for stockfish with and with out null move pruning with default
and here are the results so far
the first n that bench(n without null)>bench(n+1 with null)
is n=14
The first n that bench(n without null)>bench(n+2 with null) is at least 20
I don't see you explain anything. You jump from 900 ply versus 1000 ply reasoning to benchmark searches of trivial depth.
You list numbers without explaining what they mean. I can't read minds.
Anyway, assuming you have indeed left the fantasy world of 900 / 1000 ply searches, why don't you run a match at not too short time control on your own machine, SF with nullmove versus SF without nullmove? SF without nullmove should lose by a considerable margin, so it doesn't have to be a match with too many games.
syzygy wrote:Again, it makes no sense whatsoever to reason based on such far out scenarios.
If you mean you prefer 27 plies selective search without nullmove over 30 plies selective search with nullmove, you can quite easily locally test whether nullmove really only adds 3 plies and you can quite easily locally test whether disabling nullmove hurts Elo.
Of course, also if you test locally you should be ready to accept that your ideas may just be completely wrong and not just reason any counterevidence away using strange examples and arguments. Be objective.
I did not compare 27 and 30 but 900 with 1000
When I use null move pruning with depth bigger than 20 I do not get 27 instead of 30 and get something that is clearly bigger at the same time.
Wat sense does it make to talk about 900 and 1000 plies. Have you asked yourself?
To explain why I think that in theory my idea is going to work at time control that is long enough.
I do not claim to know if the time control that we use today is long enough.
I ran bench for stockfish with and with out null move pruning with default
and here are the results so far
the first n that bench(n without null)>bench(n+1 with null)
is n=14
The first n that bench(n without null)>bench(n+2 with null) is
n=20
explanation of my numbers:
first number is bench with null move pruning
second number in the last lines is nodes per second.
next number in every line is bench without null move pruning.
4th number in the last lines is again nodes per second when you have it.
I added some additional numbers in the post.
Last edited by Uri Blass on Sun Feb 16, 2014 8:26 pm, edited 2 times in total.
syzygy wrote:I don't see you explain anything. You jump from 900 ply versus 1000 ply reasoning to benchmark searches of trivial depth.
You list numbers without explaining what they mean. I can't read minds.
Anyway, assuming you have indeed left the fantasy world of 900 / 1000 ply searches, why don't you run a match at not too short time control on your own machine, SF with nullmove versus SF without nullmove? SF without nullmove should lose by a considerable margin, so it doesn't have to be a match with too many games.
It is not going to help because I do not think that avoiding null move pruning is good at the time control that we use now but only that avoiding null move pruning at high depth may be good at the time control that we can use now(not claim to be sure about it) and I prefer to use my machine for other tasks then making games.
calculating bench in my machine seems to me more interesting
because I can get some estimate for a formula to see how many plies we lose by not doing null move pruning at different depths based on it.