Month: March 2008

Faculty Positions Down Under

Natashia Boland recently noted that I was the “very first to publicise” the fact that she was leaving the University of Melbourne to take up a Professorship at the University of Newcastle in Australia. I think that phrasing is her polite way of saying I jumped the gun in posting that she was leaving. To make up for that faux pas, let me do my part to make sure everyone knows she is hiring  faculty for her group. From the announcement:

The University of Newcastle (Australia) is embarking on an ambitious
programme of building research strengths in applied and computational
mathematics, including a particular focus on operations research/
optimization. Under the leadership of two new professors, Prof. Natashia
Boland and Visiting Prof. Jon Borwein, the University intends to create a
world-leading research activity. The University is now undertaking a
world-wide search for faculty to join the team.

I have not been to Newcastle, but it sounds like an interesting city:

The main campus is located in the city of Newcastle, on the coast about
two hours drive north from Sydney. The School of Mathematical and Physical
Sciences provides a stimulating and supportive environment for research
and teaching, with ample opportunities for collaborative research
partnerships both within the university and with industry. Although well
known for its beautiful beaches and pleasant climate, Newcastle is also
home to a significant port, and Australia’s largest coal-handling
terminal. Newcastle is also at the gateway of one of Australia’s largest
wine-growing regions, the Hunter valley. It is also home to top-class
medical and medical research facilities, affiliated with the University,
which is ranked 63 in the world for biomedical research. Thus
opportunities for research in shipping, transportation, mineral resources,
agriculture, health and medicine abound.

Interested? Check it out:

Applications received before Monday 28th April 2008 will receive full
consideration. To apply, please follow the instructions available at

http://www.newcastle.edu.au/service/employment/index.html

Look for position numbers 923 (Senior Lecturer) and 924 (Lecturer), as
appropriate.

Professor Natashia Boland
The University of Newcastle
Callaghan, NSW 2308
Australia
(currently best contacted at natashia@unimelb.edu.au for enquiries)

As I pointed out in my original post on Natashia, I think she chooses very good problems to work on, and I think she would make a great colleague to work with.

Disaster in the making, and averted

According to the New York Times, I am unlikely to be a successful researcher in my chosen field of operations research. The reason? No, not due to an insufficient mathematical grounding, or a fuzzy understanding of methods of symmetry breaking for integer programs, but rather due to a social effect: I like to drink beer. I particularly like to drink beer with other academics. Here at the Tepper School, there is a Friday Beer group that goes out at the end of every week, and drinks.. yes.. beer. At OR conferences, I am likely to be found in the bar talking with friends (and adversaries!), and have often evaluated a conference on the quality of that bar and those conversations. In fact, as President of INFORMS, I took it as a platform that people should drink more beer together (actually, I advocated a stronger understanding of social capital, but it is a rather thin line). But the New York Times, via a Czech ornithologist, says that is a problem:

What is it that turns one scientist into more of a Darwin and another into more of a dud?

After years of argument over the roles of factors like genius, sex and dumb luck, a new study shows that something entirely unexpected and considerably sudsier may be at play in determining the success or failure of scientists — beer.

According to the study, published in February in Oikos, a highly respected scientific journal, the more beer a scientist drinks, the less likely the scientist is to publish a paper or to have a paper cited by another researcher, a measure of a paper’s quality and importance.

Oh no! I still have aspirations to be OR’s answer to Darwin and Einstein. Am I ruining my chances by partaking in the golden nectar? Is having my “conference preparation” be limited to checking out the brewpubs in the area fundamentally flawed?

Fortunately, there are people out there who spend time debunking such myths, and lithographer Chris Mack was on the job. In a brilliant piece of work, Chris provides an excellent summary of what can go wrong in statistical analysis. He sees a number of problems with the analysis:

  1. Correlation is not causation. Perhaps it is poor research that drives one to drink (as alluded to in the Time article), or there is a common factor that drives both (a nagging spouse or an annoying dean, perhaps).
  2. There aren’t many data points: just 34, and the r-squared value is just .5
  3. The entire correlation is driven by the five worst-performing, and heaviest drinking, researchers.
  4. It is likely those five are drinking with each other, messing up the independence assumption of linear regression.

So, as Chris says:

Thus, the entire study came down to only one conclusion: the five worst ornithologists in the Czech Republic drank a lot of beer.

Whew! That’s a relief. The next time operations research gets together with lithography, I owe Chris a beer.

Thanks to, ironically, my drinking buddy Stan for the pointers.

P.G. Wodehouse approach to Modeling?

P.G. Wodehouse, creator of Bertie and Jeeves, Psmith, and countless other characters reeking of prewar (WWI, not Iraq) England, is one of my favorite authors (my favorite being Patrick O’Brian). When I am sick or down, or simply at loose ends, I love to get out one of my Wodehouse books and get lost in worries of stolen policeman’s hats and avoiding harassment by elderly aunts.

The Basildon Coder has an article entitled “The P.G. Wodehouse Method of Refactoring”. Now, refactoring is pretty important to a lot of operations research. In particular, for linear programming, the basis is normally kept as a sequence of eta-vectors whose application results in the inverse of the basis matrix. As the sequence gets long, there will come a time to refactor the basis matrix, reducing the eta sequence (see here for some details). What-ho! Bertie (or, more likely, Jeeves) has thoughts on this?

Unfortunately, not, but close. Refactoring in this context is “any change to a computer program‘s code that improves its readability or simplifies its structure without changing its results”, according to wikipedia. So when a computer program is built on over the years, at some point there is a wish to rewrite or otherwise consolidate the code so it is back looking new, ideally with the effects of all the changes intact. Of course, this is relevant to OR also. We often put together models that have been added on to, changed, and modified to within an inch of their lives. And at some point we would like to have the model “we should have written” in the first place. So there is a temptation to toss everything out and start again. In fact, I often recommend doing so in my classes. But that isn’t very good practice, according to contemporary work in refactorization:

Now, the first mistake to avoid here is the compulsion to throw it away and rewrite from scratch. So often when confronted with a vast seething moiling spiritless mass of code a developer throws his hands into the air and declares it a lost cause. How seductive is the thought that 31,000 lines of code could be thrown away and replaced with ~15,000 lines of clean, well-designed, beautiful code?

Sadly, that’s often a path to disaster. It’s almost a rule of the game. jwz left Netscape because he knew their decision to rewrite from scratch was doomed. Joel Spolsky wrote a rant about the same decision – in fact, the Netscape rewrite is commonly cited as a major factor in Netscape losing the first browser war.

The problem is that warty old code isn’t always just warty – it’s battle-scarred.

This is a very good point. Back before I found someone (Hi Kelly!) who could work with me on sports scheduling, doing all the hard work (and most of the inventive work), I tossed away my main sport scheduling models (embedded in thousands of lines of C++ code) two or three times. Every time, the first thing I lost was two months as I remembers why I had in some of the more obscure code conditions in the models. It was always nice to work with “new” code, but it would have been nicer to work with new, commented, code, which never quite seemed to happen.

So where does P.G. Wodehouse come in? When refactoring a large computer code, the author (the Basildon Coder, not Wodehouse) suggests putting up printouts of the code, greatly reduced. The resulting display gives a hint of where code problems occur: lines squeezed to the right are a sign of deep nesting in loops, dense mass is often overly-complicated code, and so on. And this reminded him of Wodehouse:

The first time we pinned up the printouts, I suddenly recalled a Douglas Adams foreword reprinted in The Salmon of Doubt. Adams was a great fan of P.G. Wodehouse, and explained Wodehouse’s interesting drafting technique:

It is the next stage of writing—the relentless revising, refining, and polishing—that turned his works into the marvels of language we know and love. When he was writing a book, he used to pin the pages in undulating waves around the wall of his workroom. Pages he felt were working well would be pinned up high, and those that still needed work would be lower down the wall. His aim was to get the entire manuscript up to the picture rail before he handed it in.

(Adams, 2002)

This actually seems like a pretty good way to write models, and to write papers. When I write a paper, I generally work on a sentence-by-sentence level, and only rarely look at a the big picture. So perhaps when you visit me next, I will have two sets of papers pinned to my wall: my current optimization model, and my current journal submission-to-be.

By the way, be sure to click on the illustration to get to the site of Kevin Cornell, who looks to be a very talented and humorous illustrator to me!

Green Supply Chains

Environmental modeling has been an increasingly active area of OR over the past few years (see the greenOR blog for many examples). As companies strive to do good, either for economic or other reasons, they are thinking more about environmental impact in all that they do.

ILOG has just announced a “Carbon Footprint” extension to its supply chain modeling software (which in turn is based on the software from David Simchi-Levi’s previous company LogicTools). InfoWorld is one site that has picked up on this:

In an effort to aid companies as they struggle to balance profitability and environmental responsibility, vendors are rolling out increasingly sophisticated tools. Among those vendors is ILOG, which this week released a Carbon Footprint extension to its LogicNet Plus XE supply-chain application. This remarkable tool serves a valuable function: It’s designed to help companies evaluate the impact that various supply-chain network configurations and transportation strategies would have on their carbon footprint.

David Simchi-Levi is quoted regarding a case of a company trying to decide how many distribution centers to have:

Using LogicNet Plus XE with the Carbon Extension, the company cranked out various scenarios that involved adding between two and seven new distribution centers. Turns out that moving to four distribution centers would have resulted in the highest costs savings. Thus, a company that wasn’t thinking about green metrics might have gone with that option.

The company found, however, that by going up to six distribution centers, it would have slightly higher costs (1.6 percent), but it would reduce transportation distances by 20 percent and overall carbon emissions by 11 percent.

Those results might come as a surprise: How could adding six more energy-consuming distribution centers result in less carbon waste? The answer: With the six-center model, the company relies more on trains for transporting goods inbound than it does on trucks to ship products outbound. Trucks have a significantly higher environmental impact than trains, according to Simchi-Levi.

I don’t know whether  a 1.6% cost increase is worth an 11 percent reduction in carbon emissions, but having the information makes it possible to make an informed decision.

This reminds me of work being done in robust optimization, of various forms.  David Ryan of the University of Auckland spoke two years about his efforts to devise airline schedules that are less susceptible to delays (I wrote on this in 2006).  He found that a very small cost increase allowed a huge improvement in the robustness of the schedules.  Many of these supply chain optimization problems are relatively “flat” with many near-optimal solutions (cases where there is only one optimal solution with everything much worse tend to have obvious solutions).  In such a situation, “secondary” issues such as environmental impact, customer perception, or robustness to variation in data take on a higher importance.

NSF Program Director Position Open

Stephen Nash’s term as Program Director for Operations Research at the National Science Foundation is coming to an end. The position is announced here, with a target date of looking at applications of April 1. The “Engineering Design” position is also open. I think this position is a very interesting one. The responsibilities (from the position announcement):

[Program Directors] solicit, receive and review research and education proposals, make funding recommendations and administer awards. They are also responsible for interaction with other Federal agencies, forming and guiding interagency collaborations, and for service to Foundation-wide activities.

I spent a number of years running Tepper’s Carnegie Bosch Institute, where we provided support for research on international issues in business. Even though the area was not my core interest, I found it a very rewarding period. So, in the interest of disclosure, I may throw my name in the hat for this NSF position (the main drawback is too much time away from my four-year-old son). I definitely encourage those interested to consider the position: we need as strong a voice for OR as we can get in this role.

Robert Sloan in computer science has a nice article on the joys of being an NSF Program Director.

Use OR for your NCAA Picks

Joel Sokol and his LRMC method have made their picks for this year’s NCAA College Basketball Tournament. Joel’s method is based on work he did with Paul Kvam on a “Logistic Regression/Markov Chain Model for NCAA Basketball” published in Naval Research Logistics. This approach agrees in part with the NCAA selectors in that the predicted final four are the four number one seeds. It disagrees strongly with some of the rankings though. It would not have put UNC as a number one seed at all, let alone the top number one seed, preferring Duke over UNC. The number six seeds, who the NCAA ranks, presumably, 24-27 or so, are ranked 16 (Marquette), 24, 26, and 34 (Oklahoma). My city’s Pitt Panthers, an NCAA 4, seed are only ranked 23rd by Sokol’s method. Perhaps the biggest difference is 11th seed Kansas State, who is 19th (4th seed) under LRMC.  Kansas State over USC is also the big first round upset.

More do OR and make money!

Francisco Marco-Serrano, author of the fmwaves blog pointed out another contest to determine a recommender system.  Unlike the Netfix contest, which might not end up with a winner, the MyStrands contest appears to guarantee $100,000, and all that is needed is an idea.  Again, this seems like a good opportunity for those in OR to use our approaches to attack these sorts of problems (it seems that CS “owns” recommender systems, for no obvious reason).

Hmmmm…. blog recommendations?  systems that allow faculty to rate students?  sabbatical destination recommendations?   What do I need recommended, and how can OR help?