Month: May 2012

Visiting Puerto Rico

Posted on by John

I’ve been in San Juan this week, visiting the University of Puerto Rico. I’ve been here several times before, but here are a few things I noticed about Puerto Rico on this trip.

Coffee: Coffee means espresso here; I haven’t seen it brewed any other way. And it’s cheap. At UPR, a 4 oz pocillo is only $0.70, and at a bakery near my hotel a 6 oz espresso con leche is $1.25.

Gasoline: You can’t pay at the pump with a credit card. You have to go inside to pay for gas. Some gas stations used to let you pay at the pump, but these have gone back to having you pay inside.

Electronics: I’ve been told that you can’t buy electronics from Apple’s website for delivery in Puerto Rico. You can buy Apple products in stores like Best Buy on the island, but you can’t have them shipped directly here from their website.

* * *

Related post: Beer with a confidence interval (Medalla)

Python as a Lisp dialect

Posted on by John

From Peter Norvig:

Basically, Python can be seen as a dialect of Lisp with “traditional” syntax … Python supports all of Lisp’s essential features except macros, and you don’t miss macros all that much because it does have eval, and operator overloading, and regular expression parsing, so some — but not all — of the use cases for macros are covered.

Source: Python for Lisp Programmers

Reading historical math

Posted on by John

I recently received review copies of two books by Benjamin Wardhaugh. Here I will discuss How to Read Historical Mathematics (ISBN 0691140146). The other book is his anthology of historical popular mathematics which I intend to review later.

Here is the key passage, located near the end of How to Read Historical Mathematics, for identifying the author’s perspective.

But not all historical mathematics is significant. And perhaps there is a second kind of significance, where something can be historically significant without being mathematically significant. Some historians (I’m one of them) delight in investigating mathematical writing that contains little or no important or novel mathematics: popular textbooks, self-instruction manuals, … or old almanacs and popular magazines with mathematical news or puzzles in them. These kinds of writing … are certainly significant for a historian who wants to know about popular experiences of mathematics. But they’re not significant in the sense of containing significant mathematics.

Wardhaugh’s perspective is valuable, though it is not one that I share. My interest in historical math is more on the development of the mathematical ideas rather than their social context. I’m interested, for example, in discovering the concrete problems that motivated mathematics that has become more abstract and formal.

I was hoping for something more along the lines of a mapping from historical definitions and notations to their modern counterparts. This book contains a little of that, but it focuses more on how to read historical mathematics as a historian rather than as a mathematician. However, if you are interested in more of the social angle, the book has many good suggestions (and even exercises) for exploring the larger context of historical mathematical writing.

Big data is easy

Posted on by John

Big data is easy; big models are hard.

If you just wanted to use simple models with tons of data, that would be easy. You could resample the data, throwing some of it away until you had a quantity of data you could comfortably manage.

But when you have tons of data, you want to take advantage of it and ask questions that simple models cannot answer. (“Big” data is often indirect data.) So the problem isn’t that you have a lot of data, it’s that you’re using models that require a lot of data. And that can be very hard.

I am not saying people should just use simple models. No, people are right to want to take advantage of their data, and often that does require complex models. (See Brad Efron’s explanation why.) But the primary challenge is not the volume of data.

Related post: Big data and humility

Traveling salesman art

Posted on by John

Bill Cook sent me a file yesterday that renders the Endeavour photo on my blog as the solution to a 66,290-city Traveling Salesman problem. His iPhone app Concord TSP chose 66,290 points and then solved for the shortest path connecting these points, a feat that would have strained a supercomputer a few years ago. (Bill Cook and I are not related as far as I know.)

Here is a thumbnail image of the full TSP tour:

You can find the full PDF here (1.24 MB). To show some of the detail, here is a close-up from near the top-left corner of the image:

I asked how the tour was constructed:

How do you construct a set of points whose TSP solution resembles a photograph? Is it sufficient to add more “cities” in regions where you want darker shading? And are the cities added at random with a density specified by color depth?

Bill Cook replied:

By default, the app will select the points along the line you describe: it splits the image into a grid, computes the average gray scale in each grid region, and drops a number of random cities into each grid region in proportion to the square of the average gray scale. This technique was first proposed by Bob Bosch and Adrianne Herman at Oberlin College. It is the default since it takes almost no time to compute, but I include two other options, that each take about a minute to render a large image on an iPhone 4.

The image of The Endeavour was created with a method Jim Bumgarnder proposed in his Stipple Cam project.

Related post: Moore’s law squared