1972 Canada-Russia Summit Series Hockey Game 8: A Social Network Analysis Part One (1st Period)

The 1972 Canada-Russia Summit Series to some is a defining moment in Canada’s history. At the height of the Cold War, 28 hockey players went into a tournament thinking they it was an exhibition series that no one would take seriously. By the end, the 28 were defenders of Canadian hockey against the surprising hockey prowess and political power of the Russian bear. The final game, number 8 in the series of 8 was particularly dramatic. After a closely-fought first period, the Canadians fell 5-3 in the second, but came back to tie it in the third until 19:26 of the third period when Paul Henderson … well if you don’t know the story, you probably aren’t Canadian and don’t care anyway. Well, here’s the game on YouTube if you want to see more.

Game 8 is a good case for social network analysis centrality at work. A hockey game is a network where people pass a puck to and from each other over the course of 60 minutes. Each time the puck passes from one player to another, we can create a directed tie. We may also be able to make some statements about the game. For instance, is it more important to give or receive a pass from a diverse group of players? Who passes to the biggest passers? Who receives passes from them? Rather than going through all this preamble how about I just get to it?

The Roster

Maybe later I will add the last names, but right now I’m going with the numbers.  You can use this roster as a key to find your favourite players.

Team Canada

  • 02: Gary Bergman
  • 03: Pat Stapleton
  • 05: Brad Park (if it weren’t for Bobby Orr, the greatest defenseman of his era)
  • 06: Ron Ellis
  • 07: Phil Esposito (big goal scorer and captain of the team)
  • 08: Rod Gilbert
  • 10: Dennis Hull (Brother to Bobby)
  • 12: Yvon Cournoyer (The Roadrunner)
  • 17: Bill White
  • 18: Jean Ratelle (One of the great Rangers, amazing goal scorer)
  • 19: Paul Henderson (A very good player, but the hero of the series)
  • 20: Pete Mahovlic (Overshadowed by his brother Frank, but actually very good)
  • 22: J.P Parise (Great player, but got thrown out early for threatening to slash the refs)
  • 23: Serge Savard (Eventually became captain of the Habs)
  • 25: Guy Lapointe
  • 27: Frank Mahovlich (Big “M” – hero of the Toronto Maple Leafs)
  • 28: Bobby Clarke (was chosen last for the team, but brought the Broad Street Bully element to the game.)
  • 29: Ken Dryden

Team Russia

  •  02: Alexandre Gusev
  •  03: Vladimir Lutchenko
  • 06: Valeri Vasilev
  • 07: Gennadey Tsyganov
  • 08: Vladimir Vikulov
  • 09: Yuriy Blinov
  • 10: Alexander Maltsev
  • 12: Yevgeni Mishakov
  • 13: Boris Mikalov
  • 15: Alexander Yakushev
  • 16: Vladimir Petrov
  • 17: Valeri Kharlamov
  • 19: Vladimir Shadrin
  • 22: Vyacheslav Anisin
  • 25: Yuri Liapkin
  • 30: Alexander Volchkov
  • 20: Vladimir Tretiak

Getting the Data Using R’s iGraph Library

The data were created using edge lists separated by spaces. Here is a sample of what it looks like:

Off16 Can07 
Can07 Can23 
Can23 Rus26 
Rus26 Rus22 
Rus22 Can29 
Can29 Rus22 
Rus22 Rus26

A few things that may be added in the future are the times of the pass, goals, steals (although this could be calculated on its own), power-play information and so on. But for now, I just have the edge lists. The first entry is the “from” player (Rus=”Russia”, Can=”Canada” and Off=”Official / Referee”) and the second is the “to” player.  You can enter the information in to an R graph object pretty easily using iGraph. You can assign descriptive values to the hockey players (vertices) by using V(df)$description.  In this case, I’ve used color to easily identify the Russians from the Canadians in the graph plots (igraph will automatically plot the colors if there is a descriptor available).

library(igraph)
el <- read.csv("summitseries.txt", header=F, sep="") #sep="" means any whitespace
df <- graph.data.frame(el) # create a graph from the dataframe el

#Create a color vertex trait so that Russians are red; Canada is white and the Refs are black.
V(df)$color <- ifelse(substr(V(df)$name,1,3)=="Rus", 
               "red", ifelse(substr(V(df)$name,1,3)=="Can", "white", "black"))

Overall Degree

Degree refers to the number of different people a person passed/lost the puck to, or received/stole the puck from. It’s basically a count of the number of “sticks” for each ball.

The code to calculate the values is this:

V(df)$degree <- degree(df) 

Each player gets a value based on the total number of pucks received or sent.  To plot:

plot(df, vertex.size=V(df)$degree, layout=layout.kamada.kawaii)

This is what the graph looks like:

Screen Shot 2015-02-16 at 11.21.54 PM

This graph is not particularly meaningful, but it does offer a few insights. For instance, Phil Esposito (#7) was out a lot in this game and managed to both take passes away from the Russians as well as lose them. It kind of speaks to his garbage can approach to hockey – his play in this period, like most days was gritty and he found himself in the midst of almost every play. This also shows quite a bit of the classy Russian style of play with a lot of quick passes and fancy footwork. Almost every player on the Russian team had the puck quite a bit. Vladimir Shadrin (#19) is mostly ignored in the English world today, but he was amazing in this series, scoring more than even the Russian hero Valeri Kharlamov (#17) who barely shows up on the charts.

Out Degree

V(df)$outdegree <- degree(df, mode="out")

“Out” degree is the same measure, but only counting “outgoing” passes. These represent passes made or intercepted.

Screen Shot 2015-02-16 at 11.28.23 PM

Like I said earlier, Phil Esposito (#7) was finding himself giving the puck away quite a bit in this first period, but also making some pretty strong passes. Brad Park was also pretty busy. Both these guys happened to score goals in the period by the way. On the Russia side, Lutchenko (#3) and Yakushov (#15) are nothing particular special in the pass department even though they scored goals as well. That could be because the Russians were much more team players.

In Degree

V(df)$outdegree <- degree(df, mode="in")

Screen Shot 2015-02-16 at 11.51.10 PM

Not too much more to say about this one, except that it’s not too different from the outdegree measures. This is not that surprising given that if you have the puck either you are going to pass it or someone will steal it from you. I should also note that goalie Ken Dryden (#29) was pretty busy in this period. Not good for Canada.

Bonacich Power (Beta=0.5)

Now we can look at some eigenvector-like centrality measures. There are a variety of them, but I’ve decided to use Bonacich in this case. Bonacich uses a beta value that assigns a weight to the degree centrality of the neighbours. In the case of a positive value (cooperative networks), the more “passy” your neighbour, the more power you have. Unfortunately, this method produces both positive and negative values which is a little challenging for plotting.  So I have a little linear mapping function that I borrowed from here:

linMap <- function(x, from, to)
          (x - min(x)) / max(x - min(x)) * (to - from) + from

And then assign the values and plot.

V(df)$eigen <- bonpow(df, exp=0.5)
plot(df, vertex.size=linMap(V(df)$eigen, 0, 25)

Screen Shot 2015-02-17 at 12.16.15 AM

The picture is a little bit different in this case. Now we see the great New York Ranger, Jean Ratelle (#18) finding his way into the largest influencer position along with Bobby Clarke (#28). On the Russian side, Yakushev (#15), Karlamov (#17) & Mishakov (#12) find themselves in their rightful place as the elite members of their team. Phil Esposito, on the other hand shrinks to almost nothing.  Why? Well, he tends to find himself taking and losing the puck from defensive players more than picking up passes from his line-mates Yvon Cournoyer (#12) & Frank Mahovlich (#27).

Bonacich Power (Beta=-0.5)

V(df)$bonpow <- bonpow(df, exp=-0.5)
plot(df, vertex.size=linMap(V(df)$bonpow, 0, 25)

The picture is also quite different when looked at from a negative Bonacich power perspective. Usually negative bonacich power is used for networks that are competitive in nature, when it’s much better to have less powerful neighbours.Screen Shot 2015-02-17 at 12.17.12 AM

In this case, it’s pretty obvious that its the defensemen that have the least powerful as neighbours.  This makes sense because defensemen usually end up playing with a wider variety of forwards than other forwards do. Canada’s top defenseman, Brad Park, certainly found himself passing to and from the lesser lines in the first period, and likely stealing from Russia’s lesser lines as well!

Conclusion (for now)

This post goes to show that you can get a different answer from a social network analysis depending on how you decide to measure it. There are no mind-blowing revelations here (likely because the game was somewhat even at this stage) but still quite a bit of diversity among the different graphs that it gives pause. At the end of the day, this is why it is important to think clearly about your research question before you start looking at your data.  If you don’t, you’ll probably find yourself getting the answer you want just by rolling through different measures. I haven’t even gone through all the possibles – betweenness, closeness, clustering values and alpha centrality are all measures I’ve decided to leave out just for now (but may revisit later).

Another thing that might be interesting to look at is what the centrality values look like when I separate the Canadians from the Russians – from that perspective you could see how well the teams play with each other. Also, we could look at the edges where the puck changed hands from one team to another. In this case the negative bonacich power may be quite telling as per who was really coughing up the puck to the wrong people.

The data is not up in my git site yet, but I will share it eventually. I’ll keep the data open so that people can add or edit it as needs be. Certainly there may be problems with the way I coded everything. It was not always easy to see who was touching the puck. Sometimes I just had to guess based on position and the usual line-ups.

Advertisements

Six Ways to Do a Presentation

People get anxious about making presentations. There are ways to manage this anxiety, but part of the reason people have this anxiety is that they think there is a formula for a “good” presentation and that they have to somehow fit the mold of that formula. It’s kind of like trying to be a rock diva without the sequins or a tech guru without the black turtleneck and jeans.

Too bad for these people that they watch too much mainstream news.

The reality is that the “good” presentation format is only “good” because a whole bunch of people have packaged it into a brand of sorts. People who are not part of that club have to think of other ways to get their message across. If you are doing a presentation for the first time, chances are your audience is not everyone in the world. More likely, you have a smaller niche audience with more specific needs. That means you have to think about your presentations a little bit differently. While I can’t give you a strict idea about how to reach  your audience in the right way, I can offer ten ways you could do a presentation and see if this gives you an idea about how you might approach yours. Here they are:

Lecture with Script

When you have done a lot of research, it is easy to get nervous about the details. Do not try to explain a mathematical algorithm in the middle of a presentation. You will draw a blank. Instead look to a script. You do not need to follow it 100%, but scripting it can help you get through the details without making a mistake. Tanya Boza has some interesting things to say about being a good lecturer, but advises against using a script. Well, I say scripts have their place depending on the situation. Although Tanya is right – it is much better if you can use your script without looking as if that’s what you are doing.

ADVANTAGES: You can script the details. Will go off very well if you are a good writer. Tends to be formal, and usually rhetorical. Great if you are a politician or have to explain things in a very specific way so not to offend people.

DISADVANTAGES: Can be boring and/or un-engaging. You can lose personal contact with the audience if not rehearsed well. Can be over-prepared. Difficult to do ad hoc presenting within a script.

Lecture with Notes

If you are teaching a big picture concept without getting into the details, it may be better to go without a script. Instead, just quick notes will do you well. This is especially good if you have props to show, are teaching English, expect questions about the material. Johnathan Fields gives a great overview of how Martin Luther King used improvisation in his speech and changed the world.

ADVANTAGES: Great for an overview topic. People may feel more comfortable to ask questions. Good for abstract concepts that are hard to display visually. Excellent for people who like to perform and/or do improv. Can be especially good for a dramatic topic.

DISADVANTAGES: Tends to cover topics too generally. Information can be hard to retain if the lecture goes on too long. Can appear disorganized or unprepared, especially if people ask for details.

Power Point Presentation

Like it or not, the Power Point is a mainstay for presentations. I wish generally that we would not rely on it so much, but so be it. The key to remember is that power point should be a support and not a crutch. However, if you are so nervous about presenting that power point is your crutch, I have a few tips to offer you on the issue.

ADVANTAGES: Great for people with an eye for design. Visuals can really help support the topic if done properly. Easily shared on the Internet. Best option for sharing graphs and charts.

DISADVANTAGES: Waaaay over done. Gets tedious if the visuals are uninteresting; gets distracting if the visuals are overpowering. Appears “salesy” at times due to its prominence in the field of marketing. People ask you for your notes so they don’t have to watch the lecture.

Present Over Sound

It’s not often thought of, but it can be very effective to use sound to illustrate a point. This is the essence of podcasting, in fact, although sound does not have to be digital. If you have your own instrument, that can be even more fun. Take a look at Anna Russell explain Wagner’s Ring using music, for instance:

ADVANTAGES: It is not using powerpoint. Sound is a great way to describe emotions, tension etc. Obviously it is excellent for showing music. It’s an excellent way for musicians to show their talents while making an argument. Very effective with visuals, perhaps removing the need for a script or notes.

DISADVANTAGES: Requires a lot of preparation. Can be distracting to try and speak over a music set. Queues can be missed, causing awkward breaks in the performance.

Q&A

I once did a presentation by simply asking the same question in three different ways. This may seem lazy (and it is) but the reality is that the audience collectively often has much more information and knowledge than the person speaking.

ADVANTAGES: Almost no preparation required. You need an eye for facilitation to ensure as many voices as possible are heard. Crowd wisdom often brings amazing insights.

DISADVANTAGES: Need excellent questions. Always the threat of no one having any thoughts (although this is rare if you are patient). People looking for something unique will often be disappointed. Can come off as overly “new age” or maudlin. You need to be comfortable with a bit of awkward silence.

Structured Alternatives (AKA “Large Group Methods”)

There are a variety of presentation structures that can open the door to more audience participation. Fish Bowls, Talking Circles and World Cafe are some examples, although there can be many more.  These can range from very easy to facilitate (talking circle pretty much just needs a stick or other object to make happen) to very challenging (World Cafe is pretty complex to organize). Either way, they all represent different ways of providing something a little different from lecture-style.

ADVANTAGES: Can be very inspiring. Can open up some voices who otherwise would not want to speak out. Self-coordinating while happening.

DISADVANTAGES: The structures can be a little difficult to explain. Not everyone is free to be honest and open, so these styles can leave them vulnerable. There can be a “musical chairs” kind of effect, so you need to be comfortable with moments of chaos.

So here are six examples of alternative styles of presentations that you can offer your audience. Not everything has to be a power point! What kinds of presentations have you encountered that seemed just a little outside the box?

Part III: How Haskell Monads are Like a Muppet

< Part II: How not to Start Your Haskell Program Part: IV:  If This is a Case of Functional Programming, Then I Am Switching to Lazy Evaluation >

In previous tutorials, I talked about some assumptions about Haskell programming, and how to overcome them.    I suggested that someone coming from an imperative background (more than likely) is going to go about functional programming all wrong.     I fretted that no one creating documentation for Haskell seemed to notice this and that this was a problem for the future of Haskell and functional programming in general.

Non-academic coders want to make their programs *do* something as soon as they can.      Academic programmers are more fascinated by making their code solve complex problems.     Making Haskell do something is possible, but you’d never know it by reading through the documentation and most tutorials.    Here I will make our Haskell program actually do something, all the while giving an inkling about how state monads / MVars / IORefs work (without ever bothering to explain the math-ese behind them).    Again, I am assuming you’ve read and have been confused by at least one or two tutorials on the subject.

Because imperative programs rely on mutable variables (of which functional programming has none), programmers usually start by creating controls mechanisms (eg. an array in php) to prevent mean side effects from creeping in to their software.    Functional programming does not have side effects.    That’s good.   However, it also does not have the ability to store values inside a variable.    That’s bad.   That’s why I suggested starting with input and output and filling in the gaps.   Then I gave a sample:


main :: IO() main = do
                        x <- getChar
                        if x == 'q'  then putStrLn "Thanks for Playing"
                            else pmove x >> main  

move :: Char -> String
move a
    |  a == 'w'       = "UP!"
    |  a == 's'       = "DOWN!"
    |  a == 'a'       = "LEFT!"
    |  a == 'd'       = "RIGHT!"
    |  otherwise      = "HANG AROUND AND DO NOTHING!"  

pmove = print . move

So far, this program doesn’t do much more than a basic “Hello World!” program.     It accepts an input that get stored in x and based on that input it prints out a word.   Pretty disappointing.   What we want is the ability to change things.    What would be really nice is graph coordinates indicating a plot on a map, for instance.    Then we could establish our character’s position that could be displayed graphically and used to analyze the characters position against (say) a wall, or a monster.   Then the real fighting can begin.

Except you can’t really do that.    If you create a variable ‘place’ that contains a tuple (5, 5), it will always be (5, 5).   Your character is stuck in the quicksand!

You *can* create a function ‘up’ that will increase the ‘y’ value when your user presses ‘w’.    Maybe it’s something like this:

up :: (Int, Int) -> (Int, Int)

up x = (fst x, (snd x) + 1)

However, you are still stuck because you have no declaration of a starting point unless you declare a variable.    If you declare a variable, then your starting point is unchangeable, so you can only move one spot and no more!      This is where you start questioning if Haskell is just some practical joke that some prof wanted to play on his or her students.   In academic terms, this is the ‘problem of state’ and is one of the main reasons why functional programming has not had much influence in its first 30 years of being in existence.

To avoid a surprise ending, the solution is actually to create an MVar, which means ‘mutable variable’ and can be found in the Control.Concurrent.MVar module.    But I am getting ahead of myself.   An MVar isn’t exactly a mutable variable, although it does a really good job at pretending it is one.   Let me use some of my mad working-with-kids librarian skillz to show you how it works.

Grover is a Monad

Since you are somewhat familiar with the Haskell tutorials, you know what a monad is.    You are also a little bit confused at how it works.   I am not going to explain it.   It’s too mathy.    Much better to talk in Muppets.     I like to read a book called Grover’s own alphabet to my kids.     In it, Grover moves his arms and legs around to shape himself into all of the letters of the alphabet.     Believe it or not, this is your solution to the mutable variable problem.

As discussed, I cannot create a function that will store a value in a variable that can be changed later.    However, I can ask a function to return a type.    I can call this type “Grover.”     So, if I’m looking for a letter of the alphabet, I can ask Grover to move his arms and legs so that he is in the shape of a letter, let’s say “G.”    He will stay in “G” until I ask what shape he’s in.     Once he says “I am in shape G”, then he will stand up straight (no shape) until I ask him to take another shape.   This is basically how Monads (more specifically, state monads) work.

(Incidentally, the idea of using Monsters as an example of the Monad type is not new.)

Now is the hard part – going through the documentation.     I am going to save you alot of time.   For our Rogue-like game, we need MVars.    Before figuring this out, I had to go through a whole lot of confusing reading and mess.     If you want some pain and suffering, look up the State Monad, State Transformers, IORef, Arrow notation and the like.    Now look at what you really need.   MVars.    Go ahead and read the documentation on that.   You’ll find out that MVars are used for supporting concurrent processes.    Then you’ll go back to IORefs because this isn’t a concurrent program.    That’s a pointless exercise – IORefs are unnecessary.    And, hey – maybe our Rogue-like game will need to be an MMORPG down the line, who knows?

Here is the code.      I will go through it in more detail in the next tutorial later, but basically this program will start with x = 0 & y = 0, and output a location or a message depending on what you hit on the keyboard.     Note, however, at this stage that you’ll need to hit ctrl-z to make the program stop.



import Control.Concurrent.MVar
import Control.Monad

main = do
           x <- newEmptyMVar
           y <- newEmptyMVar
           putMVar y 0
           putMVar x 0
           forever (do
                    char <- getChar
                    if char == 'q' then putStrLn "Thanks for Playing!"
                        else if char == 'w' then up y >> output x >> output y
                        else if char == 's' then down y >> output x >> output y
                        else if char == 'a' then down x >> output x >> output y
                        else if char == 'd' then up x >> output x >> output y
                        else putStrLn "you did not type a correct entry")

up, down, output :: MVar Int -> IO()
up y =  do
             v <- takeMVar y
             putMVar y (v + 1)

down y = do
             v <- takeMVar y
             putMVar y (v - 1)

output y = do
             g <- takeMVar y
             putMVar y g
             putStrLn (show g)


It’s not the prettiest code in the world, but that’s how you have to do it with Haskell.   Start out ugly, and make it pretty as you go along.

Part II: How not to Start Your Haskell Program

< Part I: Is There a Such a Thing as ‘Real World’ Haskell? Part: III   How Haskell Monads are Like a Muppet >

My last Haskell post had me thinking that I might as well create a really bad tutorial outlining my own strategies to deal with Haskell in the real world.    Some of the issues I outlined were:

  • Tutorials for Haskell focussed on solving problems, rather than getting it to ‘do stuff’ which is what alot of users expect from their computer software.
  • Haskell is emerging as an important player in the future of code.   Both as a type of code itself and as a way of improving skills in such languages as Java and Python.   However, it will not make the mainstream unless ‘regular folk’ start using it.
  • Functional programs (in theory) are apt to be more sustainable, less buggy and more consistently documented.   Regular folk, working with imperative and/or objective and pseudo objective languages probably don’t realize this -> not until their code breaks and they have to re-install the wheel.

While I have some experience in other languages like Ruby, and Python, I’ve decided to approach Haskell as if I were a PHP developer instead.     There are some very good reasons for this:

  • PHP is a ‘do something’ language.    Basically, it takes dynamic data and outputs it to a web page.   While math problems and recursion-like methods are possible – it’s usually input and output (ie. taking data in and out of a MySQL database) that is the most important.    Anyone expecting to use Haskell for primarily I/O related stuff is going to die from frustration.
  • PHP code can get very messy, even in the hands of an experienced coder.   Documentation of code is all dependent on comments and external manuals.     Haskell can help your average PHP coder, because its type-system offers a kind of in-source documentation.
  • PHP is a ‘regular peoples’ code.    It is adopted by alot of people with varying skills and experience with computer software, many of whom have very little understanding of its long run limitations.
  • Well into its 5th release, alot of the work has already been done for your average PHP coder.       It’s almost not even necessary to create your own objects and functions with all the pre-created libraries available.     Unfortunately, it’s also widely assumed that you are going to create a web application ->  what if you want to turn your code into an App?    or a desktop application that uses data from a php created api?   or an intense web universe ala Second Life or World of WarCraft?
  • As an interpreted program,   it’s pretty simple to solve problems through trial and error.    Just keep hacking away at php, and eventually you can make some convoluted function do what you want it to do (in an unscalable way, of course).

I am also going to make a number of assumptions:

  1. That you have read through at least some of the Haskell Wikibook.    I do not intend to explain what a Monad is, or impress everyone with my knowledge of complex mathematical theory.    This tutorial is an inquiry about how to approach a Haskell applications, not learning Haskell itself.
  2. You have a fair knowledge of some imperative-style computer language (possibly PHP).

As suggested, I am going to look at developing a one-level ‘rogue-like’ RPG game.      If I were to start such a game in php, I might start with something like:

$playerChar = array ("name" => 'Bob', "class" => 'fighter', "STR" => '18', "DEX" => '14', "WIS" => '11', "INT" => '15');

I suggest this because PHP coders want to get to the action as fast as possible.   The PHP coder (let’s call her PHiP) will know that her first problem is making data output in some consistent manner, so will create a variable that mimics a possible set of data that will eventually be displayed to the screen (likely a webpage).   Knowing that things like the name and class of the character will change, PHiP will put some variables inside the array.    Then PHiP will include some other ideas about what a character will need, and a print_r statement to watch the action as she lashes out blindly for the right outputs:

$playerChar ['traits'] = ("name" => $name, "class" => $class ...); $playerChar ['equip'] = ("weapon" => $weapon, "armour" => $armour ...); print_r ($playerChar);

If you are a Haskell coder, you probably already see countless disasters in store for PHiP if she uses this approach with Haskell.    Here are a few:

  • variables in Haskell are always constant.     Once called, the values will not change.   Believe it or not, functional programmers will see this as a good thing (see side effects in Wikipedia).
  • playerChar [‘traits’] would be seen as a function with an input [‘traits’] that, using Haskell syntax, is a list containing one string value ‘traits’.   Haskell would be wondering what to do if it encountered other lists containing one or more other string value(s).
  • All of the variables inside the associative array $playerChar  are irrelevant in Haskell.  Unless they are constant.
  • Deciding what to do with the array would be overwhelming.    A list could be used, but would require that all values inside be strings.   Or it could be a huge tuple of various kinds of values, or a list of tuples.
  • Without being sure what types of values are needed to create the playerChar, there are almost sure to be problems letting PHiP’s player character switch its weapon from a sword to a mace and back.

In short, PHiP is using the wrong paradigm to code effectively in Haskell.    The issue is not a problem of syntax, or even understanding a problem.   The issue is the approach.

As the tutorial goes along, we will deal with PHiP’s player character.    But, to work in Haskell, I propose that you do not start with the data you want to put in and out.    Instead, you start with input and output itself – inside main – like this:

main :: IO() main = do x <- getChar if x == 'q' then putStrLn "Thanks for Playing" else pmove x >> main move :: Char -> String move a |  a == 'w'       = "UP!" |  a == 's'       = "DOWN!" |  a == 'a'       = "LEFT!" |  a == 'd'       = "RIGHT!" |  otherwise      = "HANG AROUND AND DO NOTHING!" pmove = print . move

Right now, this code is pretty useless, but it offers a few nice things to help make sure you don’t lose steam in your coding.

  • It creates an output that will work (sort of) like PHiP’s print_r string.
  • It offers a practical demonstration of point notation, which, in laymen’s terms creates a function pmove that prints (using print) the results of move.    Essentially, it keeps me from having to write “print (move x)” all the time.
  • I accepts an input ‘a’ that is a character.
  • It creates a strongly typed function ‘move’ that takes a Character and returns a String.   As we move forward, we can chain a series of functions together that will help PHiPs make her Haskell program to do more interesting things such as fight a monster.

(as it turns out, this code works slightly differently in Windows than it does in Linux.    Use the Linux version, because it makes me seem a little more competent.   If anyone can explain why Windows wants the CR for the getChar command, please  add it to the comments.)

I am not absolutely sure this is the very best approach to a rogue-like game, but I can guarantee it is better to start this way than it is to begin with creating variables.     As you read this tutorial, I hope you continue to use other documentations elsewhere to help you get your mind around my use of ‘do’, ‘getChar’, ‘putStrLn’ and guards ‘|’ here (pretty rudimentary Haskell code right now).

The next tutorial will look at shaping our dungeon and establishing where our player as he or she moves across the board.

Incidentally, as of writing this, I am working on a rogue-like game with my son called Rasghiosse (my son named it).    I have a public Darcs repository on Patch-Tag that you are free to join in on if you like.   As of writing this tutorial, I am not much further ahead than the above code, so I would appreciate your help.

Why “The Clash City Rockers” is a Well-formed Song

UPDATE:

It seems that I converted Mick Jones to librarianship after this video.    (Yeah, that’s the ticket.)   Actually, he really just opened up his own collection to the public library.   Bottom line is, Mick understands the importance of making knowledge of all kinds and formats available to the public.   Thanks Mick!

(July 3, 2009)

A long time ago, I used to be a Tutorial Assistant for a Listening to Music course put on by Adrian Hoffman.   Usually at the time when we discussed the “Classical Era” (ie. Mozart, Haydn, early Beethoven) there was a lecture on form.   Often, form was expressed as a tool for absolute music (ie. how to give a song a structured feel to it).    I always itched at doing a lecture on how form can impact program music (music that tells a story or paints a picture) – and especially I wanted to do this lecture using a piece of popular music.

So I did an explanation of form using “The Clash City Rockers” by The Clash.   I should note that I believe that the brief samples I use here qualify under fair use policies, in particular because I am using them in a tutorial about music, adding considerable amount of my own knowledge and material in the process.    Got any other good examples of how the form of a rock song really suits the lyrics/content well?

UPDATE:

You can go through all the verses of the song and perform the same exercise, actually.     Third verse has “everybody gone dry” on the “down” section” and “plug into the aerials that poke in the sky” in the “up” section (sky/up works really well, don’t it?).    Then, the suburbs are down, and the “you won’t succeed unless you try” get the up.   Very simple “up-down” technique that does alot to help the song makes sense.   I’m always impressed when I see this amount of craft put into a song.

UPDATE July 5, 2009

Just watched this with my wife and must admit that the front needs considerable editing.   (yeah, I’m babbling alot about whatever and whatnot – I think I couldn’t decide whether this was a video blog post or a tutorial on music).

Skip to about 1:30 to get to the fun part (where I use the “W” to show how the song is well-formed).   I’m going to spend some time editing this down shortly and I’ll repost it.

Doing a 15 Minute Presentation in 10 Easy Steps

Thanks Formication!Presentations are not easy to do well even if you are a designer or professional speaker.   Understanding your audience, having a catchy topic, being loud enough to be heard are all things that require practice.    Designers and professional speakers have the bonus of experience (and pre-set slides) on their side – you probably do not have any of the above.

After the Computers in Libraries conference, I got to see all kinds of styles of presentation.   There is one style that always stands out, no matter what.   I like to call it the “Scatter-Drone.”   That is the presentation that has 50 bullet points scattered on every slide with a long-winded drone of a voice wavering in the air saying something, but nobody really knows what because catatonia has already taken over.

 

There are simple things you can do to prevent being a total bomb in your presentation, though.   Here is one step-by-step process you can use to create a half-decent 15 minute presentation out of your typical Scatter-Drone.

What Do You Have to Say?

  1. Create 12 blank slides using your favorite presentation software.   
  2. The last slide should say “questions” or have a nice question mark graphic on it.
  3. The second slide should provide an agenda consisting of three sections.   Nice if you can offer a “promise” – something that you can assure will be worth taking away from your presentation.
  4. The third slide will offer three “big picture” points — you will repeat these things three times throughout your presentation.
  5. Fill in the rest of the slides with as many bullet points as you want.

How Will Your Audience Understand You?

 

  1. Print off your presentation as is.   Yes, it does stink right now – now you must fix it for your audience.
  2. Think of a single word or phrase that describes each slide (remember, each probably has 5-6 bullet points).   Go to Flickr’s Creative Commons and use that word or phrase to find a picture that will suit the bullet points you have on your slide.   Replace the bullet points with your nice picture.   As you put your pictures onto the slides, take a look at how other people do their presentations and adapt accordingly.   I appreciate that you are not a designer – but grab some ideas from people who are.
  3. Use the original presentation print-off (the one with all the bullet points) as your notes and the slide show with the pictures is what your audience will see.   Now you can just “read your slides” without anyone ever knowing that that’s what you are doing.

 

Feeling Confident and Prepared

 

  1. Start by acquainting yourself with the audience somehow.   Poll them.   Ask them what they expect from you.   Crack a joke to test their level of seriousness.   Maybe even throw them a bit, by offering an alternative presentation style.
  2. Give yourself an idea of where you are going to repeat your three key messages.    You should do this somewhere in the middle (slide 7 or 8) and again near the end (10 or 11).

 

That’s it.   A generic procedure for creating a half-decent presenation if you are not a designer or professional speaker.    It’s not too difficult to get a passing grade from your audience.   Remember, the audience *wants* you to present well and share your ideas in a meaningful way.   It just takes a bit of preparation, and some way of getting feedback from your audience.