Programs and algorithms for playing the game of chess have been around as long as computers themselves, with the first chess playing program being developed in the 50's by Alan Turing. Computer chess has come a long way since then, and in 1997 IBM's Deep Blue defeated chess grandmaster Garry Kasparov. One thing all these chess programs have in common though is a need to determine when the winning move, or checkmate, is reached. Your goal for this problem is to implement an algorithm such that, given the current layout of the chessboard, it will detect if a checkmate has occurred during that turn.

Chess is played on a board divided into a 8x8 grid of 64 squares. On a real chessboard, the 64 squares have alternating light and dark colors. For this problem the individual square colors are irrelevant and the entire board is simply treated as a uniform 8x8 grid.

The game is played by two opposing sides, white and black, with each side controlling up to six kinds of pieces: a king, queen, rook, bishop, knight, and one or more pawns. For simplicity's sake, however, this problem will only consider the first five and not make any use of the pawn chess piece. The two players take turns moving one piece at a time on every turn. It is up to each player to decide which piece they wish to move on their turn, but it is not possible for a player to "skip" or "pass"; each player must move one of their pieces in some fashion.

Each kind of chess piece moves in a distinct way as explained in the list below, and Figure 1 gives an example using an X to show each square that a chess piece can move to.

• Rook: The rook moves in a straight line by any number of squares in any of the four cardinal (horizontal and vertical) directions.
• Bishop: The bishop moves in a line by any number of squares in any of the four diagonal directions.
• Queen: The queen can move in a line by any number of squares in any of the eight cardinal and diagonal directions. As such, it is considered to be the most powerful piece in the game.
• Knight: The knight always moves by "jumping" two squares in one cardinal direction and one square in a direction perpendicular to the first. There are 8 possible squares that a knight can move to from a given position, and these are shown in the figure below.
• King: The king can move in any of the eight cardinal and diagonal directions but by one square only. Put another way, the king can only move into the eight immediately adjacent squares. As such, this makes the king one of the weakest pieces on the board.

Figure 1: Valid moves for each kind of chess piece

Rook

Bishop

Queen

Knight

King

On every turn, a chess piece may be moved either into a vacant square or into a square already occupied by an opposing piece. In the latter case, the opposing chess piece is said to be

and is permanently removed from the game. However, a chess piece

move into a square already occupied by another friendly piece, because each square can be occupied by at most one piece at a time. Most chess pieces move by "sliding" across vacant squares on the board. In other words, any other chess piece (be it friendly or foe) in the path of the moving piece will block any further movement of that piece. The only exception to this rule is the knight which "jumps" directly to its final destination square, and therefore its movement cannot be blocked by any surrounding pieces between it and the destination square. See

for an example: image (a) shows a white rook's movement blocked by two other pieces, and image (b) shows the same white rook capturing a black bishop (the rook's previous position before the capture is shown as a white outline).

Figure 2: (a) rook's movement blocked by other pieces; (b) rook capturing the black bishop

(a)

(b)

Although the king may be one of the weakest pieces on the board, it is also the most important. A king cannot be captured directly by another piece but it can be threatened. When the king is threatened, or checked, it means that on the next turn, the opposing side would be able to capture the king. Putting a king in check forces the checked side to defend their king by moving the king out of harm's way, blocking the threat with another piece, or capturing the threatening piece. If the checked player has no valid move that they can make to protect the king, then the king is in fact checkmated, and that player has lost the game. Also note that a player may never put their own king in check. Figure 3 shows the difference between a check and checkmate. In image (a), the imminent capture of the white king can still be avoided by either moving the king out of the way or by capturing the black queen. Image (b) shows an example of checkmate, where no valid moves exist for the white side that would eliminate the threat to the king.

Figure 3: Example of white king in (a) check and (b) checkmate

Check

Checkmate

The rules laid out above are the only ones that should be considered for the purposes of this problem. Any other special rules or moves present in a real game of chess, such as castling, are not considered valid in the context of this problem. For the chessboard layout in each data set, you may assume it will contain exactly one white king and exactly one black king, although either side may have any number of rooks, bishops, queens, and knights.

extents

), each of which may be located almost anywhere on the underlying disk. Each extent takes up one or more contiguous

blocks

on the disk, which represent the underlying physical disk structure. Files may not share blocks or extents between themselves, although there may be (and hopefully are) blocks not currently in use on the filesystem.

Despite all of the advances in modern disk technology, this disparate layout still makes for slower access than when all of a file's blocks are in order and adjacent (and therefore occupying a single extent). Because of this, many modern filesystems support defragmentation: the reorganizing of files on the disk so that the blocks of any given file are in order and adjacent.

With RAD's Awesome Dynamic Filesystem (commonly referred to as RADfs), a file can occupy any number of extents, each of which consists of at least two adjacent blocks. The first block in an extent holds metadata about that extent; the rest contain some portion of the file. Consider this simple representation of the extents and blocks occupied by a file:

RADfs.doc: 57-58,102-114,23-47

The file RADfs.doc currently occupies 40 blocks on the disk, even though the file itself is only 37 blocks in size. The smallest on-disk size that it could have is 38 blocks (37 plus a single metadata block), and that can only happen if the entire file is in a single extent. One potential single-extent representation of the file is:

RADfs.doc: 115-152

Here, the single metadata block (115) is followed by the 37 data blocks in a single extent.

The developers of RADfs have also developed the RADical Defragmentation Daemon, or RADDD. RADDD works with a simple two-step algorithm; despite its simplicity, it still manages to significantly reduce the number of extents consumed by files, given enough free space on the disk.

A RADDD pass works as follows:

• First Step ("to the back"):
  • For every file on the filesystem that hasn't been run through this step on this pass, sorted in ascending order by the first block it occupies on the disk:
    • Find the series of adjacent unused blocks nearest the end of the disk that can hold the file plus a single metadata block
    • If such a series exists:
      • Move the file to those blocks
      • Mark the original blocks as unused
    • Else do nothing to the file
• Second Step ("to the front"):
  • For every file on the filesystem that hasn't been run through this step on this pass, sorted in descending order by the last block it occupies on the disk:
    • Find the series of adjacent unused blocks nearest the beginning of the disk that can hold the file plus a single metadata block
    • If such a series exists:
      • Move the file to those blocks
      • Mark the original blocks as unused
    • Else do nothing to the file

After one pass on a filesystem with some free space, some files have hopefully been reduced to a single extent. Multiple passes can often defragment the filesystem even further.

Of course, it's not that simple; some files simply cannot be moved, perhaps due to being in use at the time of the run. These are marked on the filesystem as immobile, and are ignored by RADDD.

Given the size of a disk, the current layout of files on the disk, and a number of passes of RADDD to run, can you determine the final filesystem layout?

(FIR) filters to make these effects happen.

Consider an input stream of samples, represented as a series of integers between 0 and 255 inclusive. (This is, you should not be surprised to discover, the range of an 8-bit sample.) These samples come in a very specific sequence, one after the other, as the digital representation of a given waveform. A FIR mixer will take multiple streams and combine them into one, a FIR echo filter will take one input and provide a single output, and so on.

A FIR filter can be represented as an equation, with the input signals on one side and the output on the other. For example:

   Y = X[0] + X[-5]

represents an echo filter (more specifically, a post-echo filter); a given sample of Y is equal to the value of X at the same location in the input stream, plus the value of the sample that occurred five samples prior in X. Values that are not available (such as X[-5] for the first four samples of X) are set to 0.

In this problem, all FIR equations obey the following Backus-Naur Form (BNF) grammar:

EQUATION	::=	STREAM  __  "="  __  EXPR
STREAM	::=	A single upper-case letter representing a sample stream, such as A or X
EXPR	::=	VALUE  |  SAMPLE  |  EXPR  __  OPER  __  EXPR  |  "("  __  EXPR  __  ")"
VALUE	::=	A floating-point number, such as 0.25, 5, or -1.5
SAMPLE	::=	STREAM  "["  OFFSET  "]"
OFFSET	::=	An integer representing the sample offset into the stream, such as 0, 1, or -5, between -100 and 100 inclusive.
OPER	::=	"*"  |  "+"  |  "-"

Operations are handled in the standard order of precedence (parentheses first, multiplication before addition and subtraction, otherwise left-to-right), and the resulting value is rounded down to the nearest integer between 0 and 255 only after all calculations (if any) are done by the FIR filter. The __ symbol in the above grammar specifies a series of one or more spaces. Note that whitespace in an equation is only allowed where explicitly specified by the above grammar.

For example, a simple low-pass filter could be expressed as:

   Z = 0.5 * Y[0] + 0.25 * Y[-1] + 0.25 * Y[1]

Each output value of Z is based on the matching value in Y, modified by the nearest values of Y. A simple mixer can be represented as follows:

   D = C[0] + B[0]

although the clipping problems that such a filter would have should be apparent.

Obviously, for complicated effects, a number of filters can be connected together. In this problem, this is represented by STREAM; any relevant stream will either be an input value (the source audio, for example) or the output of a single FIR filter. However, a stream may be used as an input by more than one other filter. This constitutes a filter network.

Given a series of definitions of FIR filters and starting inputs, your task is to provide all of the outputs of the various filters. No FIR filter will have more than 10 operators or more than ten pairs of parentheses, nor will its representation use more than 80 characters. There will be at least one input stream and at least one output stream per data set, and all streams referenced in a filter equation will be defined in the same data set. All input streams and output streams will have the same number of samples, and there will be no "feedback loops" described by a filter network; that is, no filter will have input dependent on its output.

Although they sure sound cool when Pete Townshend uses them.

Yeah, I don't know either.

Stick-Tite blocks are one inch cubes of some sort of material that is permeable to air but not water. They stick quite nicely to each other when properly aligned, such that it's delightfully easy to make any sort of nice pixel-esque structure. They also stick well (but not too well) to perspex (also known as Plexiglas(tm)).

When dunked underwater and shaken about a bit, water fills the open space in a Stick-Tite construction such that any open spaces are filled unless they are completely enclosed inside the construction. While Stick-Tite blocks are water-impermeable, water can fill from any open space to any other open space that is orthogonally or diagonally adjacent.

X.. .X. ..X	Water can flow between the top-right and bottom-left areas
X.. XXX ...	Water cannot flow between the top-right and bottom-left areas

Consider the above two examples of such a construction. At the top, water can come through the blocks (represented by Xes) to fill the top chamber. At the bottom, water would not be able to flow between the two areas unless they were connected elsewhere.

After being dunked and wiggled, the Stick-Tite construction is pulled straight out of the water. Water drains out from any holes in the bottom or sides of the construction, coming out of all internal chambers and passages until the water level is even with the bottom of holes in the sides of chambers. In addition, due to static water pressure, the height of water in any pool still connected after this draining will never be higher than the bottom of the lowest hole that the pool's water can flow from.

XXXXXXXXXXX
XX......XXX
XXX.XXXXX.X
X...X.XXXXX
X.X.X...X.X
X.X~X~X.X.X
X.X~~~X...X
X.XXXXXXX.X

In the above example, the tildes represent the maximum amount of water that the center pool can hold; while the left side has a hole one unit higher than the right side, the water level for the pool as a whole cannot be higher than the one on the right side. The act of draining pools may make a pool of water into smaller, separate pools; these would then drain independently.

XXXXXXXXXXX
X......X..X
X.XXXX~X..X
X.X~~~~X...
X~XXXXXX~~X
X~~~~~~X~~X
X~~~~~~~~~X
XXXXXXXXXXX

A particular Stick-Tite construction will hold different amounts of water depending on which direction it's dunked into the bucket from. Given the blocks comprising a particular construction, you will determine how much water it can hold when dunked with each of its four edges facing straight up. (The construction is dried out completely between dunkings.)

You've been tasked with the development of the town character (or NPC) movement handling for a new game.

Any given NPC has a movement script with a few simple commands:

Command	Behavior
NORTH x	Move NORTH (up) x steps, one per turn
SOUTH x	Move south (down) x steps, one per turn
EAST x	Move east (right) x steps, one per turn
WEST x	Move west (left) x steps, one per turn
PAUSE x	Stay in the current location x turns

Note that the individuals who write the NPC movement scripts aren't the most careful coders in the world. Sometimes the scripts have the NPCs attempting to walk through walls and other barriers or even off the edge of the map. When this occurs, all of the steps of movement that would put the NPC in such an invalid location are converted into PAUSEs. For example, given this small snippet of a town:

...#
.1.#
...#

if the NPC represented by the 1 had

as their next command, that would be converted on the fly to

followed by

. This processing must be done before determining whether a script is

or

.

A script is cyclic if, at the end of the script, the NPC back in their starting position. This sort of script is simply looped indefinitely. The other type of script is reversible; if, at the end of the script, the NPC is not back in their starting position, they then run a reversed copy of the script, with directions switched (WEST becomes EAST, EAST becomes WEST, NORTH becomes SOUTH, and SOUTH becomes NORTH) and PAUSEs intact. The end result is the character returning to their starting location.

Original script segment	Reversed script segment
SOUTH 1 PAUSE 5 EAST 1	WEST 1 PAUSE 5 NORTH 1

For the sake of this problem, you can assume that no NPCs will ever attempt to occupy the same location on the map at the same time, although one may enter a location on the same turn as a different NPC leaves it, which is valid behavior.

The simulation starts at turn 0; your task is to show, given a map and set of NPCs with their scripts, what the simulation looks like after a large number of turns have passed.

In your own SF novel, humanity has spread out throughout the galaxy and has come to colonize many a planet. Aside from the obvious requirement of interstellar space flight in your book, you'd like to keep all other technologies, computers especially, similar to what is available in today's world. That means the computer networks on many of the colonized planets will still be designed by running copper or fiber optic cable between the computers.

Modern computer networks use packet switching which means that you do not have to physically run a separate cable between every pair of computers. It's enough that the computer network remains strongly connected. In other words, it's enough that for every pair of computers on the network, some path exists such that packets traveling to and fro between the computers can reach their destinations by being forwarded through any number of computers in-between.

This property of packet switching allows us to minimize how much cable has to be laid down to allow every computer on the network to communicate with every other. As a budding SF writer, you'd like to know the absolute minimum total length of cable that would be required to create a computer network between all the cities on your newly colonized planet, assuming there are no redundant or aggregate links in the network. When performing your calculations, you may assume that the planet is a perfect sphere, all the cables are run along the surface of the planet, and that no surface obstructions (like rivers or mountain ranges) exist to impede the run of cable.

The input to this problem will specify the diameter of the planet in question, and it will include a list of city coordinates given in degrees of

latitude

and

longitude

. For those who are not as cartographically savvy as they'd like, latitude is an angular measurement ranging from −90° at the South pole to +90° at the North pole and with 0° located at a planet's

equator

. Longitude is an angular measurement ranging between −180° and +180° with 0° specifying the

prime meridian

. By convention negative longitude represents locations to the West of the prime meridian, and positive longitude presents locations to the East.

A given image, such as a carrot in the above example, takes up a certain number of square inches on the fabric. In addition, a piece of fabric with more than one image will have those images in some sort of simple integral ratio, such as 3 carrots for every 2 bats. One instance of images in the given ratio is considered a full set.

Fabrics are sold by the square yard (and, for those of you who have forgotten, there are 36 inches to the yard). Given a collection of images, their sizes, and the ratios in which they occur, what is the maximum number of full sets that could possibly appear on one, two, and three square yards of patterned fabric?

(Note that this maximum implies totally arbitrary shapes and placements for the images, which may be different for the three lengths of fabric; the particulars of the layout are irrelevant for the purposes of the problem.)

Although your mission briefings include the exact year that a time agent must travel to, the physics of time travel don't make it quite so simple. Time travel can only be done by moving through wormholes that connect two specific instances of time together. As a result, an agent must travel through several wormholes in sequence to reach his or her destination time. In addition, an agent may have to spend some time living in the past or future while waiting for the next wormhole to appear. Traveling through a wormhole also isn't as simple as it might seem: moving forward in time through a wormhole will instanteously age the user by a certain number of years and moving backwards through one will instanteously make the traveller slightly younger.

Because the agency pays its agents based on how many years they've aged since joining the service, you are required to minimize the "aging process" as much as possible for every agent. Your goal therefore is to write a program that finds the optimal itinerary of wormhole jumps for each agent's mission and then reports the total number of years each agent will age after completing their assignment.

For agency accounting purposes, the formulas for computing total years aged on a mission are as follows:

• When starting from some year of origin and simply waiting until some destination year, the age a body accumulates in years equals:

  destination - origin

  In other words, if you were currently in the year 1785 and had to wait until the year 1793, then you will have aged 8 years.

• When traveling forward in time through a wormhole that connects one year of departure with a later year of arrival, then the number of years a body ages is equal to:

  floor((arrival - departure) / 2)

  Put in another way, you will age half the number of years (rounded down) you normally would have had you instead waited for the equivalent number of years to pass by. Note that when traveling over a small enough time difference, the years aged may be rounded down to zero for accounting purposes.

• When traveling backward in time through a wormhole that connects one year of departure with an earlier year of arrival, then the number of years a body "gains back" by becoming younger is equal to:

  floor((departure - arrival) / 4)

  In other words, you gain back a quarter of the difference between the two years (rounded down). Note that when traveling over a small enough time difference, the years "gained back" may be rounded down to zero for accounting purposes.
• A wormhole that starts and ends at the same year is possible, but causes no aging or time travel, and as such serves little purpose other than to confound the scientists.

Each dataset to this problem will contain a starting year from which all agents begin their travels and a list of mission assignments, one for each agent. Every mission assignment includes a final destination year that the agent must travel to. The mission can only be completed if the agent is able to make a round trip by traveling from the starting year to the mission's destination year and then traveling back to the initial starting year again. If such a round trip cannot be completed, then that particular mission is invalid. For the purposes of this problem, you also do not have to consider the maximum lifespan of any given agent. A mission is considered valid as long as a round trip is possible regardless of how high the count of years aged will be.

The Tenacious eDitor is an attempt to clone to power of a certain modal editor. However, it is notoriously bug-ridden. You've been asked to replace Kyle (who quit the devteam) and help with fixing some of the bugs.

The main problem with the current release of td, as it is commonly referred to, is that it cannot differentiate between text on a line and commands. Whenever a user wants to type an x, the editor interprets it as a command to delete the last character. This is problematic. Thankfully, commands are case-sensitive, and each letter is at most a single command (sometimes uppercase, sometimes lowercase), so one can manage to write any given line of text as long as it's allowed to look like something written by a fourteen-year-old hacker wannabe.

Editing occurs in an edit buffer, which starts out empty. The cursor in td rests in gaps, locations surrounding each printed character. When a non-command character is entered, the character is inserted to the right of the cursor's current location and the cursor moves to the gap to the right of the new character. (This is the standard behavior of most editors.) A line with no characters has a single gap. A line with a single printable character has two (one before and one after), a line with two printable characters has three, and so on.

The currently-implemented commands are:

Command keys	Result	Cursor location after operation
x	Delete the character immediately to the left of the cursor	One gap to the left
K	Delete all non-spaces to the left of the cursor, stopping at the first space encountered or the beginning of the line; if the previous character is a space, delete nothing	The gap to the right of the "stop" character
c	Duplicate the character to the left of the cursor, inserting it to the right of the cursor	The gap to the right of the duplicate character (one right)
D	Duplicate all non-spaces to the left of the cursor, stopping at the first space encountered or the beginning of the line and inserting them to the right of the cursor; if the previous character is a space, duplicate nothing	The gap to the right of the rightmost duplicate character
R	Reverse all non-spaces to the left of the cursor, stopping at the first space encountered or the beginning of the line; if the previous character is a space, reverse nothing	No change
p	Delete all characters to the left of the cursor	Leftmost gap
W	Delete all characters to the right of the cursor	No change
h	Move the cursor one gap to the left	One gap to the left
L	Move the cursor one gap to the right	One gap to the right
f	Move the cursor to the first gap on the line	Leftmost gap
G	Move the cursor to the last gap on the line	Rightmost gap
any non-command character	Insert the character into the edit buffer to the right of the cursor	One gap to the right

For the purposes of this problem, the only characters are uppercase and lowercase characters, digits, and spaces.

When a character is added internally to a line of text, all subsequent characters shift to the right (as in "insert mode"); when characters are deleted from anywhere other than the end of a line, all subsequent characters shift to the left.

Any commands which cannot properly do anything (attempting to move past the first or last gap, deleting characters when none exist, and so on) do nothing. They do not show up as printed characters.

Each line represents a different session of td; at the beginning of a new session, the edit buffer is empty.

Given a series of keystrokes by a user, can you determine what text actually results if it were entered in the current version of td?