Category Archives: Discrete Structures

Another un-productive weekend

The Problem

Convert a 12-variable Boolean expression in disjunctive normal form (DNF) to conjunctive normal form (CNF) so that generating the truth table is NP-hard.  Resulting CNF expression will be used in a student assignment.

Convert DNF to CNF is itself an NP-hard problem. If it were easy, SAT would not be NP. But I need a way to computationally convert DNF to CNF.

Possible solution: Wolfram|Alpha

Wolfram|Alpha is certainly able to convert DNF to CNF. Initial testing shows it works quite well for many variables, but it has a 200-character input limit. DNF expression is much longer than that.

Paid for annual Wolfram|Alpha subscription, hoping that would raise the character limit. Unsuccessful.

Applied for and was granted Wolfram|Alpha API access to try to get around the 200-character input limit. Unsuccessful. API error message is non-existent; it just silently refuses to run the query.

Possible solution: Mathematica

Download trial version of Mathematica and install on Mac. Success! Mathematica is able to convert DNF to CNF quickly. Twelve variables isn’t very many, anyway.

But Mathematica costs $500 to buy — a lot of money for a one-off problem I need to solve a couple times a year.

Possible solution: Karnaugh Maps

Learned that DNF can be converted to DNF using Karnaugh Maps. Just minimize the “zero” cells instead of the usual “one” cells. Invert the inputs. The result is a DNF expression. Seems easy enough.

Research K-map solvers. Most free ones are educational tools designed to show students how K-maps are solved. Because of the limited screen real estate, most can use at most four or five variables — nowhere near the twelve I need.

Possible solution: Roll my own K-Map solver

Getting desperate here. Spend a few hours thinking about how to solve K-Maps using only a truth table, as it would be silly to implement the actual 2D grid in a computer program. Came up with Quine-McCluskey algorithm on my own, so there’s that I guess.

But the Quine-McCluskey algorithm is also NP-hard. The number of prime implicants for 12 variables is as high as 3^n/3, or 177,147, so I see this is going nowhere fast.

Possible solution: Find a Q-M solver

Googled around for a Quine-McCluskey solver, ideally in Python. Found one called QM, referenced from the Wikipedia article. Ran it on my DNF expression. Waited about an hour, but still no results. Gave up.

Also found an optimized version of QM, but I’m already onto the next Possible Solution…

Possible solution: Symbolic computation package

Google around for a symbolic computation package for Python. Found one called Sympy. Install. Run. Plug in my DNF expression. Wait about 30 minutes with the CPU running at 100%. Give up.

Possible solution: Logic Friday

Learned that although DNF-to-CNF is NP-hard, some fine folks at UC Berkeley have discovered a heuristic approach that gives non-optimal but good-enough-for-me solutions. Originally for developing PLA devices at IBM, Logic Friday is a Windows application that implements the Espresso Heuristic Logic Minimizer.

Fire up a Windows VM, download, install Logic Friday. Plug in my DNF and, huzzah!, out pops a CNF within moments!

But.. It’s Windows. And non-scriptable. I’d like to be able to generate the DNF and convert to CNF in an automated fashion on a Linux box.

Working solution: Espresso on Linux

The Espresso Wikipedia page references a working copy of Espresso updated for ANSI C. (Note: this link is to the tar.gz file itself.)

Downloaded, installed on Linux.

Spent about six hours combing through the docs to get it to convert DNF to CNF (what it calls Product of Sum form). But output is still in a DNF formula.

Hack at the source code to get it to print CNF when the -pos command line argument is specified.

Finally get something to work:

$ espresso -pos -oeqntott mydnf.esp
v13.0 = (d|!j|!l|!m) & (!a|!g|m) & (d|!k|l|m) & (c|!d|!e|!j|!l) & (c|d|i|k|m) & (b|!g|!j|m) & (!a|!i) & (!c|k|l|m) & (a|b|j|!m) & (!c|!e|!k|l|!m) & (!b|d|!e|!l|!m) & (a|c|!e|l) & (!b|j|!l|m) & (e|i|j|!k) & (!d|e|!k|l) & (!c|h) & (b|!d|i|k) & (!c|d|!i) & (!a|d|l) & (!b|!c|!l) & (!b|c|e|!j) & (c|e|k|!l) & (a|g) & (!c|e|!l|!m) & (!c|j|!k) & (d|h) & (e|j|l|!m) & (b|d|!g|!k) & (!a|!d|j) & (c|!d|!i) & (!a|!c) & (!b|c|!h|l) & (!d|g) & (!d|!e|k) & (d|!j|k) & (!i|!j) & (!e|g) & (h|!k) & (!f);

Total time spent on this problem: 12+ hours spread across several days. But in the end I got something that worked.

New Problem

Didn’t get any grading done.

Advertisements

Computational Games, part 3

If you’ve been following along, you should have a working Java program that builds the entire game tree for the “1, 2, … 10” two-player game. We are now going to add some code to compute each node’s win/loss status.

(This is the third part of a series on computational games. Read part 1 and part 2 before tackling the code here.)

Start by refactoring the class to add a winLoss attribute. Its values will be W (win), L (loss), or ? (don’t know yet). Also modify the constructor and toString methods accordingly. The changes are highlighted in green.

public class OneTwoTen
{
    int player;
    int pile;
    OneTwoTen add1;
    OneTwoTen add2;
    char winLoss;

    public OneTwoTen(int player, int pile)
    {
        this.player = player;
        this.pile = pile;
        this.add1 = null;
        this.add2 = null;
        this.winLoss = '?';
    }

    public String toString()
    {
        return "(" + player + ", " + pile + ", " + winLoss + ")";
    }

All the other methods remain as they are.  Don’t you love nicely modularized code that “just works” when you make changes?

We can’t know whether a particular node is a win or a loss until we know what its children are. So we’ll do this from the bottom up as described in part 1 of this series.

The leaves are handled specially: they are automatically losses. (By the way, this is only true for games where the goal is to be first to finish. In other games, such as “Even or Odd,” the goal is to have an even number of tokens regardless of who took the last one. Therefore, the leaves are not strictly losses.)

For all other nodes, we call doWinLoss on the children, then figure out if there are any losses among them. If there are, we are a win. Otherwise, a loss.

public void doWinLoss()
{
    if (add1 == null && add2 == null) winLoss = 'L';
    else
    {
        if (add1 != null) add1.doWinLoss();
        if (add2 != null) add2.doWinLoss();

        if ( ((add1 != null) && (add1.winLoss == 'L'))  ||
             ((add2 != null) && (add2.winLoss == 'L')) )
             winLoss = 'W';
        else
             winLoss = 'L';
    }
}

That’s all there is to it! Run it like this:

OneTwoTen root = new OneTwoTen(1,0);
root.buildTree();
root.doWinLoss();
root.printTree();

You should see that the root (1,0) node is labeled with a W to indicate it is a winning position — the first player is guaranteed a way to win. All other nodes will be labeled according to the rules discussed in part 1.

Want to try this on your own? Modify the program to implement the Even or Odd game. Here are the rules:

  • Start with 15 tokens in the pile. Each player maintains their own piles, initially with zero tokens in them.
  • At each turn, a player can take one, two, or three tokens from the central pile and adds them to their pile.
  • The game is over when the central pile is empty.
  • The winner is the player with an even number in their pile, regardless of who took the last tokens or who has more.

Some key points to consider when writing the program:

  • Each node will have three children because you can take 1, 2, or 3.
  • The win/loss status of the leaves depend on who has an even number and are therefore not automatically losses.
  • The in-order traversal of the tree won’t be pretty. You might be better off with a pre-order traversal: display the node first, then call printTree on each of the children.

When you’re done, you’ll be able to answer the central questions: will the first player win or lose the game? What moves should each player make?

In later posts, we’ll tackle some harder problems:

  • “Loopy” games, in which a move may take you back to a state you’ve already seen. Checkers is a well-known example of a loopy game — once a piece is kinged, it can move back and forth on the board.
  • You may have noticed a lot of duplication among the nodes. A total of 232 states are in the tree, but there are only twenty-one distinct states. How can we avoid computing and storing the duplicates? This will help us deal with games that have a lot of states.

Along the way, you’ll learn some more advanced data structures, such as HashMaps, and Java techniques for using them effectively.

Computational Games, part 2

Let’s see about coding up the “1, 2, … 10” game so the computer can arrive at the same conclusion we did: that player 1 is going to win the game.

Read Computational Games, Part 1 for the background material.

Each node in the tree is represented with:

  • The player number (1 or 2)
  • The number of tokens remaining in the pile
  • Pointers to the child nodes

(By the way, the content of this blog is aimed at university/college freshman and sophomores. The code is straightforward with not a lot of fancy syntax until it’s needed.)

Let’s define a Java class to represent a OneTwoTen node. We’ll also provide a convenient constructor for setting the attribute values and a toString for displaying them.

public class OneTwoTen
{
    int player;
    int pile;
    OneTwoTen add1;
    OneTwoTen add2;

    public OneTwoTen(int player, int pile)
    {
        this.player = player;
        this.pile = pile;
        this.add1 = null;
        this.add2 = null;
    }

    public String toString()
    {
        return "(" + this.player + ", " + this.pile + ")";
    }
}

Here’s how to define a few nodes:

OneTwoTen n1 = new OneTwoTen(1, 0);    // The initial state
OneTwoTen n2 = new OneTwoTen(2, 10);   // One of the leaf nodes
OneTwoTen n3 = new OneTwoTen(1, 6);    // A mid-game node

(I use BlueJ for a lot of my coding. Its Code Pad feature lets me simply type in statements like the ones above. With BlueJ, I can quickly test code without laboriously defining a main method. If you’re not using BlueJ, you’ll need to put the statements into a main.)

We can inspect the nodes, again in the CodePad:

> n1.player
1 (int)
> n1.pile
0 (int)
> n2.player
2 (int)
> n2.pile
10 (int)
> n1.toString()
“(1, 0)” (String)
> n3.toString()
“(1, 6)” (String)

Next, define a method called spawn that creates a node’s children. For a node where the pile is 10, there’s nothing to do. If the pile is 9, only one child is created. In all other cases, both children are spawned.

The otherPlayer method is a helper. It simply returns the number of the other player.

public void spawn()
{
    if (pile == 10) return;   // Nothing to do for the leaves
    else if (pile == 9)
    {
        // Only one child here
        add1 = new OneTwoTen(otherPlayer(), pile + 1);
    }
    else
    {
        add1 = new OneTwoTen(otherPlayer(), pile + 1);
        add2 = new OneTwoTen(otherPlayer(), pile + 2);
    }
}

public int otherPlayer()
{
    if (player == 1) return 2;
    else return 1;
}

Try it out:

> OneTwoTen n1 = new OneTwoTen(1, 0);
> n1.spawn();
> n1.add1.toString()
“(2, 1)” (String)
> n1.add2.toString()
“(2, 2)” (String)

Looks good! To build the whole tree, we’ll spawn a node’s children, then call buildTree on each of the children, telling each one to build their own trees.

public void buildTree()
{
    spawn();
    if (add1 != null) add1.buildTree();
    if (add2 != null) add2.buildTree();
}

Did it work? Let’s see…

> OneTwoTen n1 = new OneTwoTen(1, 0);
> n1.buildTree();
> n1.add1.add1.toString()
“(1, 2)” (String)
> n1.add1.add2.toString()
“(1, 3)” (String)
> n1.add1.add1.add1.toString()
“(2, 3)” (String)
> n1.add1.add1.add2.toString()
“(2, 4)” (String)

Sure looks like it! It would be nice to see the whole tree, though. The next method below prints the tree, but it’s sideways. You’ll need to turn your head 90 degrees to the left to see it.

The first printTree method takes an integer argument that tells it how far to indent the node. It calls printTree on the take2 node (so it appears on the right side of the sideways tree), then prints itself, then calls printTree on the take1 node. This is called an in-order traversal.

The second no-argument method just calls the first one with an indent of 0.

public void printTree(int indent)
{        
    if (add2 != null) add2.printTree(indent + 1);

    for (int i = 0; i < indent; i++) System.out.print("   ");
    System.out.println(toString());

    if (add1 != null) add1.printTree(indent + 1);
}

public void printTree()
{
    printTree(0);
}

I’ll leave it to you to call printTree after building the tree and seeing the fruits of your (well, my) labor.

In the next post, I’ll show you how to assign the win-loss label to each node.

Computational Games, part 1

Consider this simple, two-player game. The rules are easy:

  • Both players take turns adding tokens to a central pile, which starts empty.
  • Each player on their turn can add either one or two tokens.
  • The player who adds the tenth token wins.

Go ahead: find a friend and play this game. You don’t even need tokens to play; on your turn just announce how many you’re adding to the pile and what the new value of the pile is. Play the game a few times.

I’ll wait here.

Got it? Great!

While you were playing, you probably discovered that when the score reached a certain point, it became evident that one of the players was going to win no matter what the other did. In other words, the game was essentially over at some point before the score reached ten. There are a few such points in the game. I’ll leave it to you to discover where they are.

This game, which we’ll call “1, 2, … 10,” falls under the category of computational games. With such games, we can use a computer to map out all possible states and moves and completely solve them. Once solved and armed with the tree of all possible moves, a human (or computer) can be unbeatable.

Other computational games include:, Tic-Tac-Toe (or Naughts and Crosses), Othello, Checkers, Connect 4, Nim, Mancala, Chess, and Go. They share a common set of characteristics:

  • Fixed number of players
  • All players have full information; nothing is hidden from any of the players
  • No randomization, such as dice rolls or drawing cards from a shuffled deck

Many beloved games are not computational games, such as poker (hidden cards and randomization), Chutes and Ladders (randomization), Yahtzee (dice rolls), Stratego (hidden pieces), and Hangman. It doesn’t mean we can’t write computer programs to play these games; they just don’t fall under the category of computational games.

Now that we know what computational games are, let’s set about visualizing them as trees.

We’ll represent each state of the 1, 2, … 10 game as a pair of integers: the player number (1 or 2) and how many tokens are in the pile. The initial state is (1, 0). Each state has two possible next moves, the result of adding 1 or 2 to the pile. (Except near the end of the game, where some of the states have only one possible next move.) Here are the first few turns of the game.

The first two moves of the game.

Notice that each row alternates between player 1 and 2. In the top row (the initial state), it is player 1’s turn. The middle row is player 2’s turn. And the bottom row is player 1’s turn.

Some terminology and concepts are worth going over:

In computer science, each of the boxes is called a node. The whole thing is called a tree, even though it is typically drawn upside-down. The topmost node is the root. The nodes at the bottom are called leaves. Each parent node has at least one child, except the leaves that have no children. The root of the tree has no parent.

Let’s draw a few more moves. As you can see, the tree is lop-sided: there are more moves on the left side of the tree because each move increments the score by one, whereas the right side increments by two.

The full game. Not all moves are shown.

At the bottom of the tree are all the end-game states, where the score is 10. We will label each of the states depending on whether they are a winning state or a losing one.

Normally you’d think of the “10” states as wins, but look closely: they are actually losses. Consider the (2,10) state at the far right. It is player 2’s turn and the score is 10. Therefore, player 2 has lost the game because, in reality, the other player won by placing the last two tokens. If player 2 finds himself in that position, he has lost. We label (2,10) as a loss.

Indeed, each of the “10” states are losses for that particular player. All the (1,10) states are losses for player 1 and all the (2,10) states are losses for player 2. We’ll color the losing states red.

The losing states (the “10” states) are colored red.

Now, if the leaf states are losses, the ones immediately above (their parents) them must be wins. Take a look at the (1,8) state just above the losing (2,10) at the far right. It must be a win for player 1 because all she has to do is play two tokens and force player 2 to lose. Player 1 is guaranteed to win from this position.

(I should make it clear at this point that both players are playing to win. No one makes a boneheaded move. Of course player 1 could lose by playing only one token, but she’d be stupid to do so. She’s going to win by playing two tokens.)

The (2,9) states are likewise wins for player 2. He’s guaranteed to win by putting player 1 into a losing position.

In fact, all states that are parents of a losing state are wins. We will color all of them green.

All states with a losing child are wins (green).

What about the other nodes? Consider the (1,7) position, whose children are (2,8) and (2,9). How should we color it?

Unfortunately, it is a loss for player 1 because no matter what move she makes, player 2 will win. We must color the (1,7) node red to signify it is a losing position. The (2,7) state near the middle of the drawing is also a losing state by similar reasoning.

I hope you discovered this tidbit while you were playing the game with a friend. If it was your turn and the score was 7, you were going to lose no matter what you did. (In fact, it wasn’t a game of trying to be first to reach 10; instead the goal was to be first to reach 7.) All “7” states are losses and we should color them red.

All the “7” states are losses (red).

At this point, we can establish a couple of general rules for identifying whether a state is a win or a loss:

  • A state is a win if at least one child state is a loss.
  • A state is a loss if all child states are wins.
  • A state is a draw if there are no losing children and at least one of them is a draw.

The third rule (draw) doesn’t apply to this game because it cannot end in a draw. I’ve included it here for future reference.

Note that to identify whether a particular state is a win or a loss, you don’t need to look any further down the tree than the next move. Start by labeling the leaf states (the ones at the bottom) and work your way up to the root of the tree, applying the three rules above. This leads us to the final coloring.

The final coloring of the game tree.

Something amazing has happened here: the initial state (1,0) is a win! Put another way: player 1 is going to win the game if she doesn’t make any mistakes. Every time.

What move should she make to assure herself of a win? She should aim to force player 2 to lose by playing one token. Player 2, finding himself in the losing (2,1) state, can do nothing to guarantee himself a win.

Armed with this complete game tree, both players can use the information to try to win the game. All they have to do is look for their current position in the tree and see if there are any moves that put the other player into a losing state. If there is at least one, take it. But if there are none, perhaps they should just resign. Or hope the other player goofs up.

What’s next? Try playing the games described below. See if you can figure out whether the first or second player wins, and what the winning strategies are.

Even or Odd: Start with 15 tokens in the pile. Each player takes turn removing one, two, or three tokens from the pile and keeping them. When all the tokens have been removed, the winner is the player who ends up with an even number of tokens.

Nim: Start with three piles of tokens of 3, 4, and 5, respectively. Each player can remove any number of tokens from any one pile on their move. The winner is the player who removes the last token.

To code up the “1, 2, … 10” game in Java, continue to part 2.

I’m indebted to Dr. Daniel Garcia of UC Berkeley whose Games Crafters undergraduate research group introduced me to the field of computational game theory.