Don wrote:
with the possible exception of not reducing null threats - that is an idea I know about but I am not aware of anyone else using it. I don't view this idea as something very interesting, it's an obvious thing to try and it does not work for Komodo. For Komodo it only slows the program down for little ELO gain but it might help other programs.
Yes, the idea is obvious, something I have tried and thrown away myself a number of times. The main issue is that null threats with a window size of 1 between alpha and beta will often miss a lot. If someone came up with a method to detect and use these threats without the kinds of penalties associated with increasing the search window size I would consider it interesting and innovative.
Of course, what I consider innovative might not be an appropriate standard, since I am not as well versed in other people's programs and ideas as many here.
-Sam
Did you read Donninger's paper on null-move? I think the section was something like "The program that knew too much" or something similar. For example, you are searching and you get a fail high at a node. What if you do a null-search on a downward offset window and it still fails low. Doing nothing is therefore really bad, when normally we get lots of null fail highs. So we are in a position that doing nothing hurts badly, and we have a move that just failed high. Wonder if that move is the _only_ move that is holding off some threat of the opponent? So you extend and re-search and see if this move still fails high. If so, return beta and you are done. If not, you don't trust the fail high.
It does some interesting things, and will return some longish PVs at times, but it was never clear to me that it was worth the overhead of that offset null-move search on each fail high...
I saved the code and am going to play with it one of these days now that cluster testing can accurately show the effect of such ideas.
My unqualified opinion is that some of the magic comes from a "Good worse case behavior" (like Romstad elaborated on some time ago) evaluation coupled with intelligent extensions.
Don wrote:
with the possible exception of not reducing null threats - that is an idea I know about but I am not aware of anyone else using it. I don't view this idea as something very interesting, it's an obvious thing to try and it does not work for Komodo. For Komodo it only slows the program down for little ELO gain but it might help other programs.
Yes, the idea is obvious, something I have tried and thrown away myself a number of times. The main issue is that null threats with a window size of 1 between alpha and beta will often miss a lot. If someone came up with a method to detect and use these threats without the kinds of penalties associated with increasing the search window size I would consider it interesting and innovative.
Of course, what I consider innovative might not be an appropriate standard, since I am not as well versed in other people's programs and ideas as many here.
-Sam
Did you read Donninger's paper on null-move? I think the section was something like "The program that knew too much" or something similar. For example, you are searching and you get a fail high at a node. What if you do a null-search on a downward offset window and it still fails low. Doing nothing is therefore really bad, when normally we get lots of null fail highs. So we are in a position that doing nothing hurts badly, and we have a move that just failed high. Wonder if that move is the _only_ move that is holding off some threat of the opponent? So you extend and re-search and see if this move still fails high. If so, return beta and you are done. If not, you don't trust the fail high.
It does some interesting things, and will return some longish PVs at times, but it was never clear to me that it was worth the overhead of that offset null-move search on each fail high...
I saved the code and am going to play with it one of these days now that cluster testing can accurately show the effect of such ideas.
If I have, it has not been for a long time and I have forgotten about it. If someone runs across a copy I would love a link to it.
Don wrote:
with the possible exception of not reducing null threats - that is an idea I know about but I am not aware of anyone else using it. I don't view this idea as something very interesting, it's an obvious thing to try and it does not work for Komodo. For Komodo it only slows the program down for little ELO gain but it might help other programs.
Yes, the idea is obvious, something I have tried and thrown away myself a number of times. The main issue is that null threats with a window size of 1 between alpha and beta will often miss a lot. If someone came up with a method to detect and use these threats without the kinds of penalties associated with increasing the search window size I would consider it interesting and innovative.
Of course, what I consider innovative might not be an appropriate standard, since I am not as well versed in other people's programs and ideas as many here.
-Sam
Did you read Donninger's paper on null-move? I think the section was something like "The program that knew too much" or something similar. For example, you are searching and you get a fail high at a node. What if you do a null-search on a downward offset window and it still fails low. Doing nothing is therefore really bad, when normally we get lots of null fail highs. So we are in a position that doing nothing hurts badly, and we have a move that just failed high. Wonder if that move is the _only_ move that is holding off some threat of the opponent? So you extend and re-search and see if this move still fails high. If so, return beta and you are done. If not, you don't trust the fail high.
It does some interesting things, and will return some longish PVs at times, but it was never clear to me that it was worth the overhead of that offset null-move search on each fail high...
I saved the code and am going to play with it one of these days now that cluster testing can accurately show the effect of such ideas.
If I have, it has not been for a long time and I have forgotten about it. If someone runs across a copy I would love a link to it.
-Sam
I think it was 1992-ish, JICCA (prior to ICGA)...
Bob
I will try to find a reference, although I am unaware of an electronic version.
yes, it was 1992 or 1993-ish. Not seen an electronic version of the paper.
If I remember right, this was "the" null move paper, which demonstrated the famous recursive null move idea. The threat extension bit was interesting (most of us played around with it in the 1990's), but seemed too expensive in real games.
I still have this extension (but commented out) in my source. Will give it another whirl, as hardware is, oh, probably 100 times faster than when I last tried it
Gian-Carlo Pascutto wrote:You mean something like: "We use ideas debuted in Rybka 3 and obtained through reverse engineering"?
No, people should give credit for what they effectively used.
I give credit to Ippolit, Stockfish and Crafty because these engines are what I studied. How and why these source codes have been constructed is beyond my knowledge, your guess is as good as mine.
Robert
Lame and evasive answer as always. "Beyond my knowledge" ..Really?
However, I do not want this thread to become a general mess so I am asking that the sniping and side issues stop.
I asked that trigger words not be responded to (I was hoping that the contributers would be mature enough to know that meant that I did not want them used either) nor flaming etc. start.
This is not the place.
I really am not into editing as that is way too distasteful but deleting, no problem.
Keep it technical and let us move on.
Please!
Later.
Sorry I took a verbal swipe at the Houdini guy but his evasiveness is rather grating.
