The CQL file staircase-sort-annotated.cql searches for queen staircases with at least 8 queen moves in it. It sorts the result by the number of moves in the staircase. A queen staircase happens when a queen moves in a zigzag pattern like a staircase, as illustrated by the arrows in the following diagram:
Aliev/Shukurov 2008, after 2...Kg1
(found from CQL file: staircase-sort.cql)

In that diagram, the white queen moves from a8 to a7 to b7 to c6 and so on up to f2.

We could easily find this particular study by searching for the exact path:


But this approach has some limitations. It only matches that exact queen path for one. We could put a in front of the to allow the path to go in any direction, but this would miss shorter paths. We could allow shorter paths by putting a shift in front of the and only listing a few moves of the queen path, but then we could not sort the result by length of the path (although for a simple way to find queen staircases, that is not a bad method). The method we actually use is much shorter and much more general.

We will use the directional filters. A directional filter applied to a set of squares gives a new set of squares formed by moving each square in the specified direction. When a number follows the directional filter, the original squares are moved the specified number of squares.

For example, up 1 e4 is the square e5. Similarly right 1 e4 is the square f4.

Recall that is a piece designator denoting the squares on which there is a . Therefore, if a position has single that is on e4, then up 1 is the square e5.

With that introduction, let's go through the CQL file.

staircase-sort-annotated.cql line by line

Let's skip over the and the sort lines and begin with the main :
     "queen staircase" verbose nestban piecepath
The introduces a series of moves, just like in explain-rookleapcorners.cql. The indicates that only moves by the are considered.

Technically, as we see later, this logic could yield some extra false positives if there are two white queens on the board. However, it's usually better in CQL to allow a few theoretical false positives if it simplifies the code. If it were important, one could use variables like in explain-rookleapcorners.cql, but that would require an extra line of CQL code and be slightly harder to read.

The title "queen staircase" just adds a queen staircase annotation to the output file, as can be seen by clicking through the sample output in staircase-sort-annotated.cql. The verbose annotates each individual move of the resulting path and is rarely needed in practice.

The nestban parameter is another option that cleans up the comments in the output PGN file. nestban makes sure that only the comments to the longest path are included. Suppose we find a 12-move queen staircase starting at move 10. Then there is likely as well an 11-move staircase starting at move 11 and so on. Both of these staircases fulfill the requirements and comments for both would be output by default. The nestban disregards staircases that are themselves included in larger staircases.

Finally, the piecepath outputs the actual path taken by the in one compact form to the PGN file. This is helpful for reading and tracing the paths taken by pieces in some themes like this one.

Recall that up 1 is the square above the location of the in the current position.

――up 1 
would match a move by any piece to the square above the square. Because the up 1 is the immediate right of the ――. In this context, that denotes the destination of the move. For example, if the were on e4, then it would mean
Our ――, however, is not a free-standing ―― filter. It is a ―― constituent, controlled by its containing . Thus, only moves by the itself are considered. If the is on e4 in the current position, our ―― constituent means

In other words, it matches a move one square upwards by the .

Similarly, ――right 1 matches a move one square to the right by the .

When we enclose these two ――-constituents in parentheses and follow it with the regular expression symbol +, it means that this pair of moves is repeated one or more times. That is,

  (――up 1 
   ――right 1 )+

means that the moves up one move and right one move, repeated one or more times.

We could end our right here, but there might be a single extra upwards move by the afterwards. This will happen when there are an odd number of moves in the staircase. Therefore, we add an optional up move after the sequence of up-right moves:

up 1 ?

The ? means "optional". + and ? might seem unfamiliar to some of our users, but these are symbols very commonly used in string matching.

Note that the automatically takes care of any unthematic moves by pieces other than the . We can concentrate on the logic of the thematic moves in the queen staircase.

So the filter now finds our queen staircase, at least it does when the moves in a repeated up-right pattern. We'd like to limit the output to staircases of at least 8 moves, and also sort the results by the length of the staircase so that the longer staircases come first. That's what the filter just before the does:

8sort "staircase size"
does. The value of the is the number of moves in it--but since we are ignoring moves not by the because of the , it's the number of moves, which is to say the number of moves in the staircase. The sort will sort the games in descending order by this length.

The value of the sort filter itself is the numeric value of its argument, in this the length of moves in the queen staircase beginning at the current position. The 8sort thus limits the output to staircases of at least 8 queen moves.

There is one last thing we haven't done. We've found up-right staircase by the , but what about down-left staircases by the ? Indeed, our diagrammed staircase is a down-right staircase.

The allows any transformation of the argument filter by board rotation and reflection. If we reflect the board about the horizontal bisector, the up in our filter becomes down and the right stays the same. That is why our original diagram position matches. The interchanges the colors, changing the in our to a . (Technically the would also change the up to a down but that doesn't matter inside of a .)


We've gone over how to look for systematic maneuvers of this type by thematic pieces. This can be done as well, in a slightly wordier way, in CQL 6.1. However, that version did not allow moves by unthematic white pieces in between the thematic queen moves. By using , the result is much more concise and clearer than it would have been in CQL 6.1, which would have required a fairly complex regular expression.