Broadly speaking, these technical documents attempt to quantify the decision-making process in order that every subsequent decision have justification. The process obscures the study biases by shifting them into the methods of quantification, and ultimately confuses quantifiability with importance.

Setting the Stage

The formal program of the study was documented in the Project Work Plan, in January 2003. One of the first of the study documents was the short Quality Assurance Program, an eight-pager released in November 2003. It establishes the tedious tone in which all further study documents will be written with empty management-speak such as “All DMJM Harris staff performing tasks on the project will utilize the appropriate implementing procedure for the work being performed.”

Two reports were finished in August 2004: The Needs Assessment and the Evaluation Framework. These followed the extensive series of community meetings in late 2003. The Needs Assessment was the only technical document that was published on the (now-defunct) study website. It examined population, employment, and overall destination patterns across the city in relation to existing transit service. The Evaluation Framework brought together all the input–from DC agencies and from the community–about routes and goals and needs and defines what sort of analysis is to be done. A structure of seven routes is proposed, two of which have alternative routings, but the stops along those routes are not defined yet. The project goals are laid out, and the measures and criteria used to evaluate choices in terms of those goals are defined. The general work plan for several documents that follow is laid out.

Route and Mode evaluation:

Screen 1, released September 2004, evaluates seven potential transit modes (streetcars, “bus rapid transit,” light rail transit, diesel multiple units, automated guideway transit, monorail, and heavy rail), and ends up recommending only streetcars and “bus rapid transit” for further evaluation.

The Definition of Alternatives, released in November 2004, analyzed the routes given in the Evaluation Framework for the two chosen modes. Station locations were assigned and propulsion technologies are considered. For each route, a “service plan” was developed, including the headways between successive runs and calculations for route travel times. Although there are separate calculations for streetcars and for “bus rapid transit,” no details are given about the assumptions that went into the calculation of the travel times.

Screen 2, released March 2005, takes the service plans and route structure from the Definition of Alternatives and tries to evaluate how well each would fulfill the project goals by applying a set of “Measures of Effectiveness,” which are defined in the Evaluation Framework. Claiming that “the operational characteristics of BRT and Streetcar are similar at the level of detail” under study, it lumps both into a “premium transit service option” to decide whether a particular corridor should have “premium transit,” or whether it should only receive some bus service enhancements. Corridors were ranked (high, medium or low) based on a few criteria for each of the four project goals, leading to a composite score. Further analysis on meeting corridor deficiencies and operational considerations, and concluded by recommending some routes for “premium transit” and relegating some to get only “local bus enhancements.”

Screen 3, released May 2005, takes the “premium transit” corridors of Screen 2 and applies further “Measures of Effectiveness” to determine whether each corridor should be Streetcars or  ”bus rapid transit.” Each corridor is broken into segements, and the effectiveness criteria are applied to the segments individually. Where applicable–which isn’t as frequently as one might think–Streetcars and “bus rapid transit” are evaluated separately. The scores from these evaluations are totaled, to come up with proposals for streetcar routes, “bus rapid transit” routes, and “rapid bus” routes.

And onwards

Further study documents, released May–September 2005, looked at the finances of the proposed system and put forward the timetable. All the study findings were summarized in a final report, published in October 2005. Future posts in this series will look in detail at some of these technical reports.

I keep a permanent page on this website listing the books that my son has, in order to minimize duplicate copies. I have just now updated this list to include books acquired over the past year.

He does also have a number of books in Korean, which are not presently listed.

Release dates of versions of Mathematica

Mathematica 6 was a substantial upgrade: the graphics system was completely overhauled, the curated data, that I’ve used as the basis for some posts here, was added, and the ability for dynamic interactivity was added with Manipulate and Dynamic. 

I am not, of course, a major Mathematica user. In fact, although I’m a physicist, I haven’t made tremendously much use of Mathematica for my professional work. This is partly because I tend to deal with relatively small data sets, for which a GUI-based data analysis tool is usually easier to work with than the command-line Mathematica. And I’d consider myself an advanced user of Pro Fit, the data analysis tool that’s made all the graphs for all the work I’ve done since about 1998.

In fact, my Mathematica license is my own personal one. As a graduate student, I bought the Student version of Mathematica, which they allow you to upgrade to a full professional license for only a few hundred dollars, compared to the $2500 list price of a new professional license.

Wolfram really wants its users to buy Premier Service, a several hundred dollars per year service which entitles you to all upgrades, major and minor. If you don’t buy premier service, then you need to pay for all upgrades, even the N.M.X to N.M.X+1 minor bug-fixing upgrades. And without premier service, you’re not even supposed to install Mathematica on more than one computer. Draconian and greedy, if you ask me, but they can do that, because they’re Wolfram. And for tech-heavy firms that make heavy use of Mathematica and get millions of dollars worth of value from whatever they compute in Mathematica, it makes sense. But it makes it very difficult to be a casual user.

And even though your existing copy can do everything it could the day you bought it, once the difference between your copy and the current release gets large enough, there is no longer an upgrade path. I think this is one of the motivations to release this as version 7 and not 6.1: I don’t recall the precise figure, but Wolfram generally offers an upgrade path only for jumps smaller than 1.5. If this is still the case,² what this does is cut off anyone who hadn’t upgraded to version 6. Update: enough with the conspiracy theories! Wolfram clears up the upgrade policy in the comments.

In my case, with Version 6.0.1, I have a choice of paying $750, and getting a year of Premier Service, or paying $500 for just version 7.0.0 with no service. Out of my own pocket, ouch! But what makes it really enticing, for me, is that Mathematica now reads SHP files. These are the Geographic Information System data files, promulgated by ESRI, in which vector-valued geographic data is commonly exchanged. In particular, the DC Office of Planning makes an amazingly large collection of DC GIS data available in SHP format. The possibility for quantitative analysis of DC mapping data is very tantalizing.

Of course, Wolfram wouldn’t release a major number upgrade without hundreds of other new features. As of yet, there isn’t much substantial written about version 7. I did find some notes from a beta-tester and from a college math teacher. I’ll probably buy it, even though it would mean delaying other expensive toys that I want.

1. most of the dates come from the Wolfram News Archive, some from the Mathematica scrapbook pages
2. I’ve asked Wolfram, but haven’t received a reply.

Gasoline has, approximately, 113,000 BTUs per gallon.¹ One BTU is 1055 Joules. So I transferred 1.25 Billion Joules in those 70 seconds, which is a rate of 17.9 megawatts. When you consider that you spend less than two minutes pumping the same amount of energy you burn in four hours of driving, it’s not surprising that you end up with such a high power. What’s more interesting, I think, is to contemplate the rather fundamental limits this puts on plug-in electric cars.

Internal combustion engines, according to Wikipedia, are only about 20% efficient, which is to say, for every 100 BTUs of thermal energy consumed by the engine, you get 20 BTUs of mechanical energy out. This is, in large part, a consequence of fundamental thermodynamics. Although electric motors can be pretty close to perfectly efficient, a similar thermal-to-electric efficiency hit would be taken at the power plant.

Let’s consider, then, that we want a similar car to mine, but electric. Instead of 1.25 gigajoules, we need to have 250 megajoules. Battery charging can be pretty efficient, at 90% or so, which means we’d supply 280 megajoules. If we expect the filling-up time to be comparable to that of gasoline cars–call it 100 seconds for simplicity–then we’d need to supply 2.8 megawatts of power. At 240 Volts, which is the voltage we get in our homes, this would require 11700 amps; if you used 1000 Volts, it would take 2800 amps. Although equipment exists² to handle these voltage and current levels, it is an understatement to say that it cannot be handled as casually as gasoline pumps are handled. Nor is it clear that any battery system would actually be able to accept this much power.

A linear relationship exists between the power requirement for filling, and the vehicle range, the vehicle power, and the time for a filling. If you’re satisfied with half the range of a regular vehicle, for example, you could use half the filling power. Let’s imagine that you’d be happy for the filling to take ten times as long as with gasoline, or 1000 seconds, just under 17 minutes. At this level, you’d need 280 kilowatts of power. If battery charging is 90% efficient, that means 10% of the power is going to be dissipated as heat, which in this case would be 28 kilowatts.

For comparison, a typical energy consumption rate for a home furnace is 100,000 BTU per hour, about 28 BTU per second, or 29.3 kilowatts. Which means that the waste heat dissipated during charging for the example–of a 1000 second fill for a vehicle with similar range and power as a modest gasoline powered sedan, at 90% charging efficiency–is as much as the entire output of a home furnace.

No wonder overnight charges are the standard.

1. Summer and winter blends have slightly more and less, respectively.
2. think about how large the wires would need to be

The study finishes

The final project newsletter, Fall 2005, and an “Executive Summary“ of the whole project were presented to the public at a final meeting, held September 29, 2005. For transit enthusiasts following the project, the end results were disappointing and frustrating. Instead of a visionary transformation of mobility in the District, the final recommendations proposed a meager streetcar buildout that, despite its modest size, would take 25 years to build. The report was frustrating because it relied on tortured reasoning that bordered on downright dishonesty, it used self-contradictory and mutually inconsistent reasoning, and offered little more than poorly-defined chimeras wrapped up in wishful thinking.

Added to the project was “Rapid Bus,” as a lower-class technology mode, joining streetcars and “bus rapid transit.” Modes were assigned to routes. The newsletter used separate streetcar and “bus rapid transit” assignments, while the executive summary lumped these together as “premium transit.” In the newsletter, streetcars got a handful of routes: the crosstown Georgtown to Minnesota Avenue route; the north-south Georgia Avenue route, which would end at K street; a Union Station to Anacostia via Eastern Market route; an M Street SE/SW route, and a short Bolling AFB–Pennsylvania Ave route. A bit of “bus rapid transit” was added: mainly Woodley Park to Eastern Market via Florida Avenue, while the rest of the 50-mile route structure developed over the course of the study was designated “rapid bus.”

On the face of it, we’re being asked to believe that there is a significant difference between “bus rapid transit” and “rapid bus,” yet no clear description of the features that differentiate “bus rapid transit” from “rapid bus” is given. “Rapid bus” is supposed to have: limited stops, fancier shelters, real-time arrival information, and signal prioritization, as is “bus rapid transit.” They’re both supposed to use “large vehicles,” with those for “rapid bus” being “distinct” and those for “bus rapid transit” supposedly “recalling the design of streetcars.”  Even though “rapid bus” vehicles “could be” 60-foot articulated buses, the largest buses used anywhere in the United States, “rapid bus” vehicles “tend to be smaller” than “bus rapid transit” vehicles. One feature that was mentioned for “bus rapid transit” but not for “rapid bus” was off-vehicle fare payment.

“Bus rapid transit” is said to run “either on mixed traffic or on dedicated rights-of-way,” and several of the “bus rapid transit” examples cited do make use of dedicated rights-of-way. Boston, Ottawa, and Pittsburgh are explicitly called out as examples of “bus rapid transit,” and shows pictures of the system in Rouen, France. Both Ottawa and Pittsburgh rely on massive, exclusive and grade separated rights of way for their systems, built on abandoned railroad rights-of-way. Rouen’s TEOR uses several sections of exclusive right-of-way with optical guidance. No similar opportunity for constructing such facilities exists along the corridors proposed for DC, and surely such rights of way would be as incompatible with neighborhood scale as light rail would be. The documents make no mention of the heavy criticism that Boston’s Silver Line has received. Incidentally, neither Boston nor Pittsburgh use off-vehicle fare payment. I find it a little dishonest to cite systems whose success (such as it is) relies on features that are not under consideration for DC.

The proposed timetable for transit buildout is galling. All lines are supposed to start as “rapid bus.” Of the meager streetcar and “bus rapid transit” network that’s proposed, the newsletter states “Naturally it will take time–two decades, in fact” to get it built. The system would not be finished until 2030, even though the need is immediate and growing, as was illustrated in the Needs Assessment. And the executive summary mentions Mayor Williams’s goal of adding 100,000 residents by 2013 is cited: presumably, we don’t want to make them wait 17 years for adequate transit.

Similarly frustrating is the lumping together of streetcars and “bus rapid transit,” as if it’s possible to create a bus-based system that could be considered equivalent to a rail based system. Although it’s been quite clear in all the public outreach that there are lots of people who are excited about streetcars, there is no evidence that anyone is excited about more buses. This is not to say that everyone is excited about streetcars, but the opposition to streetcars does not come from an enthusiasm for buses. Streetcars offer better ride quality than buses, and the investment in infrastructure required for streetcars gives other investors confidence in the civic commitment. Indeed, while there are dozens of examples of rail-based urban revival, there are no examples of bus-based revival. Rail has shown itself to be far more attractive to riders: whenever a bus service is replaced by rail, ridership grows; whenever rail is replaced by bus, ridership drops. 

If the final output of the study was underwhelming, what happened next was breathtaking. Once the study was over, absolutely nothing happened. The study documents seemed destined to gather dust on someone’s shelf. It did not help that the DDOT Mass Transit Administrator, Alex Eckmann, left in February 2005, before many of the reports would be released and decisions would be made. The position would remain vacant until the study was nearly complete. The DDOT director who pushed to get the study underway, Dan Tangherlini, left DDOT in February 2006 to become interim general manager of WMATA. Because this was near the end of then-mayor Williams’s term, DDOT was left in the hands of the deputy director; no high-profile appointment was made. This left a leadership void from which no push to move forward with the transit project was made.

So how did the study team arrive at its conclusions? Part 3 of this series will examine the detailed technical documents produced by the study team.

It occurred to me that this is an easy thing to investigate with Mathematica, much like my earlier post on the Bailout. Mathematica 6 includes access to a huge library of curated data, including historical values of the Dow Jones Industrial average and other indices (and individual stocks, and so forth). The function here is FinancialData, which Wolfram cautions is experimental: I believe they get the data from the same source as, say, Yahoo! Finance, and just do the conversions to make it automatically importable into Mathematica. That is, it is no more reliable than other web-based archives. The computations are absurdly easy, taking only a few lines of Mathematica code. 

The graph I (eventually) produced shows the relative frequencies of first digits that are calculated by Benford’s Law, together with the relative frequencies of the leading digits from the Dow Jones Industrial Average, the S&P 500, the NASDAQ Composite index, the DAX 30, and the Nikkei 225:

It appears that, for both the Dow and the S&P 500, there is a surplus of 1s as leading digits, and also of 8s and 9s. None of the indices particularly follows Benford’s Law, although I’ll leave it to the more statistically inclined to figure out the significance of the variations. 

To fetch the historical closing prices, simply tell FinancialData what date range you wish to look at; in this case, it was All:

dowJonesData = FinancialData["^DJI",All];

Use the semicolon to prevent a 20000 element list from being displayed. (Actually, Mathematica 6 is smart enough to know that one usually doesn’t want to look at lists that long, and would show a shortened version. FinancialData uses the standard ticker symbols for the indices: ^GSPC for the S&P 500, ^IXIC for NASDAQ Composite, ^GDAXI for the DAX 30, and ^N225 for the Nikkei 225. The function returns a list of date-closing value pairs, such as:

In[]:= dowJonesData[[1]]
Out[]:= {{1928, 10, 1}, 240.01}

I wrote a small function that captures the first digit:

FirstDigit[x_] := RealDigits[x][[1, 1]]

RealDigits returns two things: a list of the digits, and the number of digits to the left of the decimal point, so the [[1,1]] element specifier picks out the first element, i.e. the first digit, from the list of digits.

dowJonesDigits = FirstDigit /@ Transpose[dowJonesData][[2]]

Since dowJonesData is a list of date/value pairs, Transpose transforms it into lists of dates and values, and the second of those is what we need to work with. The shorthand for Map is /@, which performs the function on the left, FirstDigit, on each element of the list on the right. To tally the number of each leading digit, I use BinCounts:

dowJonesDigits=Rest[BinCounts[dowJonesDigits]]
dowJonesDigitFractions=N[dowJonesDigits/Length[dowJonesData]]

Since there are no zeroes as leading digits, but BinCounts starts its tally with zero, I use Rest to remove the first element of the returned list. The N is necessary to avoid getting a bunch of (exact) fractions when computing the percentages.

I won’t go into detail about the production of the graph (or the table): this is the type of thing that often trips me up in Mathematica. Although it is true the Mathematica has nearly unlimited flexibility to make graphs, finding the right method to do something that isn’t one of the default options often leads to a frustrating cycle of tweaking, looking at the examples, and experimentation. In this case, getting the legend to come out right was a sticking point.

The same is true with the following table, which I present for anyone wishing to think about the data in more detail. Figuring out the right way to make the number of decimals right for each entry took much longer than it should have.

In any case, here are the individual percentages presented in the graph above, along with the total number of data points for each sample set, and the first day for which FinancialData data is available.

 Update, 20 Nov 2008: fixed Nikkei column in table.

Bringing a 50-mile streetcar network to Washington DC is the top priority for the DC Chapter of the Sierra Club. I have been following this issue with the Sierra Club since 2002, and it was recently suggested to me that I write down a brief history of the effort, to provide context for those new to the subject. Current progress on the issue is blogged at streetcars4dc.org. 

The DC Transit Improvements Alternatives Analysis gets underway.

The last time streetcars ran in DC was the early morning of January 28th, 1962, after which all lines were converted to buses. Such was the state of public transit in the District until March 27, 1976, when Metrorail opened. Metrorail, of course, has been a tremendous success, but it does not serve all areas of DC, and was designed primarily to move suburban commuters to their jobs in downtown DC.

The District government has, in principle, been planning to bring streetcars back to DC for some time now. My involvement began in September 2002, when I testified on behalf of the  at a joint oversight hearing of the DC City Council. A relatively small, two-year study had recently been completed (DC Transit Development Study), and then-DDOT director Dan Tangherlini, and then-DDOT Mass Transit Administrator Alex Eckmann went before the council (read their presentation) to ask that a more expansive study be funded. Plans to expand transit in the District stretch back further than that, and are generally said to have begun with the Barry-era DC Vision Study of 1997, itself 2 years in the making. And after more than ten years of talk and study, there are still no streetcars.

DC Vision had proposed four light rail corridors and a new crosstown Metrorail line. The Transit Development Study had looked at nine potential routes, and from that, DDOT proposed what amounts to five corridors for further study. Three were crosstown routes, converging in the east at the Minnesota Avenue Metro and crossing the river together. Two of these followed a northern route, heading west to Union station, from which one would go northwest to Woodley Park and another would head to Georgetown. The third crosstown route headed south to the Navy Yard, and continued to Waterfront. A north-south route followed Georgia Avenue/7th Street from Silver Spring to Waterfront, and an east-of-the-river route that went from Minnesota Avenue, to Anacostia, and finally to National Harbor.

The study that did go forward, formally the DC Transit Improvements Alternatives Analysis, was indeed quite extensive. A joint effort between DDOT and WMATA, most of the actual work of the study was done by transportation engineering firm DMJM+Harris. Numerous public meetings were held, fancy full-color newsletters and brochures were produced, and scores of meetings with community groups were held, including one with the Sierra Club in October 2003. Tangherlini and Eckmann both spoke enthusiastically about the plans for the 2002 Rail-Volution conference, which was held in DC that year. 

Throughout 2003, a series of semi-public meetings were held: nobody would be excluded, but they were advertised primarily to civic leaders. In July I made it to the meeting in the Mt. Pleasant neighborhood, at which, it turned out, I was the only attendee to show up. From a public outreach standpoint, this is not so good, but for a transit wonk like myself, a detailed, hour-long conversation with the project leaders was something of a treat. In the fall, the project released the first of what would be five project newsletters (Fall 03, Spring 04, Fall 04, Spring 05, Fall 05).

By Spring 2004, the list of routes under consideration had grown, and in addition, the route lines were drawn as narrow lines following actual streets, instead of broad bands indicating a general route. A route up Wisconsin Avenue was added, as was a Brookland-Columbia Heights-Woodley Park crosstown route. Alternate alignments for the southern route from Woodley Park were added: one that headed to New York Avenue and then went south to Eastern Market, and the other going to Union Station and snaking across the Capitol to Eastern Market. By the Fall of 2004, a Foggy Bottom-Waterfront route, hugging the Potomac, had been added, a a spur East of the River was added. The map presented in the Spring of 2005 backed off of showing lines along particular streets to re-work the routes into nine “proposed corridors.”

The newsletters, and other project documents, were available on a well-publicized, but regretfully, now defunct website called dctransitfuture.com (archived on the Internet Wayback Machine), and many of them are now on DDOT’s website. In conjunction with the public meetings and widely distributed newsletters, some substantial analysis analysis of transportation services and demand was being conducted, which culminated in the Needs Assessment, released in June 2004. Not surprisingly, it found a great need for expanded transit in the city. One of the most telling parts (Fig. 6, p. 17) shows a map illustrating the density of households with no car available: this quite clearly shows the need for high-capacity transit along Georgia Avenue and along H Street NE. Nearly all of the corridors from the 2004 newsletters were identified in the Needs Assessment as “recommended priority transit corridors” (Fig. 20, p. 43).

The project team met with the Sierra Club for the second time in June 2004. I recall asking if there was some thing we could focus on that could help move the project forward; the project team demurred, assuring us they had everything under control. The Fall 2004 newsletter announced that the technologies chosen for further study were streetcars and “bus rapid transit.” Through spring 2005, all the route maps presented in every facet of the study treated all the routes equally–they were drawn with the same thickness of lines with no distinguishing features–and no association of routes with technology had been yet indicated. The graphics had emphasized streetcars, modern and historic. Small features in the newsletters highlight the benefits of bringing a streetcar–and not a bus–to a specific neighborhood. 

The point made in Fall 2004 about streetcars was first that they were not considering more Metrorail, but also that it would not be the type of light rail one sees in Sacramento or Dallas or Denver. That is, it would not get dedicated rights-of-way, and would probably not be designed for long, multi-car trains. This makes sense: in these cities, the light rail is the only rail transportation and performs both suburban commuter and urban mobility functions. In DC, the transit is to be overlaid on top of Metrorail, which performs the suburban commuter function quite well.

The Fall 2004 discussion of “bus rapid transit” uses the subtle dishonesty which I’ve found to be typical of bus advocacy: it’s said to “combine the best of rail and bus,” begging the question of whether buses can ever provide service equivalent to rail (to which I answer “no”). Also mentioned is the fact that buses running on dedicated rights-of-way can be much faster than ordinary buses, which is a red herring: it’s already apparent that a dedicated right-of-way, for any sort of vehicle, is not being considered.

At any rate, those following the study at this point had reason to be optimistic.

Part 2 of this series will look at the conclusion of the study, in the second half of 2005. Part 3 summarizes the technical documents produced as part of the study. Further parts will look at the Anacostia Starter line and the issue of overhead wires.

I actually don’t talk to many telemarketers anymore–I’m on the do not call list, so nobody’s been calling to sell me aluminum siding or vacation get-aways. Ever since cell phones really took off, it seems that the long distance companies aren’t falling over themselves to get you to switch to their plan, although I do remember plenty of this in the late 90’s. And although we don’t have caller ID, we’ve gotten pretty good about catching the second or so delay from the robodialers and hang up before the telemarketer comes online.

But sometimes someone does get through, and it’s usually either a charity (usually one that I nominally support) or a political campaign, asking for more money. However, I really, strongly prefer to give on my own terms and on my own schedule, and not theirs. So I want to get rid of them, in some way that’s still polite. So this is what I say now:

Although I will continue to support [your cause], I do not make financial commitments over the phone due to identity theft concerns.

All I have to do now is think of a line to get rid of the (overpriced) identity theft “protection” sales pitches that my credit card companies foist upon me.

I visited Peregrine for the first time Saturday. The space has been remodeled to look much cleaner–in fact, nothing from the old Murky remains. Their blog has several pictures. The chalkboard menus are gone, the walls are painted, the floors are freshly finished. The menu has been simplified, to the point where each drink comes in only one size. The brewed coffee offerings are given more prominence. 

Peregrine gets its coffee from Counter Culture Coffee, the same supplier that Murky uses. Their milk comes from Trickling Springs Creamery, a relatively local dairy in Pennsylvania that sells milk in re-usable and returnable glass bottles. This is one step beyond Murky, which as far as I know used ordinary supermarket milk. 

I had a cappuccino–regrettably, to go, as there were no free seats. Even in the (appropriately sized) to-go cup, the barista poured a small rosetta. It had been months since I’d had a “third-wave” cappuccino: the way-beyond-starbucks, hand-crafted expression of exactly how amazing coffee can be. Delightful.

Coffee lovers in Washington do owe much to Nick Cho, owner of Murky. That his business skills are sloppy is unfortunate, but he planted the seeds of coffee culture in DC. That a former employee is able to open a cafe that improves upon its predecessor reflects both the technical training and the enthusiasm for coffee that Nick imbued his employees with.

But I realized that this sort of comparison is something that Mathematica 6 is supposed to be good at. Mathematica is an amazingly powerful system for doing mathematics on a computer. Its strength, traditionally, has been symbolic manipulation–I most often use it for the Integrate command, which can do most of the integrals that in grad school I’d look up in Gradshteyn and Ryzhik. Version 6 has added, amongst other things, a huge library of curated data, loaded over the Internet, that’s relatively straightforward to use.

The command CountryData gives access to all sorts of country-by-country information, including “GDP” and “GovernmentDebt”. So following one of the examples in the documentation, I produced this graph, plotting the Debt-to-GDP ratio versus GDP for (nearly) all the countries for which Mathematica has data. (Note that the x-axis is a logarithmic scale.) The United States, before and after a $700 billion bailout, are shown in green and red, respectively.

If the xhtml export actually works the way it’s supposed to, you should be able to hover your mouse cursor over each point and have a little ToolTip pop up telling you which country the data are for.

GDP [$US]

Mathematica has a syntax that strikes many as arcane. Since I learned about computers with procedural programming, and haven’t really done any functional programming, I too struggle to get Mathematica to do what I want it to do. But one can often do complicated things, such as the above graph, with a very compact command. To make the main graph–the red and green dots are relatively trivial additions–the command I used is:


gdpplot =
ListLogLinearPlot[
Tooltip[{CountryData[#, "GDP"],
CountryData[#, "GovernmentDebt"]/CountryData[#, "GDP"]},
CountryData[#, "Name"]] & /@ CountryData["Countries"],
PlotRange -> {{10^9, 2 10^13}, {0, 2}}]


There are a couple things one needs to understand for this to make sense: First is Mathematica’s syntax for pure functions, using all the stuff with the #s and up through the &. Second, the /@ is shorthand for the Map command, which means apply the function on the left to each element of the list on the right. Finally, the command CountryData["Countries"] produces a list of all the countries for which Mathematica has data.

1. He is, nevertheless, against the bailout.