Holding off on evaluating variables

There is a difference between performing a calculation and solving a problem.

I’ve been considering the equation of a circle, x^2 + y^2 = r^2. Except, you see, that’s not the entire thing. There’s a bit that we’ve dropped because it’s  zeroes (and therefore doesn’t affect our equation):

(x-h)^2 + (y-k)^2 = r^2.

This equation contains the full information–everything that is necessary to draw and position a circle on a cartesian graph. You see, the and k move the circle around the graph. When the circle is on the origin, they are both zero and often dropped from the formula. When figuring something quickly with a circle, the shortened form is more than adequate. However, without them, part of the story is lost.

Similarly, if we have the task of working a problem it is tempting to perform the arithmetic along the way. If we resist, however, at the end we produce a general solution that may be used for other similar problems.

Programming can work the same way. We may write a program to perform a calculation. This would involve lots of hardcoding, many assumptions making it analogous to our “arithmetic along the way”.

Alternatively, try leaving the variables in, or not doing the arithmetic along the way, and preserve the information in the equation which would otherwise be lost.

Switching Wireless, a Soap Opera

Now that I’ve gotten my Wireless Perceptions guide out of the way, I can mention one of my favorite misconceptions.

Myth: “Switch to MUSTANG, it’s faster than MORNINGSIDE.”

The observant reader will note that this myth is contradictory to my previous assertions. No right-thinking person would possibly believe that something is slower when it is faster.

One wrinkle in our understanding of wireless is that we expect it work just like cell service. When we are close to a tower, we want to use that tower. If we move across the city, we want to change to closer towers without a blip.

Wireless (802.11, WiFi, etc) does not always work this way. The decision to leave one “tower” for another is completely up to the client. All of our radios have ways of encouraging clients to move but cannot force a client move to a closer radio.

It is the practice of most clients that I have seen–Windows 7, Mac OS X, and others– to stay associated with the original tower until practically disconnected. In one instance, a user closed their laptop in an area while connected to a nearby radio and walked down the hall to their office (which is out of range of the first, but well covered by a second radio). When they opened their laptop, it registered almost no connectivity in spite of abundant local wireless because it was still connected to the classroom radio.

At this point, it is not irrational to open up the AirPort menu to investigate. After the computer reconnects to MORNINGSIDE from down the hall (because it can still see a trickle of the wireless signal back in their office) they see that their network is performing poorly. In that menu, MORNINGSIDE will be presented with zero bars and MUSTANG with maximum bars.

In this case, the connection strength shows the MORNINGSIDE radio that is currently connected and in use. The MUSTANG network strength is displayed from the closer radio.

Fact: Close wireless is better than distant wireless.

At this point, our user disconnects from MORNINGSIDE in favor of MUSTANG and observes that it is significantly faster.

To conclude at this point that MUSTANG is faster than MORNINGSIDE is a half truth. A near MUSTANG is faster than MORNINGSIDE at a distance.

Moral of the story: Sometimes disconnecting and reconnecting to wireless will allow the computer to connect to a closer radio.

Wireless Perceptions

It has come to my attention that wireless is still considered somewhat amorphous and, as a result, I’ve seen some pretty interesting misconceptions.

How does our wireless work?

Small radios have a limited range so we have many of them all over campus. Sometimes they are in visible locations and sometimes they are hidden in closets or above ceilings. But, if you are receiving MUSTANG or MORNINGSIDE wireless networks, one must be nearby.

Every radio on campus is configured centrally to handle both MUSTANG and MORNINGSIDE networks.

In fact, MORNINGSIDE and MUSTANG share a number of features:

  • Both run on 5Ghz and 2.4Ghz spectrum, allowing both bands to connect.
  • Both run on every radio on campus.

What is the difference between MUSTANG and MORNINGSIDE?

  • MORNINGSIDE encrypts traffic passed through the air. MUSTANG does not.
  • MORNINGSIDE is authenticated. Because you log in with your Morningside credentials, Staff and Faculty are given more access than they would be on MUSTANG.
  • MORNINGSIDE will be faster. MORNINGSIDE has “High throughput” features of 802.11n enabled, while MUSTANG does not.

MORNINGSIDE is faster?

Yes. Sitting in my office, I benchtest 15.8Mbps on MUSTANG and 58.1Mbps on MORNINGSIDE. Everything is the same except for changing from MUSTANG to MORNINGSIDE.

How to attach to a remote emacs session

I was away from my workstation which was running an emacs with several open files (some potentially unsaved!) when I wanted to access some of those files.

My emacs is always configured to run the server process. This means I can start an emacs process and edit any file with `emacsclient $file`. Instead of a new emacs process, the file is opened by my original emacs.

I was curious if I could use emacsclient to connect remotely to a running frame: I can. By ssh’ing in I can run `emacsclient -nw` (no-window) and get a new frame of that emacs client in the terminal which has all my buffers open and ready to go.

Alternatively, if you’re forwarding X connections, using `ssh -X` for instance, `emacsclient -c` will fire up a new emacs frame on your local machine which shares the same emacs process.

More information: http://www.emacswiki.org/emacs/EmacsClient

Naive Programming

I think that may always be the case, especially when the resulting program is a function of what I’m asked to do! I was instead considering how, give experience in mathematical reasoning and programming, one writes increasingly concise code.

Because of the intense usefulness of Maths in programming, I cannot grok my fellow students’ disapproval of the subject. One of the major ways my code has grown less naive is in the borrowing of mathematical concepts.


// print the sum of numbers x through y.
int sum(int x, int y) {
  int s = 0;
  for (int i = x; i <= y; i++)
    s += i;

  return s;


// print the sum of numbers x through y.
int sum(int x, int y) {
  return y*(y+1)/2 - x*(x+1)/2; 

I cannot remember a time when a working insightful function has been worse then the naive equivalent. Even in my contrived example above the naive_sum() has inputs which would yield undefined output such as the case where y <= x while the insightful_sum() would degrade more gracefully.

In the naive style, we’d have to add conditionals to validate inputs that the maths would accept, meaning increased line count, reduced legibility, increased chance of errors, and increased nativity. The only advantage I can see to the naive style is the reduction in mathematically cluttered code.