[nav prev=’ppprev’ next=’nnnext’]

Wikipedia article on PRISM Surveillance Program

Washington Post: U.S., British intelligence mining data from nine U.S. Internet companies in broad secret program

The Guardian: NSA paid millions to cover Prism compliance costs for tech companies

The Atlantic: PRISM Companies Start Denying Knowledge of the NSA Data Collection

“How much math do I need to know to program?” Not That Much, Actually.

Nobody Wants to Learn How to Program

I’ve completed my next book, which focuses on the Pygame library and making graphical games in Python. It assumes you have a little bit of Python programming knowledge. The book is free to read online from http://inventwithpython.com/pygame and can also be bought on Amazon.com for $25.

Thanks to everyone who helped me out with this book over the last year and a half.

So I’ve written a program that will automatically open a new browser window pointed to Google Maps at whatever text is in the clipboard. Now I just copy the address, hit Win+R to bring up the Windows “Run” dialog, and then type “mapit”. Instant map.

You can also type “mapit <type address here>” to run it from the command line.

Download the Windows Executable (6.2 MB, big since it’s a compiled Python script)

Download the Python script (2 KB)

The Python script should work with Python 2 and 3, and on Windows, Mac, Linux (but I haven’t tested it on Mac & Linux yet).

Here’s the code on github: https://github.com/asweigart/mapitpy

JavaScript Cipher Wheel

I also have a Pygame version and Windows executable of this.

A Clever Programming Trick…

If you need to swap the values of two variables, this usually requires a third temporary variable (that is, if you’re not using a language like Python that supports the a, b = b, a syntax.) It looks something like this:

temp = a;
a = b;
b = temp;

But if these are integer variables, there’s a nifty trick to save yourself a little bit of memory. You can use arithmetic instead of a temporary variable:

a = a + b;
b = a - b;
a = a - b;

If the integers on your platform are 32-bits, your new swap will save four bytes of memory.

NOBODY CARES ABOUT FOUR BYTES OF MEMORY.

This is a mistake a lot of new programmers make. The coder comes up with some clever trick or that can save a few bytes of memory or shave a few nanoseconds off of a function. You must learn that these “clever tricks” aren’t really worth it. These clever tricks are called “micro-optimizations”, and back when computers only had 64KB of memory, they made sense. More often than not these days they just make the code less readable and harder to debug. Memory is cheap, and humans won’t notice a few more milliseconds of waiting time (unless the delay is for a frequent and visible event.)

Think about it. In the time that it takes for you to read this sentence, several billion nanoseconds have already passed. Billions. A clever trick that saves a few nanoseconds at the expense of code readability is not going to be noticed. NOBODY CARES ABOUT A FEW MILLION NANOSECONDS.

“Premature optimization is the root of all evil.”

This notion is encapsulated in Don Knuth’s venerated saying, “Premature optimization is the root of all evil.” In other words, you should concentrate on making your software, then concentrate on making it work correctly, and then later (if you have to) concentrate on making it fast. Trying to optimize the code before then is a fool’s errand. Most likely, the software you write today will have been replaced or tossed out or forgotten three years from now. (Unless you are writing Oregon Trail, in which case old people will keep writing emulators to play it out of some silly sense of nostalgia.)

Some examples of clever tricks you should never do:

• The integer variable swap trick shown above.
• Reusing variables for different purposes. Separate variable names for separate values makes debugging easier.
• Using a float instead of a double. (You save a little memory but the smaller precision can result in notoriously tricky rounding errors.)
• Doing math in the code for the computer, such as multiplying a value by 525600 (the number of minutes in a year) instead of multiplying a value by 60 * 24 * 365 (which is more obvious). The compiler/interpreter will most likely optimize these automatically anyway.
• Combining functions together into fewer functions to reduce the overhead of function calls.
• “Loop unrolling/unwinding”, that is, copying/pasting code that would normally be in a loop so that you do not have the overhead of looping for each iteration. (Don’t even think about using Duff’s device.)
• Short variable and function names. This doesn’t even make the compiled program run better, it just makes the source code slightly smaller. That the variable “mttl” means “monthly total” will be completely impossible to know, even for the programmer who wrote it, once a few weeks have elapsed. Single-letter variable names, unless it’s something like x and y for coordinates or i and j for a loop’s variable, should never be used. Don’t use the variable name “n” to store a number: have the variable name describe what the number is used for.

Don’t Guess, Use a Profiler

When you do begin the process of optimizing your program, don’t just look through your code and guess where the slow and bloated parts are. Run your code under a profiler, which will scientifically tell you how much memory and how long is spent executing each function in your program. (For Python, the cProfile module does a good job. See the Instant User’s Manual to learn how to profile your Python code.)

Unless the software is being run on a computer that is going into space, a nuclear reactor, or someone’s chest cavity, these micro-optimizations don’t matter 97% of the time. Even when programming for smart phones (which have limited system resources) you need to focus on improvements that result in orders of magnitude improvements, not micro-optimizations. These usually involve caching data or using entirely different algorithms, not tiny clever tricks that make the code inscrutable.

Code that is straightforward to read is easy to understand. Code that is easy to understand is less likely to have bugs. Code that is easy to understand is easy to extend with new features. And it’s bug-free programs with cool features that people want. Nobody cares about a few million nanoseconds.

More info about this topic here: http://en.wikipedia.org/wiki/Program_optimization

Also, to head off criticisms of this article, there are times when micro-optimizations are needed. That’s why Knuth says they’re unneeded only 97% of time.

It’s fairly simple to write a program to calculate vampire numbers. I was somewhat bored and went ahead and wrote one up. Download the vampire number generator.

I’ve gone ahead and calculated all of the vampire numbers up to five digits. You can download the full text file of vampire numbers here (zipped, it’s about 1.06 MB). The nifty thing is, if you plot these numbers on an image with the two fangs being the X and Y coordinates, you get a pretty interesting image. This image is 500×500 pixels and covers the range of 0 to 100,000. Each pixel represents a 20×20 range of numbers. The more dense this area is with fangs, the darker the pixel is colored in. The 0, 0 origin is in the lower left. The final image has an interesting pattern: