Clustering is difficult only when it does not matter, Amit Daniely, Nati Linial, and Michael Saks, arXiv:1205.4891. […] this represents a move from worst-case complexity towards something more instance-based. The main idea here is that the only hard instances for clustering problems (under traditional worst-case algorithms) are ones in which the input is not actually clustered very well. Their definition of a “good clustering” seems very sensitive to outliers or noisy data, but perhaps that can be a subject for future work.

This paper really hit home for me. I have taught data mining quite often to the MBAs at the Tepper School and clustering is one topic I cover (in fact, research on clustering got me interested in data mining in the first place). I generally cover k-means clustering (easy to explain, nice graphics, pretty intuitive), and note that the clustering you end up with depends on the randomly-generated starting centroids. This is somewhat bothersome until you play with the method for a while and see that, generally, k-means works pretty well and pretty consistently as long as the data actually has a good clustering (with the correct number of clusters). It is only when the data doesn’t cluster well that k-means depends strongly on the starting clusters. This makes the starting centroid issue much less important: if it is important, then you shouldn’t be doing clustering anyway.

There are other operations research algorithms where I don’t think similar results occur. In my work in practice with integer programming, most practical integer programs turn out to be difficult to solve. There are at least a couple of reasons for this (in addition to the explanation “Trick is bad at solving integer programs”). Most obviously, easy problems typically don’t get the full “operations research” treatment. If the solution to a problem is obvious, it is less likely to require more advanced analytics (like integer programming and similar).

More subtly, there is a problem-solving dynamic at work. If an instance is easy to solve, then the decision maker will do something to make it harder. Constraints will be tightened (“What if we require at least 3 weeks between consecutive visits instead of just two?”) or details will be added (“Can we add the lunch breaks?”) until the result becomes a challenge to solve. I have not yet had a real-world situation where we exhausted the possibilities to add details to models or to further explore the possible sets of constraints. Eventually, we get to something that we can’t solve in a reasonable amount of time and we back up to something we can (just) solve. So we live on the boundary of what can be done. Fortunately, that boundary gets pushed back every year.

I am sure there is a lot of practical work in operations research that does not have this property. But I don’t think I will wake up one morning to see a preprint: “Integer programming is difficult only when it doesn’t matter”.

]]>I greatly enjoyed the workshop and thank Celso Ribeiro for organizing it and inviting me. It was a small workshop, with perhaps 40 participants, with a single track of papers. For the first time in years I attended every talk at a conference! Try doing that at INFORMS!

My favorite talk was given by Matteo Fischetti of the University of Padova. The talk, entitled “Erraticism in tree search” was a real eye opener in terms of my understanding of how branch-and-bound on integer programs performs in practice. I’m going to paraphrase some of the key points of the talk. None of the numbers in the following are exactly what Matteo presented, but this is close enough to get the idea across.

Here’s the setup: Matteo claims to have a new cut for general mixed integer programs. It is parameterized, so he can actually create 10 different versions of that cut. He downloaded the MIPLIB 2010 benchmarks and some other benchmarks he found, ran default CPLEX on them, and limited his test to hard, but not insolvable instances (tossing out all instances solved by default CPLEX in under 100 seconds or requiring more than 1000 seconds). This left a test bed of 38 instances.

When Matteo solved the testbed using each of the ten cuts (separately), he found something amazing: a single cut often greatly decreased computation time. The (geometric) average decreases over the testbed relative to default CPLEX for the ten different parameterizations were:

Parametrization | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |

Decrease | 12% | 14% | 25% | 4% | -0.50% | 32% | 15% | 12% | 6% | 33% |

Wow! These cuts are great! Cut 5 had a bit of an increase in time, but it turned out that cut was kind of a dummy. Cut 5 took a random permutation of the non-negative integer variables and added a constraint Σ xi ≥ -1. This constraint clearly doesn’t do anything: CPLEX throws it away during preprocessing.

But look at Cut 10. It decreased computation time by 33%. It is amazing! Cut 10 took a random permutation of the non-negative integer variables and added a constraint Σ xi ≥ -1. And that seems to work really well!

Hold on…. What’s going on here? In fact, each of the cuts is simply a random permutation of the variables and a redundant constraint. How can that have any effect?

CPLEX (as with Gurobi or any other solver) has a certain “randomness” in its operation. This is not random in the sense that the final answers are not optimal, but rather the exact operation of the algorithm may depend on things like the ordering of the variables. So, for instance, if a solution to a linear program has multiple optimal solutions, the exact solution reported can depend on which variable is first in the internal ordering of variables. And, of course, the exact solution reported can then affect the branch and bound tree (since different variables might have fractional values).

If you change the internal ordering of the variables, you can change the operation of the branch and bound algorithm. Adding the redundant cut changed the internal ordering of the variables, so the timing results could vary. Not every instance has this aspect. Some have relatively consistent computation time independent of the ordering. But some instances vary a lot based on the ordering.

This is insight 1: branch and bound timings may vary a lot due just to the random choices of the algorithm.

If your computation time is too long, try permuting the variables. If you see lots of variation in computing time, perhaps it it is worth running multiple instances in parallel with different variable orderings (or internal random number seeds) in the hopes that one instance will solve much faster than the others.

This makes me wonder how many past papers showing that an approach is useful are simply showing different (good) random draws from the search tree? And how many good ideas have been discarded due to “bad luck” from the random number generator?

But this still leaves a puzzle: almost *every* random ordering is better than default CPLEX. Does this mean that you should at least randomly generate an variable ordering? One gentleman at the conference, vibrating with excitement, thought he had the justification for this:

Since most of these instances come from real problems, perhaps there is something about the way people formulate problems that leads to problems with the solution code. As I code, I would normally generate all of one type of variable (say, the “x” variables), then the “y” variables, then the “z” variables. This must be messing up CPLEX. What a great insight!

That hyperventilating gentleman was me. And Matteo quickly and firmly showed that I was wrong. How could almost all of the orderings do better than default CPLEX? Look back, the hint is there…..

How did we get our instances? Let me quote myself:

He downloaded the MIP2010 benchmarks and some other benchmarks he found, ran default CPLEX on them, and limited his test to hard, but not insolvable instances (tossing out all instances solved by default CPLEX in under 100 seconds or requiring more than 1000 seconds).

In doing this, he biased the sample! Anything default CPLEX did well on (under 100 seconds), we threw out! So the sample was made up of things that default CPLEX did not do well on. It is no wonder that “Cut 1” had an advantage. If we had run all the instances on “Cut 1” and threw out anything it did well on, it would turn out the default CPLEX would do better than “Cut 1”. If you toss out instances that an algorithm works well on, don’t be surprised if it does poorly on the rest.

So this is insight 2: if you want to compare algorithms A and B, make sure the definition of the testbed does not depend on which gets label A and which gets label B.

I can’t tell you the number of times I have read computational papers that make the bias mistake. And I rarely noticed it. I will now!

Of course, Matteo doesn’t make mistakes like this in his work: this presentation was an extremely effective way of showing how easy it is to make this error.

I cannot do full justice to Matteo’s talk: there were many more insights and surprises. The associated paper (with Michele Monaci) is here. And if you get a chance to see him give the talk, do so!

After that talk, I will never look at computation in integer programming the same way again. That presentation alone was worth the flight to Brazil!

**Added 9/26: ** Matteo has kindly provided his slides, which are available here.

]]>