Calculating space

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
zd3nik
Posts: 193
Joined: Wed Mar 11, 2015 2:34 am
Location: United States
Contact:

Calculating space

Post by zd3nik » Sun Aug 07, 2016 5:56 pm

I tried searching for existing topics on this, but the terms I could think of to search on are apparently too general so I didn't find any topics on this specific idea.

I currently calculate space by looking at squares behind connected pawns. Of those squares I count the number of vertically contiguous squares controlled by the side in question (e.g. white control if looking at squares behind connected white pawns).

This seems to work pretty well, but I've never done a thorough investigation to verify it's effect. And I'm in a situation where I no longer have room in my pawn transposition table entries to store connected pawn maps. So I'm trying to decide whether it's worth finding a way to preserve this metric in my static positional evaluation.

So I'm wondering:

1. how others do space calculation?
2. is the metric actually useful/beneficial to calculate?
3. is it only necessary to consider space in certain situations?

If anyone has any experience in this area I'd appreciate it if you share your thoughts.

Thanks,
Z

ZirconiumX
Posts: 1327
Joined: Sun Jul 17, 2011 9:14 am

Re: Calculating space

Post by ZirconiumX » Sun Aug 07, 2016 7:33 pm

zd3nik wrote:1. how others do space calculation?
I don't use space, but your "area behind connected pawns" idea seems solid. What do you do in the case of pawn islands, though?
2. is the metric actually useful/beneficial to calculate?
If you could do it quickly, it might help the engine in closed games. The numbers will speak for themselves though.
3. is it only necessary to consider space in certain situations?
It would probably be pointless to consider it in a pawnless endgame, for example. I don't know the data structures you have, but perhaps you could ignore it when there are 3 pawn islands or more?

I'm not Lyudmil though.
Some believe in the almighty dollar.

I believe in the almighty printf statement.

User avatar
Kempelen
Posts: 620
Joined: Fri Feb 08, 2008 9:44 am
Location: Madrid - Spain
Contact:

Re: Calculating space

Post by Kempelen » Sun Aug 07, 2016 7:36 pm

I dont use space, but I think I am indirectly doing it, because if you value PST advanced pieces, you will making your engine to try to gain space.... I think this works quite well with pawn pst
Fermin Serrano
Author of 'Rodin' engine
http://sites.google.com/site/clonfsp/

Ferdy
Posts: 4111
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Calculating space

Post by Ferdy » Mon Aug 08, 2016 4:55 am

zd3nik wrote:I tried searching for existing topics on this, but the terms I could think of to search on are apparently too general so I didn't find any topics on this specific idea.

I currently calculate space by looking at squares behind connected pawns. Of those squares I count the number of vertically contiguous squares controlled by the side in question (e.g. white control if looking at squares behind connected white pawns).

This seems to work pretty well, but I've never done a thorough investigation to verify it's effect. And I'm in a situation where I no longer have room in my pawn transposition table entries to store connected pawn maps. So I'm trying to decide whether it's worth finding a way to preserve this metric in my static positional evaluation.

So I'm wondering:

1. how others do space calculation?
2. is the metric actually useful/beneficial to calculate?
3. is it only necessary to consider space in certain situations?

If anyone has any experience in this area I'd appreciate it if you share your thoughts.

Thanks,
Z
It is a safe square that your pieces (not pawns and not king) can go from rank 3 to rank 5 for white and rank 6 to rank 4 for black.
The bonus is only given when there is at least one space in queen-side and at least one space in king-side.
From the image below, black may have a space but it would not get a bonus because there are no space on its king-side.
The queen-side is from file a to file d, the king-side is from file e to file h.

Image

PK
Posts: 824
Joined: Mon Jan 15, 2007 10:23 am
Location: Warsza
Contact:

Re: Calculating space

Post by PK » Mon Aug 08, 2016 3:18 pm

Stockfish depends space as "squares on 3rd to 5th rank, behind pawns, edge files excluded, not attacked by enemy pawns and attacked by our pieces". Toga II 3.0 gives a non-linear bonus for pieces on enemy half of the board (the more the better). Neither approach worked for me, but it probably varies from engine to engine. Anyhow, space eval seems just a correction to whatever piece/square tables and mobility do wrong.

D Sceviour
Posts: 458
Joined: Mon Jul 20, 2015 3:06 pm
Contact:

Re: Calculating space

Post by D Sceviour » Tue Aug 09, 2016 12:05 am

PK wrote:Toga II 3.0 gives a non-linear bonus for pieces on enemy half of the board (the more the better).
I have using an approach similar to the Toga approach mentioned for some time. If I take it out, then the program plays weaker. This is an indication that "space" value is primary and crucial to the total evaluation. That is, space is one of the four corner stones of chess being: material, space, time and pawn structure. You cannot simply adjust a space value. I think space has to be considered first and then other values adjusted around it. Of course, this is only my conclusion but it seems to be supported by a number of chess authors. Still, if I am wrong then tell me how to remove a space calculation without damaging the search.

Post Reply