Dependent Sample Assessment Plots (DSAP) constitutute a way of visualizing data from pre-intervention and post-intervention sources in order to determine whether the intervention likely influenced any changes.

Suppose you’re an educator and you administer an assessment to students at the beginning of a unit asking about their level of confidence or understanding of a topic. You then teach a lesson that spans some period of time. At the end you collect responses to the same questions again. You now have a dependent sample: two responses that related to the same individual for some number of individuals.

For such a small sample, you can quickly eye-ball the raw data and see that there seems to have been an upward shift in scores, but is it significant (in the statistical sense)? Could you so easily eye-ball the results for a class of 20, 30, or 100 students? Probably not.

Data visualization is an attempt to reveal patterns in data by converting it from raw numbers to graphic images where we can more easily discern clusters (small groups of students who exhibit similar score patterns), outliers (unusually high or low scores), and effects of treatments (did the instruction result in learning?).

An assessment plot is simply a specialized scatter plot showing the pairs of values as (x, y) coordinates. When we enhance the scatter plot a little, we can gain quick insight into patterns in our data. Consider the following Dependent Sample Assessment Plots:

The plot has several features worth mentioning:

• The x-axis and y-axis use the same range (they’re on the same scale), so the plot is square.
• I’ve plotted post-assessment scores along the x-axis so that the mean difference will be positive for increases in post-scores and negative for decreases in post-scores.
• The solid black line running from the lower-left to the upper-right represents x and y values that are the same (10, 10), (20, 20), and so on; this is called the identity line. Therefore, if there was no change between the pre- and post-assessment, we would expect the points to appear along this 45 degree line.
• Any points below this line represents a positive change (scores increased from the pre- to post-assessment).
• Any points above this line represents a negative change (scores decreased from the pre- to post-assessment).
• The horizontal, thinly-dashed red line represents the pre-assessment mean; here, about 29.
• The vertical, thinly-dashed red line represents the post-assessment mean; here, about 44.
• The thick, dashed red line running diagonally is the mean of the difference between pre- and post-assessment scores (the difference mean); here, 14.8, i.e., post-assessment scores were 14.8 points higher than pre-assessment scores, on average.
• The green bar indicates the 95% confidence interval: the range of values for the population mean difference that are reasonable, in light of these data. Technically, this is the range of values that would not lead to rejection for alpha = 0.05.
• If the green bar includes the identity line, then any observed difference is not statistically significant.
• Conversely, if the green bar does not include the identity line, then any observed difference is statistically significant.

This simple visualization offers us much information quickly and scales well to samples of moderate class sizes. (See the 40-student example, below.)

Free software is available to help us generate these graphs with just a little effort on our part. R, a statistical programming environment, is available for download for Windows, Macintosh, or Linux operating systems and offers a wealth of data management, analysis, and visualization tools. Here I’ll focus on only one such tool: granova.

Granova is an abbreviation for Graphical Analysis of Variance and is a package available (also for free) for use in R written by Bob Pruzek and Jim Helmreich. In fact, the above plot was generated using granova.

In order to install and use R and granova to produce this plot, you would

1. Download R
2. Install R per your operating system’s usual process
3. Mac Users will also need to download and install tcl/tk
4. Launch R
5. Type the following commands within R

• install.packages("granova", dep=TRUE)

• library(granova)

• x <- cbind(post=c(45, 30, 53, 55, 40), pre=c(22, 33, 35, 32, 27))

• granova.ds(x)

In the future, to run your own analysis using your own pre- and post-assessment data, you would simply

1. Launch R
2. Type the following commands within R

• library(granova)

• x <- cbind(post=c(45, 30, 53, 55, 40), pre=c(22, 33, 35, 32, 27))

• granova.ds(x)

replacing the numbers on the line beginning with

x <- 

with your own pre- and post-assessment scores. It's important that the two lists of numbers are in matched order. That is, 22 and 45 are scores for the first student, 33 and 30 are scores for the second student, and so on. Also, notice that I've entered post-assessment scores, first, so that the post-scores will appear on the x-axis.

In closing, consider the data below: 40 pairs of scores in both raw numeric and granova format. Can you eye-ball any trends from the raw data? What about based on the plot?

For more examples on how these types of enhanced scatter plots can be used, see Pruzek and Helmreich's paper in the Journal of Statistics Education Volume 17, Number 1 (2009), Enhancing Dependent Sample Analyses Using Graphics.

Pre	Post
21.72	50.68
33.26	36.39
20.41	51.55
26.06	36.26
33.62	32.18
27.16	20.13
30.38	27.90
28.84	59.17
33.00	34.18
36.36	41.76
30.36	48.92
33.16	35.80
31.42	43.73
39.90	40.53
29.90	52.50
35.42	34.67
29.14	38.33
22.31	29.02
27.96	41.19
24.42	57.77
23.65	28.68
26.94	26.31
35.09	23.09
38.29	53.75
39.09	50.23
30.21	23.43
24.78	35.14
34.26	54.71
31.64	20.91
31.41	27.45
23.84	48.05
36.11	25.58
37.45	59.60
29.38	56.05
39.72	51.28
29.82	36.91
31.82	21.71
24.82	23.96
37.80	49.52
38.45	56.68

I love Apple’s design aesthetic. I see it in the simplicity of their physical and software UIs, although usually not in the baroque nature of their business processes. What frustrates me is the lack of parity among the Apple-born technologies. I don’t just want a good experience on one device, I want it on, between, and among all my Apple devices!

Case in point, a few years ago I submitted a note to Apple suggesting that they had missed the boat by not having the iPhone earphone controller/mic work on their notebook line, too. That is, I wanted to be able to iChat using the iPhone earbuds as my earphones and microphone. Sure enough, the latest MacBook Pro models have that feature. I’m not saying it was me! I’m sure many people had a similar idea, and told Apple about it, and I’m thankful for it. What I am asking is, why didn’t Apple notice it? Are their development efforts so siloed or their release cycles so offset from one another that it’s not possible?

Another, current, case in point: the push for ebooks. I have my iPad (thank you, Steve!) and I loaded iBooks on it. I like it. I like the upgrade even more. And there are more features I expect will come soon. However, it’s frustrating to not have iBooks parity between the iPad (/iPhone/iPod touch) and iTunes on my MacBook.

• on the iPad, I can’t easily manage my collection (gather new books, other than from the iBookstore, (and that’s yet another frustration!), although it’s slowly getting better with the “open in…” capability.
• on my MacBook, in iTunes, I can’t read the ebooks I’ve collected.

Or the jumble that passes for document management in iWorks for the iPad, or for the Notes app on the original iPhone, or… or…

If Apple truly wants devices like the iPad to be devices for everyone, then the user experience on different Apple devices really needs to be in parity from day-zero.

Don’t make me think twice.

The Problem: Create a basic 1970s style Pong game for one player using the Processing programming language. The paddle will be on the right and the ball will bounce off of the three other sides. If the ball passes the paddle while the ball is traveling to the right, game play ends. The paddle will be controlled by the keyboard’s UP and DOWN arrow keys.

The purpose of this article is to present my problem solving process as I create Pong. I’m going to deliberately walk through the process as a novice programmer might. Students rarely get to see how their instructors think through a problem, unless the instructor live-codes in front of them. But, even then, students are confused by the changing dynamics of the solution as the instructor begins to understand the problem better and refactors his or her code in real-time.

First, let me make sure I understand the problem space. A quick diagram often helps:

• There’s a playing field of some unspecified dimensions
• there’s a ball (a circle)

Ok, that seems like a good start. Now, let me do the simplest thing that can possibly work to represent what I know about the game. In Processing, there’s a standard skeleton for basic programs:

Now, let me create the playing field (window) in the setup method and create a ball (circle or ellipse) in the draw method. The Processing reference manual tells me that when drawing an ellipse, the default drawing mode assumes that the ellipse method takes four arguments: x and y coordinates for the center of the ellipse and width and height values for the horizontal and vertical diameters of the ellipse.

Further, the setup method is executed just once, before the program gets started. The draw method is an implicit loop in Processing; it gets called many times per second to redraw the window.

If I run my code, I get a 400 by 400 pixel window and a circle located at (20,20) that is 20 pixels wide and 20 pixels high, but so far, it just sits there.

• the ball moves from left to right

Well, that implies that the x and y coordinates of the ellipse need to vary, so I’m going to need to refactor my code to use variables for the x and y coordinates of the ball. When I refactor, I want to reorganize my code, but not change the functionality: the code should be organized better, but the program should do the same thing. I like to use obvious variable names, so my code is easy to read and understand, so I’ll use “ballX” and “ballY”. (nota bene: when you find yourself prefixing variable names with the name of objects you’re manipulating, it suggests strongly that you should consider object-oriented design/programming.)

I run my code again, and indeed it behaves exactly the same as it did before the refactor. Now, I’ll add the least code I can to get the ball to move from left to right a little bit each time it’s drawn. It’s often difficult for novices to break down a task like “move the ball to the right side of the screen” into the smaller, discrete steps necessary to get the task done. The key, I think, is to think of a loop (in this case, the implicit loop of the draw method) like a flipbook animation from your childhood. You’re not going to just magically have the ball appear at the right edge of the window. Instead, you’re going to move the ball just a little toward the right edge each time it’s drawn.

It’s probably best for me to think about how much of a change I want ballX to undergo during each drawing cycle. It’s customary to refer to a small change in x as “dX”, the “delta x” or “change in x” value. Since x represents the number of pixels from the left edge of the window, adding just 2 pixels to the ball’s location each time it is drawn should have a smooth animation effect. So, I’ll set the initial value of dX to 2 and add dX to ballX each time the draw method is executed.

When I run my code, the ball moves!! Not well, but… it moves! Each drawing of the ball is being left on the playing field. In Processing, to start each drawing cycle with a clean window, you set the background of the window. Here, I’ll set it to a solid color using the RGB color model: (255, 255, 255), which is the value I want for red, green, and blue components of the color. Setting them all to 255 causes the background to be white.

When I re-run it, the ball now moves cleanly… and keeps moving, right off the right side of the window. I want to add code that says that if the ball reaches the right side of the window, it should move back the other way. That’s not ultimately how game play will work, but I want to be able to see the ball moving around successfully, before I worry about how the game ends. I know that in this particular case, the right side of the window is at x coordinate 400, because that’s how big I made the window in the setup method. So, if the ball’s x position reaches (or passes) 400 pixels, I’ll reverse the direction of the change (dX). If a dX value of 2 moves the ball 2 pixels to the right, then a dX value of -2 would move the ball 2 pixels to the left. So all I should need to do is change the sign of dX (lines 13-15). Notice that I’ve added a comment at line 14 using the // notation. Generally, comments should describe why you’re writing the code, not how; the code itself tells me how.

If I run the code, I get a ball that bounces off of the right side of the window, then disappears off the left side!

• the ball bounces when it hits the left of the playing field

Well, I know that the left side of the window is at x coordinate 0 (zero), so I can repeat my code that handles bouncing on the right side (lines 13-15) and change it a little to handle bouncing on the left side of the window.

This seems to give me the bouncing ball I want, but I’m bothered by the magic number 400 I’ve used at line 13. In general, I won’t know how wide or high the playing field window is. I need to use a variable that represents the width of the window and, fortunately, Processing provides such a variable for me already: width.

So far, I’ve only addressed the ball’s movement left and right. It doesn’t move up and down at all. Let me write a few lines of code (lines 4 and 23, below) just the way I’ve handled dX and create a dY variable that behaves similarly.

Well that seems OK… the ball bounces from the upper-left corner to the lower-right corner, but it’s not very interesting. Let me spice things up a little by changing the magic numbers I’ve used for dX and dY to random numbers in the range [+1..+2] at lines 3 and 4.

When I run it a few times, I notice that the ball works well, if it happens to reach the right and left sides of the window, but when it reaches the top or bottom of the window, it disappears. I can add two additional if statements similar to the two I already have, but this time they’ll work with the variables ballY and dY. Also, the new code (lines 22-28, below) doesn’t need to know about the width of the window, but it does need to know about the height of the window and, again, Processing provides us with a convenient variable named height.

• the ball bounces when it hits the top of the playing field
• the ball bounces when it hits the bottom of the playing field

Alright, now that the ball seems to be moving around well, I’ll turn my attention to the paddle.

• there’s a paddle (a rectangle) near the right of the playing field

I’m going to make some assumptions about the placement of the paddle. First, it won’t be touching the right side of the window. Second, it will be 10 pixels wide and 30 pixels tall. I’m also placing it arbitrarily 10 pixels from the top of the window. I’m pulling these numbers out of thin air (they’re magic numbers), so I may well need to change them or replace them with variables later.

So, now I have an unmoving, inert paddle! Well, it’s progress… I’ll deal with the movement of the paddle, first. I know that I want to change the vertical position of the paddle, which is its y coordinate. So far, the position of the paddle has been hard coded with the magic number 10 (in line 14, above). I’ll need to refactor that into a variable, since its value will change over time, much like ballX and ballY. I’ll call it paddleY, to be consistent and obvious.

To be completely consistent, I’d like to replace my magic use of “width – 15″ (line 15, above) with a variable (line 17, below), too. It’s the x coordinate of the paddle, so I’ll create a paddleX variable, just like the paddleY variable. I’m going to run into one problem, though. The variables I define (lines 1-6, below) are declared and initialized before the setup method executes. That means that the size of the window hasn’t been set yet (line 8), so I can’t initialize the value of paddleX, since it’s determined relative to the width of the window. I can only declare my intention to use it (line 5). Later, after the size of the window has been set (line 9), then I can initialize the value of paddleY (line 10) and replace my magic number with the variable (line 17).

• the paddle can move up and down using the keyboard’s UP and DOWN arrow keys as input

Let’s deal with the problem of having the paddle respond to key presses, now. I do a quick search of the Processing Reference web pages and find some example code for the keyCode property that is close to what I want to do.

In their example, pressing the arrow keys results in a changed fill color (lines 10-14, above). For my pong game, I want the arrow keys to change the value of paddleY, the paddle’s vertical position. The variables, draw method (1-6), and else statement (lines 11-13) from the example are irrelevant to my pong game.

As a programmer I often need to find examples of how a task is performed in a given language, and then modify the example to match my circumstances better. When I do that, it’s good practice to add a comment explaining where I got the original code and acknowledging that it’s not my original creation. First, it provides me and other programmers with a road map, if I or they ever need to maintain the program I’ve written. Second, it makes clear which parts of the code are my original creation and which I’ve borrowed from other sources. If I were writing an English essay, I would use quotation marks and proper citations. When writing code, I add comments and provide URLs, email addresses, etc. to cite my sources.

I have once again put in some magic numbers: 30 at lines 17, 43, and 45, above. It’s the paddle height, but that’s not obvious from the code. So, let me refactor that to a variable.

Now that we have a paddle, we want to reconsider when the ball should bounce on the right side of our window. As the code is written, it bounces with it reaches the edge of the window itself, but we want it to bounce when it reaches the left-hand face of the paddle, which is located along a vertical line located at paddleX. I’ve updated line 20, below.

But that’s not the end of the story. As it’s written, the ball will bounce when it reaches the invisible vertical line, even if it isn’t touching the face of the paddle.

• the ball bounces when it hits the paddle (approaching from the left)

So, we need to update line 20 so that we check not only the horizontal position of the ball (which we’ve been doing all along), but also the vertical position of the ball with respect to the vertical position of the paddle.

I’m getting nervous about the complexity of the logic on line 20; other programmers (including my future self!) may not understand what my intention was in writing that code. In fact, I haven’t really given a name to what it is I’m trying to do on that line! A large part of programming is communication. As a programmer, I’m trying to communicate my intentions not only to the computer, so that it can execute them, but also to other programmers who may read my code. I’ve tried to create a domain specific set of variable names (ballX, ballY, dX, dY, paddleX, paddlyY, and paddleH) to make my code more readable by humans. If I only cared about the computer understanding my code, I could just as easily have used bX and bY or iLoveRockAndRollX and iLoveRockAndRollY. But humans (me, my instructors, my students, my friends, my future employers) need to read the code, too, so I’d like to make it as understandable as possible.

With that in mind, I’m going to extract the logic from line 20 into its own method with a method name that makes my intentions clear(er). My new method will return a boolean value (either true or false) depending on whether there has been a collision.

The collision method, so far, is still not transparent to the casual reader. I’d like to refactor the code within that method to make my intentions clearer.

That refactoring has revealed a problem with my thinking. So far, I’ve been testing only that the ball is to the right of the left-hand face of the paddle. If the ball somehow managed to get BETWEEN the right edge of the window and the paddle, it would still count as a collision and the ball would start back toward the left. I’ve noticed this because my testing of the horizontal position of the ball at line 42 isn’t parallel to my testing of the vertical position of the ball at line 43. In other words, I’m testing that the ball is between the top and bottom of the paddle, but I’m only testing that it’s to the right of the left-most side of the paddle.

In order to fix this, I need to know how wide the paddle is. Unfortunately, I’ve left that as a magic number (10) at line 18, until now. I’ll extract that to a variable (paddleW) and update my collision method to incorporate that at line 43.

Finally, I want to end the game, if the player missed the paddle.

• the game ends when the ball reaches the right of the playing field

I notice that, if the ball’s x coordinate is greater than the window’s width, then the ball must have passed by the paddle, so the game should end. There are other possible conditions you might use, but this one seems simple and obvious, at the moment.

I have also noticed that by using the ball’s x and y coordinates in my collision method, and leaving the default ellipse drawing mode set to CENTER, it’s actually the center point of the ball that I’m using as the hot spot (have you hit the wall? have you hit the paddle?) when I should probably be using the ball’s left-, right-, top-, and bottom-most points as the hot spots.

In order to be able to compute the left-, right-, top-, and bottom-most points of the ball, I’m going to need to know the radius of the ball (or, equivalantly the diameter). Unfortuneately, I again left that as a magic number (line 16, above), so I’ll first need to refactor that and extract the radius to a variable (lines 3, 18).

Now, I can add methods that compute the bounds of the ball on demand (lines 58-72).

It’s usually good practice when refactoring to only change one thing at a time (i.e., only add one new method, only change one variable name, etc.) and then retest your code. That way, you limit the range of mistakes, typos, logic errors, etc. that you might make at any one time.

So, I’ll begin by finding all the lines of code that I intended to refer to the right-most point of the ball. It seems that lines 22 and 50 should be my targets.

Now, I’ll find all the lines of code that I intended to refer to the left-most point of the ball. It seems that lines 32 and 50 should be my targets.

Test my code to confirm it’s still functioning, and then I’ll find all the lines of code that I intended to refer to the top-most point of the ball. It seems that lines 40 and 51 should be my targets.

Test my code once more to confirm it’s still functioning, and then I’ll find all the lines of code that I intended to refer to the bottom-most point of the ball. It seems that lines 36 and 51 should be my targets.

There are additional features I’d like to add (the ability to reset the game or to use mouse input, for example) and refactorings I’d like to make (turn this into an object oriented program), but this is a working, playable game at this point that solves the problem, as stated. A well-trained programmer will no doubt be appalled at the coding style, but I’ve intentionally tried not to use shorthand notations or to introduce solutions or idioms that would be unfamiliar to the novice programmer.

The fact that I have multiple methods (setup, draw, keyPressed, and now collision) that are all accessing the same variables raises a serious concern for me as does my use of special methods to handle pseudo-properties of the ball (ballTop, ballBottom, ballLeft, ballRight). How can I hope to keep track of where variables are used and modified? I’m making my code difficult to maintain and understand by using instance variables all over the place. A better solution would be to use object-oriented programming techniques so that I can encapsulate the variables and behaviors related to the ball within an object (perhaps named Ball) and encapsulate the variables and behaviors related to the paddle within another object (named Paddle). I’m going to set aside my misgivings for now and leave the refactoring of this code into an object-oriented structure for another blog post.

Recently, several students commented that I seemed to have a lot of classroom rules. This is an old refrain in my life, and, in a sense, it’s true. However, the rules I have are all just special cases of my basic three rules, which I share on my About Me page.

1. If you are going to break the rules, don’t be obnoxious about it.
• If you can’t be engaged, don’t distract others. It’s unfair to both you and them.
2. Don’t disappoint me.
• Don’t promise to focus, but fail to do so. Instead, acknowledge whatever is distracting you and address it.
3. Be aware.
• Know what questions your classmates are asking.
• Recognize which questions are related to tweaking the solution and which are related to a different problem context.

A full sized version of my rules diagram

I think my biggest failing in the classroom is that I’m uneven in the application of the rules, which is perceived as me being arbitrary. Inconsistency and randomness seem very similar to the outside observer.

I sometimes let feature creep take over the problem statement, which can lead to unintentional complexity or student confusion as the problem changes. I need to spend more time up front specifying the problem completely with students so that it’s clear to them and me what the invariants are.

I also find it difficult to ask a student actually to leave the classroom. I’m forever optimistic that the unfocused student will find moments of clarity and engage with the course material. Often, they do, but unfortunately, while I’m waiting for that to happen, the class as a whole is affected and, generally, material isn’t covered as concisely, clearly, or completely as might have been the case otherwise, thereby disadvantaging the other students who could have gone further, faster. Such is the nature of a set of random people with diverse metacognitive skills and needs. Still, I’m certain that I could serve better both ends of the spectrum.

I’d like to give a brief overview of computational efficiency, since it’s a topic that has come up in a few conversations recently. The super short version is this: it’s often helpful to understand the resource (time, space, or power) needs for a given algorithm. Why? Because we want the fastest algorithm, or the one that uses the least amount of storage on our hard drive. In extreme computing environments (think Mars Rover, Apollo capsules, etc), we many have very limited resources available. For example, your digital wrist watch almost certainly has more memory than the Apollo capsules, which only had about 32KB of RAM. How can you possibly land a person on the moon with only 32KB?!!

So, how do we measure the resource use of a given algorithm? Essentially, we decide how much of a resource is used for each “step” in the algorithm, then try to count the number of steps the algorithm will perform. Suppose we had a very simple algorithm:

With a few simplifying assumptions, it’s probably safe to say that this would require just 1 step to perform, namely the step of displaying the value 1. Meanwhile, a similar, yet slightly more complex, algorithm such as

would likely require 2 steps: 1 step to look up the value of x and 1 step to display the value. Here, I’m assuming that the variable x has already been assigned a value, which would have taken a little work, as well.

Taking it one step further (ha!), consider the slightly more complex example of

How many steps would that take? Well, looking up the value of x is still 1 step, plus 1 step for the addition operation, plus 1 step to display the result of the addition. So, 3 steps in total. This assumes that you have a sensible computer at your disposal where addition only needs 1 step to complete.

Again, let’s make it a little more complicated and consider

Now, multiplication, unlike addition, is usually a two step (or more!) operation. Why is that? Well, for simple addition problems, computers have a straightforward solution to solving the problem. But multiplication is a more complex process, as any 4th grader will tell you. One way to think of multiplication, in the general case, is as repeated addition. So, x * 4 is the same as x + x + x + x. But if addition is a 1 step process, then that approach to multiplication would require 4 steps! Fortunately, computers have better algorithms for multiplication than our grade school teachers taught us. Still, multiplication takes more steps than addition, so for the sake of argument, let’s say it’s 2 steps per multiplication. You can probably imagine what would happen with exponentiation!

In short, every operation that the computer must perform takes time, which in the abstract we can think of as steps. Looking up a value is an operation, storing a value is an operation, displaying a value, adding, multiplying, and even just waiting– they’re all operations. We can count the number of operations to be performed (not always as trivial as I’ve made it here) and use the total number of steps as a measure of efficiency.

Some algorithms take constant time to execute. Looking up the first entry in a phone book, for example, will always take the same number of steps, regardless of how big the phone book is.

Other algorithms will vary, based on the size of the input (i.e., how big the phone book is). For example, counting the number of people named Jane in the phone book is relatively easy in a very small town, but very hard in a large city! In computer science terms, we say that the input to an algorithm is of size n (i.e., how many names in the phone book, in this case). When n is big, the algorithm takes more steps.

For very large data sets, the difference between an algorithm that executes in 1 step versus an algorithm that requires n steps (where n varies on the size of the input) is a huge difference. Finding the first name in the phone book in New York City is as easy as finding the first name in the phone book in Smalltown USA.

In computer science we would say that asking “what is the first” is O(1) (read: “big-Oh of 1″ or “on the order of 1″) and asking “how many are there” is O(n) (read: “big-Oh of n” or “on the order of n”).

O(1) algorithms execute in a constant number of steps (the time to execute it doesn’t vary when the input size varies). For example, “what is the first (or last) element?” is an O(1) question… no matter how large the input is, finding the first (or last) element is easy.

O(n) algorithms execute in n steps (the time to execute it DOES vary when the input size varies). For example, “what is the maximum (or minimum) value in a given list?” is an O(n) question… generally, you have to inspect every element in the list to be able to answer it. If you happen to know a priori that the list is sorted (a special case), then finding the minimum or maximum reduces to finding the first or last element in the list, respectively, making it an easy question — but you have to get the vector sorted, first.

There are many other orders of complexity: O(log(n)), O(n/2), O(n²), O(n³), O(n!), and so on. Something that’s O(n!) will take a very large number of steps, even for small values of n (the factorial function grows very quickly!).

In short, understanding something about the number of steps a given algorithm will take to solve an instance of a problem can help us choose among different algorithms that all produce the same result, but where some solutions are more efficient than others.

It strikes me that co-work spaces and coffee shops are similar, but… not. Your typical coffee shop grudgingly offers moderately useful WiFi (can we get rid of the 20 minute timeouts and required “accept terms” pages, please!) and a few power outlets and has yet to figure out what to do with all these individual patrons taking up so much table space for so long. In short: lots of coffee, little access to power or high speed WiFi.

Co-work spaces have more than enough power outlets and Wifi, usually high speed and reliable (if not, find another co-work space!), but very little coffee. People are expected to come in, spend time without buying anything, and slurp all the Internet they can.

Could we have a coffee shop-style chain of co-work shops with space, meeting rooms, power, and WiFi and sell day passes/memberships? What’s the critical population/entrepreneurial density to sustain it?

So-called “content providers” who provide little to no content in their RSS feeds break my flow. They’re an annoyance to read. Their one-line teasers drive me away from their content, not toward it. I tend to unsubscribe from those feeds, rather than visit their websites.

If your one-paragraph introduction is compelling, I’ll visit your site to read the rest. However, your one-line teasers are rarely compelling and often annoyingly vacuous.

Please, provide the content and let me decide how to consume it.

While many content providers are working diligently to find ways to lock us in to their content and to exclude aggregation, it’s aggregation that I want!! I want to be able to read my content in the form and manner that fits my workflow of the moment.

Reeder for the iPad is a great example of an app that makes reading a pleasure. It’s fast; amazingly fast. I can read my Google Reader subscribed feeds, mark items for further follow-up, forward them to my Twitter feed (Note to Reeder devs: I maintain more than one Twitter account and more than one account on other social networking sites, to separate the personal from the professional roles vested in me), add it to my Instapaper account, and so on. In short, reading news feeds in Reeder is a pleasure; very nearly perfect.

With the explosion of applications for the iPhone and iPad, I wanted to point out that, for many things, I don’t want an app for that! Consider the works of Shakespeare; I really don’t want a separate app for each of his plays and sonnets. Some books and magazines are being published as separate apps, to take advantage of the graphics in OpenGL ES, to control content distribution, etc; I understand their reasoning. But I don’t want one-app-per-book; it’s too messy and disjoint. Similarly, I don’t want one-app-per-magazine or one-app-per-newspaper; I read too many sources each day for that model to work.

What I want is to be able to retrieve, review, annotate, and share content I view with the tools I find most natural and that enable my workflow. I do wish “content providers” could grasp that and start providing some content, instead of trying to lock it away.

Like many educators, I worry about the level of effort that my students commit to their studies (the process) and the quality of their work (the product). We call the process many things: engagement, time on task, passion… But we mean to describe that self-driven, motivated commitment to learning for the sake of learning that we value.

Unfortunately, in many educational environments, the standard proxy for effort is the course grade. Grades are a poor proxy, but are so ingrained in educational practice (in some of the institutions where I teach) and in students’ minds that it may be useful to consider a way to structure grade rewards to encourage the genuine engagement from students that we desire.

I’ve tried to address this in my syllabi and in my course designs by assuring students in various ways. Most recently, I’ve tried to get them to understand that they start out in my class with an A and that it’s theirs to lose by not doing the course work. I’ve had some success with that approach and some students have embraced the notion that they start at the high end of the scale and not at the low end. It’s subtle, but seems to help some students’ mindset.

I’ve recently been trying to reconcile that with my insistence in classes that students should view the syllabus as the least they can do to pass a course; they should view it as a floor, rather than a ceiling. But why should they, when they get an A for doing what’s listed in the syllabus? The potential reward (or lack thereof) doesn’t match the effort I’d like to see my students make.

Meanwhile, I’ve read Carol Dweck’s work on the perils of praise which, if I read it correctly, comes down to two main findings:

• If you praise outcomes (using rewards, e.g.), learners will tend not to take risks. Instead, they’ll do only those things they know they can do, because they’ve done them before and know it will bring rewards.
• If you prize effort, then learners will tend to take risks, even if it might lead to failure, because they learn to value the process, rather than the product.

I’ve also been thinking about Daniel Pink’s work on the motivation distribution: reward too little or too much and individuals aren’t motivated; reward enough to cover the necessities and individuals are motivated to improve.

How can I build those ideas into my course designs?

Effort is difficult to observe or quantify, but we know it when we see the results. I can focus on the effort involved when I’m conversing with students, but how can I encode the value I place on effort in forms that will resonate with students who don’t typically engage in conversations with their instructors?

Setting the right reward structure might be easier, however. Simply create a syllabus that outlines what students need to do to attain a respectable B in a course and leave an A-level project up to the individual student to conceive of, propose, and execute. Think of the A-level project as the student’s 20% flex time. They get to be creative; in fact, need to be creative in order to receive the highest rewards. The project design, itself, can be a series of milestones that presses students to think early and often about their original contribution to the class.

Some students will be happy working toward a B and leaving it at that, while the others—the grade-seekers and aspirers—will be called on to think about their learning experience and about what sparks their creative talents.