Moderator: Andres Valverde
Richard Allbert wrote:Hi Roman,
By qs I assume you mean quiescence search?
I had the same setup as you, and simply made a different ordering function for the qs, just using mvvlva / see(), no other scores.
Regards
Richard
Roman Hartmann wrote:Hi,
for move ordering and also for evaluation my engine relies on piece-square tables. There is a table for every piece. Depending on the game stage they are different for certain pieces (pawn, king). As I improved my qs lately which is much more accurate now, I'm in the process of adjusting these values to avoid big jumps of the evaluation related to these tables.
Is there any simple rule like -the positional value of a bishop shouldn't exceed 20 cp- or something similar? I'm only talking about the positional value of a certain piece on a certain square without any search or an SEE involved, of course.
Actually I think there are at least three problems related to using piece-square tables:
-they have to be in balance with each other
-the positional value should not exceed a certain value
-the values in each of the table have to be 'smooth' or they will break the search (I suspect that this is the main problem that LMR doesn't work at all for me)
Maybe someone who is using piece square tables would like to give his opinion/comment on this?
Best regards
Roman
wBishopTbl[sq] = PopCnt(moves) * 4 + PopCnt(moves2) * 2 + PopCnt(capts) * 8;
if(cenRow == 0) wBishopTbl[sq] -= 10;
if(moves & (D4bit | E4bit | D5bit | E5bit)) wBishopTbl[sq] += 10;
points = evalHistTblg[WB][sq] / evalHistTbln[WB][sq];
wBishopTbl[sq] += points/2;
Michael Sherwin wrote:Roman Hartmann wrote:Hi,
for move ordering and also for evaluation my engine relies on piece-square tables. There is a table for every piece. Depending on the game stage they are different for certain pieces (pawn, king). As I improved my qs lately which is much more accurate now, I'm in the process of adjusting these values to avoid big jumps of the evaluation related to these tables.
Is there any simple rule like -the positional value of a bishop shouldn't exceed 20 cp- or something similar? I'm only talking about the positional value of a certain piece on a certain square without any search or an SEE involved, of course.
Actually I think there are at least three problems related to using piece-square tables:
-they have to be in balance with each other
-the positional value should not exceed a certain value
-the values in each of the table have to be 'smooth' or they will break the search (I suspect that this is the main problem that LMR doesn't work at all for me)
Maybe someone who is using piece square tables would like to give his opinion/comment on this?
Best regards
Roman
RomiChess uses mostly piece square tables for its eval with a little pawn structure code at the leafs. I have tried countless ways to scale and/or limit these values. They all lead to substantially weaker play.
Here is the critical part of the white bishops eval:
- Code: Select all
wBishopTbl[sq] = PopCnt(moves) * 4 + PopCnt(moves2) * 2 + PopCnt(capts) * 8;
if(cenRow == 0) wBishopTbl[sq] -= 10;
if(moves & (D4bit | E4bit | D5bit | E5bit)) wBishopTbl[sq] += 10;
points = evalHistTblg[WB][sq] / evalHistTbln[WB][sq];
wBishopTbl[sq] += points/2;
// note: moves2 are all the squares reachable in two moves
It is amazing to me that RomiChess is as strong as she is with such a naive and simple eval.
Uri Blass wrote:Michael Sherwin wrote:Roman Hartmann wrote:Hi,
for move ordering and also for evaluation my engine relies on piece-square tables. There is a table for every piece. Depending on the game stage they are different for certain pieces (pawn, king). As I improved my qs lately which is much more accurate now, I'm in the process of adjusting these values to avoid big jumps of the evaluation related to these tables.
Is there any simple rule like -the positional value of a bishop shouldn't exceed 20 cp- or something similar? I'm only talking about the positional value of a certain piece on a certain square without any search or an SEE involved, of course.
Actually I think there are at least three problems related to using piece-square tables:
-they have to be in balance with each other
-the positional value should not exceed a certain value
-the values in each of the table have to be 'smooth' or they will break the search (I suspect that this is the main problem that LMR doesn't work at all for me)
Maybe someone who is using piece square tables would like to give his opinion/comment on this?
Best regards
Roman
RomiChess uses mostly piece square tables for its eval with a little pawn structure code at the leafs. I have tried countless ways to scale and/or limit these values. They all lead to substantially weaker play.
Here is the critical part of the white bishops eval:
- Code: Select all
wBishopTbl[sq] = PopCnt(moves) * 4 + PopCnt(moves2) * 2 + PopCnt(capts) * 8;
if(cenRow == 0) wBishopTbl[sq] -= 10;
if(moves & (D4bit | E4bit | D5bit | E5bit)) wBishopTbl[sq] += 10;
points = evalHistTblg[WB][sq] / evalHistTbln[WB][sq];
wBishopTbl[sq] += points/2;
// note: moves2 are all the squares reachable in two moves
It is amazing to me that RomiChess is as strong as she is with such a naive and simple eval.
I think that RomiChess is not so strong.
My opinion is that if you modify Strelka's evaluation to piece square table evaluation you may get a stronger program.
I have a piece square table version of strelka and I found that it is at least stronger than Joker(did not test it against RomiChess)
The piece square version of strelka has not optimized piece square tables
because I did not change the original piece square table values.
Uri
Return to Programming and Technical Discussions
Users browsing this forum: No registered users and 3 guests