LMR other conditions

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
bob
Posts: 20369
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: LMR other conditions

Post by bob » Mon Jul 23, 2007 10:02 pm

frankp wrote:I still find the history table reduces the tree size for a fixed endpoint - but maybe random numbers would......
Read Don Beal's paper about random evaluation. It produced surprising results that actually make sense when you think about how random evaluations favor positions with more mobility.

But there has to be a better way...

Michael Sherwin
Posts: 3021
Joined: Fri May 26, 2006 1:00 am
Location: WY, USA
Full name: Michael Sherwin

Re: LMR other conditions

Post by Michael Sherwin » Tue Jul 24, 2007 3:13 am

You make a very good point. In a 2B node 18 ply search after 6 to 9 moves by each side all the moves the history tables say are good, may be bad and visa versa. The history tables may do more harm than good in that instance.

Then what about a table for every 4 ply? That means 5 tables for a 20 ply search. When the search reaches the 5th ply, it zeros out the second table and all 5th to 8th ply moves update that table. Same when the 9th ply is reached except that the 3rd table is zeroed, etc. Two moves by each side would seem to change the average situation very little and the history info would tend to be much more accurate. Or would it?
I hate if statements. Pawns demand if statements. Therefore I hate pawns.

bob
Posts: 20369
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: LMR other conditions

Post by bob » Tue Jul 24, 2007 5:16 am

Michael Sherwin wrote:You make a very good point. In a 2B node 18 ply search after 6 to 9 moves by each side all the moves the history tables say are good, may be bad and visa versa. The history tables may do more harm than good in that instance.

Then what about a table for every 4 ply? That means 5 tables for a 20 ply search. When the search reaches the 5th ply, it zeros out the second table and all 5th to 8th ply moves update that table. Same when the 9th ply is reached except that the 3rd table is zeroed, etc. Two moves by each side would seem to change the average situation very little and the history info would tend to be much more accurate. Or would it?
I don't have an answer to that, I've never tried multiple tables beyond one for black and one for white. The question is, is "4" the right number, or is there something that would be better?

It's an interesting question, but not one I am going to tackle anytime soon, I have more than enough other problems to look at. :)

Michael Sherwin
Posts: 3021
Joined: Fri May 26, 2006 1:00 am
Location: WY, USA
Full name: Michael Sherwin

Re: LMR other conditions

Post by Michael Sherwin » Tue Jul 24, 2007 5:48 am

I have already started the experiment! I have ripped out all history table stuff and created ten new history tables. To conserve memory and to have it compatible with what I do with the eval function, I have made them [fig][ts] ([12][64]) only. Sofar, there is a 6% drop in node rate if the search ends on an iteration that is evenly divisible by 4. That is due to zeroing the table at the last ply of normal search. Despite this drop in speed it is finishing the search sooner! I will post some results when I know more.
I hate if statements. Pawns demand if statements. Therefore I hate pawns.

Michael Sherwin
Posts: 3021
Joined: Fri May 26, 2006 1:00 am
Location: WY, USA
Full name: Michael Sherwin

Re: LMR other conditions

Post by Michael Sherwin » Tue Jul 24, 2007 7:35 am

Michael Sherwin wrote:I have already started the experiment! I have ripped out all history table stuff and created ten new history tables. To conserve memory and to have it compatible with what I do with the eval function, I have made them [fig][ts] ([12][64]) only. Sofar, there is a 6% drop in node rate if the search ends on an iteration that is evenly divisible by 4. That is due to zeroing the table at the last ply of normal search. Despite this drop in speed it is finishing the search sooner! I will post some results when I know more.
Well, I know enough now. IMO, any history table that is not comprised of [fig][fs][ts] ([12][64][64]) is not as good for move ordering or LMR. I would even venture to say that they just are not good, period. I get far superior results with the more specific tables. Unfortunately, the larger tables are just to expensive to zero out, during the search.

The only idea left (that I have) is to record into the tables only shallow ply info of about 8 ply or less, and hope ...
I hate if statements. Pawns demand if statements. Therefore I hate pawns.

frankp
Posts: 216
Joined: Sun Mar 12, 2006 2:11 pm

Re: LMR other conditions

Post by frankp » Tue Jul 24, 2007 9:55 am

bob wrote:
frankp wrote:I still find the history table reduces the tree size for a fixed endpoint - but maybe random numbers would......
Read Don Beal's paper about random evaluation. It produced surprising results that actually make sense when you think about how random evaluations favor positions with more mobility.

But there has to be a better way...
Failed to find this unfortunately, although it is referenced many times on the net. I would guess that maximising the number of moves (mobility) would increases your chances up to a point.

bob
Posts: 20369
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: LMR other conditions

Post by bob » Tue Jul 24, 2007 3:31 pm

frankp wrote:
bob wrote:
frankp wrote:I still find the history table reduces the tree size for a fixed endpoint - but maybe random numbers would......
Read Don Beal's paper about random evaluation. It produced surprising results that actually make sense when you think about how random evaluations favor positions with more mobility.

But there has to be a better way...
Failed to find this unfortunately, although it is referenced many times on the net. I would guess that maximising the number of moves (mobility) would increases your chances up to a point.
That was it. A position where _you_ have more mobility gives you the opportunity to generate more random numbers, and grab a larger one. Reduced mobility positions gives you fewer opportunities to generate a larger value...

It was amazing when I first saw it, but then it began to make some sense, in a twisted way...

frankp
Posts: 216
Joined: Sun Mar 12, 2006 2:11 pm

Re: LMR other conditions

Post by frankp » Tue Jul 24, 2007 9:38 pm

bob wrote:
frankp wrote:
bob wrote:
frankp wrote:I still find the history table r

That was it. A position where _you_ have more mobility gives you the opportunity to generate more random numbers, and grab a larger one. Reduced mobility positions gives you fewer opportunities to generate a larger value...

It was amazing when I first saw it, but then it began to make some sense, in a twisted way...
Reminds me of Bruce's searchlight analogy - for fast dumb searchers: the bigger angle you can sweep the searchlight through, the more chance you have of finding something.

Post Reply