zamar wrote:
My hypothesis why this could not be working in Stockfish is that we already have the "super-quiescence"-approach (often called history pruning). Basically we are throwing moves out of the window already at depth == 6.
They throw out even more !
I am still working on the details, but it seems that below a certain depth they try only sliding pieces moves and forget about the pawns !
I can see a little sense to that. Every last pawn move is bad. Because once moved, it can not retreat. Sometimes we need to control a square and are willing to move a pawn to do so, knowing the weaknesses it incurs. Cutting those off near the frontier might be an idea. Unfortunately there are not nearly as many pawn moves are there are piece moves. But if you include knights (particularly leaving centralized knights centralized) it might make sense. I tried some reduction ideas based exactly on this idea but nothing I tried even broke even. For example, retreating a knight on e5 is usually poor. Retreating it to the opposite of the board as well is usually worse. But I never found any rules that worked. For reduction decisions, I used a large switch() to switch on the piece type, and tried different rules for different pieces. But could not make any headway. Even after spending a couple of months on it. It was all essentially work that was thrown out as not good. Hated to do so, but when the cluster testing says "this sucks" I listen.
One thing that seems to be working for me is LMR reduction of two plies for moves where the piece moves to a square attacked by the other side but not defended. But I do a full eval at every node so I have that information on hand already.
bob wrote:
if 2=> one ply, the above is not quite as speculative-looking. Is this indexed by remaining depth? Moves searched at a ply? However, 7 (3.5) is not that big a value. I've experimented with an increasing reduction as more and more moves fail to produce a cutoff, but have yet to find anything that improves the basic algorithm I have been using for several years now. At least so far.
- Indexed by Moves searched at a ply
- 3.5 ply reduction is not a big value ????????
LMR has a recursive behaviour for the moves near the list end, even if reduction is only one ply and we are let's say at depth 12, when we reach depth 5 the late moves of the lates moves of the lates moves ... will be reduced by 7 ply already because at each next ply you add one ply of reduction to late moves.
So reducing 3.5 for a _single_ ply is a _tremendous_ reduction IMHO.
In Twisted Logic I'm already doing reductions of 2 ply in LMR since the 20080404 versions and lower. This is what compensates for not using history based reduction and pruning stuff. I have played with the above idea a couple of weeks before but I just didn't have the time to test it thoroughly. This is before I have seen Ippolit source code ( I've only known and seen it the last few days). All the Speculation stuff in TL's UCI parameters is related to LMR.
I think my approach in developing TL the last few months is following the Rybka way without me being aware of it, it's a bad thing this Ippolit thing comes out. Now almost everyone could just benefit from someone else hard work (Vas has once said that he spent hundreds of hours thinking about the search >> I am not sure if I remembered it correctly. Now others could just adapt the idea without spending an hour of thinking time at all. Oh well.).
I would have preferred the challenge of discovering things by myself. Now that this thing is out I'm a little bit discouraged. Anyway, there's nothing we could do about that. I just hope Vas would come up with a much stronger version than this Ippolit.
About the recursive LMR in Ippolit, I think it wouldn't reduce by 7 plies. Remember that it doesn't call the same function in the recursive search. Meaning it might reduce by 3.5 (cut node) then 0.5 (all node) then tactical search with out reductions (qsearch).
bob wrote:
if 2=> one ply, the above is not quite as speculative-looking. Is this indexed by remaining depth? Moves searched at a ply? However, 7 (3.5) is not that big a value. I've experimented with an increasing reduction as more and more moves fail to produce a cutoff, but have yet to find anything that improves the basic algorithm I have been using for several years now. At least so far.
- Indexed by Moves searched at a ply
- 3.5 ply reduction is not a big value ????????
LMR has a recursive behaviour for the moves near the list end, even if reduction is only one ply and we are let's say at depth 12, when we reach depth 5 the late moves of the lates moves of the lates moves ... will be reduced by 7 ply already because at each next ply you add one ply of reduction to late moves.
So reducing 3.5 for a _single_ ply is a _tremendous_ reduction IMHO.
In Twisted Logic I'm already doing reductions of 2 ply in LMR since the 20080404 versions and lower. This is what compensates for not using history based reduction and pruning stuff. I have played with the above idea a couple of weeks before but I just didn't have the time to test it thoroughly. This is before I have seen Ippolit source code ( I've only known and seen it the last few days). All the Speculation stuff in TL's UCI parameters is related to LMR.
I think my approach in developing TL the last few months is following the Rybka way without me being aware of it, it's a bad thing this Ippolit thing comes out. Now almost everyone could just benefit from someone else hard work (Vas has once said that he spent hundreds of hours thinking about the search >> I am not sure if I remembered it correctly. Now others could just adapt the idea without spending an hour of thinking time at all. Oh well.).
I would have preferred the challenge of discovering things by myself. Now that this thing is out I'm a little bit discouraged. Anyway, there's nothing we could do about that. I just hope Vas would come up with a much stronger version than this Ippolit.
About the recursive LMR in Ippolit, I think it wouldn't reduce by 7 plies. Remember that it doesn't call the same function in the recursive search. Meaning it might reduce by 3.5 (cut node) then 0.5 (all node) then tactical search with out reductions (qsearch).
I don't like the clone / copying issues, but I am not that concerned about Vas' claim of spending hundreds of hours thinking about the search. How many thousands of hours do you think went into the stuff he took for granted and for free himself? Hashing? Alpha/Beta? reductions? extensions? Evaluation? Bitboards? I don't consider _that_ a reason to dislike what is being done with ippolit.
This used to not be possible because everyone was open with new ideas. I looked at the code very briefly when I first heard about it back in June. I was more interested in using it as an opponent in my cluster testing, but it was buggy enough that was not feasible. I was unwilling to spend the time necessary to read the rather pidgeon-like variable names and such to figure out what it was doing. And still am not...
bob wrote:I was more interested in using it as an opponent in my cluster testing, but it was buggy enough that was not feasible. I was unwilling to spend the time necessary to read the rather pidgeon-like variable names and such to figure out what it was doing. And still am not...
bob wrote:I was more interested in using it as an opponent in my cluster testing, but it was buggy enough that was not feasible. I was unwilling to spend the time necessary to read the rather pidgeon-like variable names and such to figure out what it was doing. And still am not...
What was wrong with using Strelka?
Did not try strelka, was really looking for something to fill in at the top of my list of opponents... I did not even notice if Strelka had a linux option or not, to be honest...
bob wrote:I was more interested in using it as an opponent in my cluster testing, but it was buggy enough that was not feasible. I was unwilling to spend the time necessary to read the rather pidgeon-like variable names and such to figure out what it was doing. And still am not...
What was wrong with using Strelka?
Did not try strelka, was really looking for something to fill in at the top of my list of opponents... I did not even notice if Strelka had a linux option or not, to be honest...
It works fine in Linux. The source might need a hack or two but it was trivial to get working IIRC.
This is all relative since a long time. Crafty source, then came Fruit source, anyone can look if they want. Also you are said how to build a hashtable etc. nothing changes. When things like this some may feel discouraged, at least some programmers. We can also change from field, you like Go too? or maybe forget this tiny little games thing and investigate natural language processing or more real AI, most people care or will care about that.
Edsel Apostol wrote:
mcostalba wrote:
bob wrote:
if 2=> one ply, the above is not quite as speculative-looking. Is this indexed by remaining depth? Moves searched at a ply? However, 7 (3.5) is not that big a value. I've experimented with an increasing reduction as more and more moves fail to produce a cutoff, but have yet to find anything that improves the basic algorithm I have been using for several years now. At least so far.
- Indexed by Moves searched at a ply
- 3.5 ply reduction is not a big value ????????
LMR has a recursive behaviour for the moves near the list end, even if reduction is only one ply and we are let's say at depth 12, when we reach depth 5 the late moves of the lates moves of the lates moves ... will be reduced by 7 ply already because at each next ply you add one ply of reduction to late moves.
So reducing 3.5 for a _single_ ply is a _tremendous_ reduction IMHO.
In Twisted Logic I'm already doing reductions of 2 ply in LMR since the 20080404 versions and lower. This is what compensates for not using history based reduction and pruning stuff. I have played with the above idea a couple of weeks before but I just didn't have the time to test it thoroughly. This is before I have seen Ippolit source code ( I've only known and seen it the last few days). All the Speculation stuff in TL's UCI parameters is related to LMR.
I think my approach in developing TL the last few months is following the Rybka way without me being aware of it, it's a bad thing this Ippolit thing comes out. Now almost everyone could just benefit from someone else hard work (Vas has once said that he spent hundreds of hours thinking about the search >> I am not sure if I remembered it correctly. Now others could just adapt the idea without spending an hour of thinking time at all. Oh well.).
I would have preferred the challenge of discovering things by myself. Now that this thing is out I'm a little bit discouraged. Anyway, there's nothing we could do about that. I just hope Vas would come up with a much stronger version than this Ippolit.
About the recursive LMR in Ippolit, I think it wouldn't reduce by 7 plies. Remember that it doesn't call the same function in the recursive search. Meaning it might reduce by 3.5 (cut node) then 0.5 (all node) then tactical search with out reductions (qsearch).
