Open and Semi-open files

Code, algorithms, languages, construction...
Post Reply
thevinenator
Posts: 68
Joined: Tue Jun 02, 2015 11:02 pm
Real Name: Vince

Open and Semi-open files

Post by thevinenator » Fri Oct 30, 2015 1:11 am

i was examining my code for Rook O and SO files and had a thought.

all the definitions i can find define an Open file as one without any pawns on the same file as the rook, for example.

say a white Rook is on F3 and there are no pawns in "front" (moving toward black's side), but the rook has the white F2 pawn behind it. why wouldn't it still be consider open? it is the attacking direction that is important, isn't it?

same goes for SO files.
"An Engine's strength flows from the Search. But beware, pruning, extensions, reductions; the dark side of the Search are they. Once you start down the dark path, it will dominate and consume you, as it has to so many developers before.” -- Yoda

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: Open and Semi-open files

Post by hyatt » Fri Oct 30, 2015 11:15 pm

Depends. It might make it harder to retreat your rook to defend a pawn from the side. It might make it easier to attack the opponent's king. The idea of an open file is nothing more than a pseudo-mobility term for a rook. No pawns = more squares the rook can move to or control. As far as whether a "lifted rook" (which is what you are describing) is good or not depends on the position. In the majority of positions, being on the normally open file is the best place. But if you want to deal with special cases, then you can add a second term for a rook in front of a friendly pawn and attacking the enemy king even if he also has a pawn in front of your rook.

So a general rule vs multiple more specific rules. The latter have a computational cost that the first does not, but the latter provide more accuracy, which the first does not. It's a trade-off.

Post Reply