charlesreid1.com blog

CSE 143 Final Project: Classy

Posted in Computer Science

permalink

Table of Contents

Problem Description

Comedian John Cleese, in his memoir So Anyway..., described the social classes of his mother and father as "upper-uper-lower-middle class" and "middle-middle-middle-lower-middle class", respectively. Write a program that will sort individuals based on a labeling of their social standing by class.

The three main classes are upper, middle, and lower. Classes progress hierarchically from right to left. For example, lower-upper would come before lower-lower. There is also ordering within a class, so upper-upper is a higher class than middle-upper.

Once you have reached the lowest level of detail of one of the classes, assume that all further classes are equivalent to middle. This means upper and middle-upper are equivalent, and middle-middle-lower-middle and lower-middle are equivalent.

Input files have a line with the number of names, then one name per line, with the name, a colon, then the title. For example:

5
mom: upper upper lowre middle class
dad: middle middle lower middle class
queen_elizabeth: upper upper class
chair: lower lower class
unclebob: middle lower middle class

The proper output should be the name of each person, sorted in order according to their social status, e.g.,

queenelizabeth
mom
dad
unclebob
chair

Solution Approach

(This discusses an approach specific to Java, but a similar approach could be adopted for other languages in which comparison operators can be overloaded for objects.)

The problem lays out all of the essential components that a solution requires. This can most easily be implemented using an object and a comparator: the object represents a person, and has a field to store their name and a field to store their titles (array-like container for Strings). These objects would then implement comparators so that individuals could be compared. This functionality then allows the array to be sorted, using the built-in Collections sort function or a custom sort function.

Algorithm

The classy algorithm can be briefly described in this way: we are iterating over two lists of strings, of possibly unequal length, and comparing them right to left. We have a few very simple rules that determine whether one title comes before the other. We have a few simple rules for breaking ties.

The core of the algorithm is the comparison operation, in which we are assuming that these two things are equal, until we encounter evidence to the contrary. Briefly, the pseudocode can be expressed as follows (where we adopt the Java convention that a negative result means the first item comes before the second item):

if item1 < item2:
    return -1
else if item1 > item2: 
    return 1
else:
    # keep going

If we find a difference, we stop and return right away, but otherwise we continue, and assume the two are equal.

The problem statement tells us that if a title is missing, and the title lengths are mismatched, we should fill in with "middle". This translates into a second comparison block, in which one of the items is hard-coded as "middle", due to an empty list of titles:

if item < "middle":
    return -1
else if item > "middle"
    return 1
else:
    # keep going

Here is how these fit together: * Start by splitting the input titles, most likely strings, into lists * Iterate over each title, from right to left, and compare the titles. * When we reach the end of the shorter list, continue comparing titles right to left, filling in "middle". * If the titles are tied, break ties with name. * The algorithm should be implemented in a way that has access to both the titles and the names of the two people being compared. * In Java, we can define people objects, then we can either have People objects implement Comparable, or we can define our own Comparator for two People objects.

Pseudocode

When we translate the above procedure into Python-like pseudocode, here is the result:

define compare_lengths(title1, title2):
    list1 = title1.split()
    list2 = title2.split()
    for i in min(list1.size, list2.size):
        sal1 = list1.reverse[i]
        sal2 = list2.reverse[i]
        if sal1 < sal2:
            return -1
        else if sal1 > sal2:
            return 1

    larger_list = <point to larger list>
    for i in ( min(list1.size,list2.size)+1 ... max(list1.size, list2.size) ):
        salX = larger_list.reverse[i]
        if SalX < "middle":
            return -1
        if salX > "middle"
            return 1

    # If you get here, it's a tie. Use names for tie-breaker.

Using an Object-Oriented Approach

To apply object-oriented principles in this situation, we want to bundle together related data, and abstract away details. That means we want to create an object to associate the name and titles of a given person, and implement functionality to allow each person to be compared with other people.

This will allow us to create two people and compare them with greater than, less than, or equal to operators. More importantly, this will also allow us to perform sorting.

Our Java program Classy is a simple driver that loads the names and titles of people from standard input.

The Person class stores associated name and title data for each person. This class implements the Comparable interface, which requires it to implement a compareTo() method.

class Person implements Comparable<Person> {

    ...

    public int compareTo(Person p2) { 

The Person class constructor just tokenizes one line of input, populating the titles list and the person's name. Here is the declaration of those private fields:

class Person implements Comparable<Person> {
    private String name;
    private ArrayList<String> titles;

    ...

The implementation of the compareTo method utilized Stack objects to examine the sequence of titles in reverse.

Pop the stacks until one of them is empty. Then, keep popping until both are empty, using "middle" in place of the empty stack.

    /** Compare a person to another person. */
    public int compareTo(Person p2) { 

        Stack<String> st1 = new Stack<String>();
        Stack<String> st2 = new Stack<String>();

        // Add names to stack, left to right
        for(String title : this.getTitles()) {
            st1.push(title);
        }
        for(String title : p2.getTitles()) { 
            st2.push(title);
        }

        // Compare each name, from right-to-left.
        // If stack 1 is not empty, pop next item, otherwise use "middle"
        // If stack 2 is not empty, pop next item, otherwise use "middle"

        int max = Math.max(this.getTitles().size(), p2.getTitles().size());
        for(int i=0; i<max; i++) {

            // Pop names from the stack, right to left.
            String s1, s2;

            if(!st1.isEmpty()) {
                s1 = st1.pop();
            } else {
                s1 = "middle";
            }

            if(!st2.isEmpty()) {
                s2 = st2.pop();
            } else {
                s2 = "middle";
            }

            // Rather than converting strings to numbers,
            // compare the strings directly (lower < middle < upper).
            int res = s2.compareTo(s1);

            // Return the first non-zero value
            if( res != 0 ) {
                return res;
            }
        }

        // If we reach here, there was a tie.
        // Use name as tie breaker.
        return this.getName().compareTo(p2.getName());
    }

Code

Here is the entire Classy code, also available on git.charlesreid1.com:

import java.util.*; 
import java.io.*;
public class Classy { 

    public static void main(String[] args) { 
        Scanner s = new Scanner(new BufferedReader(new InputStreamReader(System.in)));

        // Read the input file: new Person for each line
        int n = Integer.parseInt(s.nextLine());
        ArrayList<Person> people = new ArrayList<Person>();
        while(s.hasNextLine()) {
            String line = s.nextLine();
            String[] deets = line.split(" ");
            Person p = new Person(deets);
            people.add(p);
        }

        Collections.sort(people);
        for(Person p : people) { 
            System.out.println(p);
        }
    }
}

class Person implements Comparable<Person> {
    private String name;
    private ArrayList<String> titles;

    /** Person constructor - pass in a String array with the deets. */
    public Person(String[] deets) { 
        name = deets[0];
        // Remove : from name
        name = name.substring(0,name.length()-1);

        // initialize list of classes 
        titles = new ArrayList<String>();
        for(int i=1; i<deets.length-1; i++) { 
            titles.add(deets[i]);
        }
        // Last word will be "class", so ignore.
    }

    /** Get a person's name. */
    public String getName() { return name; }

    /** Get a person's titles in an ArrayList. */
    public ArrayList<String> getTitles() { return titles; }

    /** Get a string representation of a person. */
    public String toString() { return getName(); }

    /** Compare a person to another person. */
    public int compareTo(Person p2) { 

        Stack<String> st1 = new Stack<String>();
        Stack<String> st2 = new Stack<String>();

        // Add names to stack, left to right
        for(String title : this.getTitles()) {
            st1.push(title);
        }
        for(String title : p2.getTitles()) { 
            st2.push(title);
        }

        // Compare each name, from right-to-left.
        // If stack 1 is not empty, pop next item, otherwise use "middle"
        // If stack 2 is not empty, pop next item, otherwise use "middle"

        int max = Math.max(this.getTitles().size(), p2.getTitles().size());
        for(int i=0; i<max; i++) {

            // Pop names from the stack, right to left.
            String s1, s2;

            if(!st1.isEmpty()) {
                s1 = st1.pop();
            } else {
                s1 = "middle";
            }

            if(!st2.isEmpty()) {
                s2 = st2.pop();
            } else {
                s2 = "middle";
            }

            // Rather than converting strings to numbers,
            // compare the strings directly (lower < middle < upper).
            int res = s2.compareTo(s1);

            // Return the first non-zero value
            if( res != 0 ) {
                return res;
            }
        }

        // If we reach here, there was a tie.
        // Use name as tie breaker.
        return this.getName().compareTo(p2.getName());
    }
}

References

  1. "ACM Pacific Region Programming Competition." Association of Computing Machinery. 19 June 2017. <http://acmicpc-pacnw.org/>

  2. "finalproject-143 (git repository)." Charles Reid. Modified 16 June 2017. Accessed 23 June 2017. <https://git.charlesreid1.com/cs/finalproject-143/src/master/classy/Classy.java>

CSE 143 Final Project: Checkers

Posted in Computer Science

permalink

Table of Contents

The Problem

This is a programming challenge that was assigned to some of my CSE 143 students as a final project for their class.

The origin of this problem was the Association of Computing Machinery (ACM)'s International Collegiate Programming Competition (ICPC), in particular the Pacific Northwest Regional Competition, Division 1 challenges from 2015.

Link to Pacific NW ACM ICPC page.

Problem Description: Checkers

In the Checkers problem, you are presented with a checkerboard consisting of black and white squares. The boards follow a normal checkers layout, that is, all of the pieces occupy only the light or dark squares on the board.

There are several white and black pieces arranged on the checkerboard. Your goal is to answer the following question: can any one single black piece be used to jump and capture all of the white pieces in a single move? This assumes that each of the black pieces are "king" pieces and can jump in either direction.

For example, the following 7x7 board configuration has one black piece that can jump all of the white pieces on the board with a single sequence of moves. The black piece at B2 jumps to D4, then to F2.

Checkerboard 1 - demonstrate solution

If an additional white piece is added, there is no sequence of moves that will allow any black piece to jump all of the white pieces.

Checkerboard 2 - demonstrate no solution

Input File

The input file consists of one line with a single integer, representing the size of the (square) board. Following are characters representing the board state.

. represents a square that pieces cannot occupy - the off-color squares.

_ represents an unoccupied but valid square.

B represents a black piece. W represents a white piece.

Example:

8
._._._._
_._._._.
.W._.B._
_.W.W._.
.W.B._._
_._._._.
.W._.W._
_._._._.

Output

The output is simple: simply state which of the black checkers is capable of jumping each of the white checkers. If none, say "None". If multiple, say "Multiple".

The Solution

Keep It Simple

To successfully solve the checkers problem, it is important to keep it simple. There are different ways of representing the checkers problem abstractly, but the best representation in a program is the simplest one - use a 2D array of chars to represent the board.

Also as usual with permutations of arrangements on boards of fixed size, recursion will be useful here.

Solution Analysis: Parity

We can begin our analysis of the checkers problem with a few observations.

First, we know that the valid squares for checkers are squares that are off by two. But we know further that the black checkers must only move in jumps, which mean that a piece at \((i,j)\) can only reach squares indexed by \((i + 4m, j + 4m)\) or \((i + 4m + 2, j + 4n + 2)\), where \(m, n\) are positive/negative integers.

That is, the checker pieces can make jumps of 2 squares at a time. For example, if a checker starts at the square \((3,3)\) and jumps a white piece down and to the right, it moves to square \((5,5)\) or \((3+2, 3+2)\). If it jumps another white piece up and to the right, it moves to square \((3, 7)\) or \((3, 3 + 4)\).

Further, we know that a black checker can only jump checkers at squares of the form \((a + 2m + 1, b + 2n + 1)\). Thus, black checkers either have the correct parity to jump all of the white checkers, or they have the same parity as the white checkers (in which case they can be ignored).

If a black checker does not have the correct parity to jump white checkers, we can save ourselves time by not checking it.

For example, in the checkerboard below, there are four black checkers, but only one (row 2, column 3) has the correct parity to jump each of the white pieces. The other three are

The other three has the correct parity, while the black checker in the right do not.

Checkerboard 3 - illustrate parity

Solution Analysis: Graphs and Euler Tours

If we examine the squares with correct parity, we can translate the board into a graph representation. Squares with the "jump" parity are nodes on the graph that can perform jumps. (No whites should have jump parity, otherwise the board is impossible.)

Squares with the "jumped" (i.e., white pieces) parity are nodes that are being jumped. These nodes form the edges between jump parity nodes, and these edges must be occupied by a white piece for a black piece to be able to pass through them. In this way, we can think of white pieces as "bridges" between jump parity squares.

This representation leads to thinking about the tour the black checker takes through the checkerboard as an Euler tour across the graph.

An Euler Tour, made famous by the Seven Bridges of Königsberg problem solved by Euler in 1736, is a path that visits each node of the graph, traversing each edge once and only once.

Euler showed that an Euler path visiting each edge of the graph depends on the degree of each node in the graph. For an Euler path to exist, the graph must be connected and there must be exactly zero or two nodes of odd degree.

If we walk through the checker board and construct the graph (or assemble the information that the graph would have told us), we can determine whether an Euler tour exists, and find the Euler tour.

The example above shows a checkerboard with two white pieces forming two edges. The first white piece connects a jump parity square with a black piece on it to a jump parity square that is empty. The second white piece connects two empty jump parity squares.

The black "entrance" node has an odd degree (1). The second, unoccupied node has an even degree (2). The third, unoccupied node has an odd degree (1). Therefore the graph has two nodes of odd degree, so an Euler tour exists.

If we modify this example to add one additional white checker piece on a square with correct parity, the Euler Path analysis identifies this as a board with no solution:

Checkerboard 4 - illustrate no Euler tour

This is because three of the nodes have degree 1 and one node has degree 3, for a total of 4 nodes with odd degree. The requirements for an Euler Tour to exist (equivalent to saying a solution to the Checkers problem can be found for a given black checker) are violated, so no solution can be found.

If we were to add a second black checker piece two squares away, an alternate graph (highlighted in blue) can be constructed, and an alternate Euler path through the graph is available.

Checkerboard 5 - illustrate alternate Euler tour

On the red graph, each node has an odd degree, so the number of nodes with odd degree is not 0 or 2. On the blue graph, only the start and end nodes have an odd degree (1), while the rest of the nodes have a degree of 2 (one input and one output). This means an Euler Tour exists on the blue graph.

In practice, a given black piece has a given graph connecting squares on the checkerboard - we can ask each node on that graph for its degree, and the degree of its neighbors, and if a black piece results in an invalid number of odd nodes, we can abandon it.

Solution Algorithm

The algorithm to find solutions to this problem very roughly follows this pattern: * First, perform a parity check to determine if a solution is impossible. * Loop over each square of the board, looking for black pieces * For each black piece: * Look at each neighbor: * Determine if there is a square to jump to if neighbor is white * Determine number of odd neighbors * Fail if more than 2 odd neighbors, or 2 odd neighbors and odd self * Backtracking: explore neighbors, determine if all whites can be jumped

Solution Pseudocode

The solution code has three basic parts (four, including the input parser): * Initialize and parse the board * Loop over each square, checking if black piece is a solution * Function to check if black piece is a solution piece * (Recursive backtracking) function to jump each white piece possible to jump.

Start with the initialization of the board and looping over each black piece to check if it is a solution piece:

initialize solutions counter
initialize board

for each s in squares:
    if s is black piece:
        if s is solution piece:
            increment solutions counter
            save location

print summary

Now we just need to implement functions that can (a) check if a square contains a black piece (easy) and (b) check if a black piece is a solution piece (uh... kind of what the whole problem boils down to, no?)

We break that functionality into a separate function. Here is the pseudocode to check if a black piece in a particular square is a solution piece. This function iterates over squares with jump parity - that means this function traverses the nodes only in the graph representation of the checkerboard.

This function enforces the requirement that no node can have more than 2 odd neighbors, or be odd if it has more than 2 odd neighbors, since a graph must have 0 or 2 nodes with odd degree in the graph for an Euler Tour to exist.

While we're at it, we also check if there are any white checker pieces without a square to land in when they are jumped (i.e., landing square blocked by another black piece or at edge of board).

function is solution piece:
    for each square of similar "jump" parity:
        for each neighbor:
            check if neighbor is odd 
            if a neighbor square is white:
                if next square is not empty:
                    fail fast

    if more than 2 odd neighbors, or 2 neighbors and odd:
        fail fast

    # we have a viable solution

    recursively count number of jumped white checkers 

    if number of jumped white checkers equals number of white checkers on board:
        return true

Finding squares of similar jump parity is as easy as looping over each row and column, and checking if it is off by 2 with the row/column of the black checker piece that we are currently checking. Checking if a neighbor is odd is as straightforward as counting its degree - checking each of its four neighbors and determining which ones are open. This leaves finding the number of jumped white checkers as the only functionality left to define.

define number of jumped white checkers:
    initialize white checkers jumped counter
    for each neighbor:
        if white piece, unvisited, with an empty place to jump to:
            visit white piece
            increment white checkers jumped
            call number of jumped white checkers on next next neighbor
            # this should be the empty space
    return number white checkers jumped

References

  1. "ACM Pacific Region Programming Competition." Association of Computing Machinery. 19 June 2017. <http://acmicpc-pacnw.org/>

Teaching Recursion with the N Queens Problem

Posted in Computer Science

permalink

Table of Contents:

A Gentle Introduction to Recursion

Recursion, particularly recursive backtracking, is far and away the most challenging topic I cover when I teach the CSE 143 (Java Programming II) course at South Seattle College. Teaching the concept of recursion, on its own, is challenging: the concept is a hard one to encounter in everyday life, making it unfamiliar, and that creates a lot of friction when students try to understand how to apply recursion.

The key, as I tell students from day one of the recursion unit, is to always think in terms of the base case and the recursive case. The base case gives your brain a "trapdoor" to exit out of an otherwise brain-bending infinite conceptual loop. It helps recursion feel more manageable. But most importantly: it enables thinking about recursion in terms of its inputs and outputs.

More specifically, to understand recursion requires (no, not recursion) thinking about two things: where you enter the function and when you stop calling the function. These are the two least complicated cases, and they also happen to be the two most important cases.

College courses move at an artificially inflated pace, ill-suited for most community college students, and the material prescribed must be presented at the given pace mostly independent of any real difficulties the students face (there is only minimal room for adjustment, at most 2-3 lectures).

This means that, before the students have had an opportunity to get comfortable with the concept of recursion, and really nail it down, they're introduced to yet another mind-bending topic: recursive backtracking algorithms.

These bring a whole new set of complications to the table. Practice is crucial to students' understanding, and all too often, the only way to get students to practice (particularly with difficult subject matter like recursion) is to spend substantial amounts of time in class. My recursion lectures routinely throw my schedule off by nearly a week, because even the simplest recursion or backtracking exercise can eat up an hour or more.

Recursive Backtracking

Backtracking is an approach for exploring problems that involve making choices from a set of possible choices. A classic example of backtracking is the 8 Queens problem, which asks: "How many ways are there of placing 8 queens on a chessboard, such that no queen attacks any other queen?"

The problem is deceptively simple; solving it requires some mental gymnastics. (By the way, most people who have actually heard of the problem are computer scientists who were exposed to it in the process of learning how to solve it, leading to the hipster effect - it's often dismissed by computer scientists as an "easy" problem. The curse of knowledge at work.)

The recursive backtracking algorithm requires thinking about the squares on which to place the 8 queens in question as the set of choices to be made.

The naive approach ignores the constraints, and makes all 8 choices of where to place the 8 queens before ever checking if the queen placements are valid. Thus, we could start by placing all 8 queens in one single row on the top, or along one single column on the left. Using this approach, we have 64 possibilities (64 open squares) for the first queen, then 63 possibilities for the second queen, then 62 possibilities for the third queen, and so on. This gives a total number of possible combinations of:

$$ \dfrac{64!}{(64-8)!} = 178,462,987,637,760 $$

(By the way, for those of you following along at home, you can do this calculation with Python:)

>>> from scipy import *
>>> math.factorial(64)/math.factorial(64-8)
178462987637760L

Even for someone without a sense of big numbers, like someone in Congress, that's still a pretty big number. Too many for a human being to actually try in a single lifetime.

Paring Down the Decision Tree

But we can do better - we can utilize the fact that the queen, in chess, attacks horizontally and vertically, by doing two things:

  • Limit the placement of queens so that there is one queen per column;

  • Limit the placement of queens so that there is one queen per row.

(Note that this is ignoring diagonal attacks; we'll get there in a minute.)

This limits the number of solutions as follows: the first queen placed on the board must go in the first column, and has 8 possible squares in which it can go. The second queen must go in the second column, and has 7 possible squares in which it can go - ignoring the square corresponding to the row that would be attacked by the first queen. The third queen goes into the third column, which has 6 open squares (ignoring the two rows attacked by the two queens already placed).

That leads to far fewer solutions:

$$ 8! = 40,320 $$

and for those following along at home in Python:

>>> from scipy import *
>>> math.factorial(8)
40320

To visualize how this utilization of information helps reduce the problem space, I often make use of a decision tree, to get the students to think about recursive backtracking as a depth-first tree traversal.

(By the way, this is a strategy whose usefulness extends beyond the 8 queens problem, or even recursive backtracking problems. For example, the problem of finding cycles in a directed graph can be re-cast in terms of trees.)

So far, we have used two of the three directions of attack for queens. This is also enough information to begin an implementation of an algorithm - a backtracking algorithm can use the fact that we place one queen per column, and one queen per row, to loop over each row, and steadily march through each column sequentially (or vice-versa).

The Pseudocode

There is still a bit more to do to cut down on the problem space that needs to be explored, but before we do any of that, we should first decide on an approach and sketch out the psuedocode.

The structure of the explore method pseudocode thus looks like:

explore(column):
    if last column:
        # base case
        add to solutions
    else:
        # recursive case
        for each row:
            if this is a safe row:
                place queen on this row
                explore(column+1)
                remove queen from this row

The Actual Code

Over at git.charlesreid1.com/charlesreid1/n-queens I have several implementations of the N Queens problem:

Row, Column, and Diagonal Attacks

We have already utilized knowledge that there will only be one queen per column, and one queen per row. But one last bit of information we can utilize is the fact that queens attack diagonally. This allows us to eliminate any squares that are along the diagonals of queens that have already been placed on the board.

How to eliminate the diagonals? It basically boils down to two approaches:

  1. Use a Board class to abstract away details (and the Board class will implement "magic" like an isValid() method).

  2. Hack the index - implement some index-based math to eliminate any rows that are on the diagonals of queens already on the board.

The first approach lets you abstract away the details, possibly even using a Board class written by a textbook, which is lazy fine, if you are working on a practical problem and need some elbow grease, but not so much if you are a computer science student learning the basic principles of software design.

The second approach requires some deep thinking about how the locations of the N (or 8) queens are being represented in the program.

Accounting for Diagonal Attacks

At some point, when you use the above pseudocode, you are going to want to know the answer to the following question: for a given column k, what rows are invalid because they are on diagonals of already-placed queens?

To answer this, think about where the diagonal indices of chess board squares are located, and how to find the diagonals on column X attacked by a queen placed in column Y.

The following diagram shows a queen on row 3 of column 2, and the diagonal attack vectors of that queen. Each of the squares along those diagonal vectors can be ruled out as possible squares to place a queen. When selecting a square for the third queen, which goes in the third column, the second and fourth rows can both be ruled out due to the diagonals. (The third row, of course, can also be ruled out, due to the one-queen-per-row rule.)

However, the effect of the already-placed queen propagates forward, and affects the choice of possible squares for each queen after it. If we jump ahead in the recursive algorithm, to say, queen number 6, being placed on column number 6 (highlighted in blue), the queen in column 2 (row 3) still affects the choice of squares for that column (as do all queens previously placed on the board). In the case pictured in the figure, the seventh row (as well as an off-the-board row) of column 6 can be ruled out as possible squares for the placement of the 6th queen.

Accounting for these diagonal attacks can lead to substantial speed-ups: each queen that is placed can eliminate up to two additional squares per column, which means the overall decision tree for the N queens problem becomes a lot less dense, and faster to explore.

Why the N Queens Problem?

Invariably, some students will deal with this difficult problem by questioning the premise of the question - a reasonable thing to wonder.

This leads to a broader, more important question: why do computer scientists focus so much on games?

Games, like computers, are self-contained universes, they are abstract systems, they remove messy details and complications. They allow you to start, from scratch, by setting up a board, a few rules, a few pieces - things that are easy to implement in a computer.

Mazes, crossword puzzles, card games, checkers, chess, are all systems with a finite, small number of elements that interact in finite, small numbers of ways. The beauty of games is that those small rule sets can result in immensely complex systems, so that there are more branches in the chess decision tree (the Shannon number, \(10^{120}\)) than there are protons in the universe (the Eddington number, \(10^{80}\)).

That simplicity is important in computer science. Any real-world problem is going to have to be broken down, eventually, into pieces, into rules, into a finite representation, so that anything we try to model with a computer, any problem we attempt to solve computationally, no matter how complex, will always have a game-like representation.

(Side note: much of the literature in systems operations research, which studies the application of mathematical optimization to determine the best way to manage resources, came out of work on war games - which were themselves game-ified, simplified representations of real, complex systems. Econometrics, or "computational economics," is another field where game theory has gained much traction and finds many practical applications.)

Recursion, too, is a useful concept in and of itself, one that shows up in sorting and searching algorithms, computational procedures, and even in nature.

But it isn't just knowing where to look - it's knowing what you're looking for in the first place.

Tags:    java    algorithms    recursion    n-queens   

March 2022

How to Read Ulysses

July 2020

Applied Gitflow

September 2019

Mocking AWS in Unit Tests

May 2018

Current Projects

November 2017

A Hard(y) Math Problem