The MCM is less about what you know or what classes you've taken, than about what you can teach yourself during the contest. It's more about creativity, writing, and working as a team. A team that creates a simple model, understands it well, and explains it clearly will generally beat a team with a more complicated, perhaps better model, that can't put their work into simple words.
Note -- I am personally biased toward the continuous problem, and I did the continuous problem all three years I participated. Most of what I'm saying applies to both continuous and discrete problems, but take everything with a grain of salt!
The summary must briefly hit all the main points and ideas of your paper. If you did anything creative, it must be here. Further you MUST put numerical results in the summary: "Our final algorithm performed 67.5% better than a simple greedy algorithm, and 123.3% better than a random choice".
Ideal summary length is hard. You must include all your main ideas in the summary, but brevety is VERY important. I would try to make the summary around half a page, definitely not more than 2/3.
The summary (and ideally the whole paper) should be written collaboratively: as a team. One way to do this is to have each person individually sit down and spend an hour (at least) writing the best summary that they can. Then, come back together and read the summaries out loud to each other (out loud is very important). After discussing them, set them aside and as a team write a new summary together up on a blackboard.
So what you need to do in the introduction is to clearly explain how you interpreted the problem, and what you decided to work on. It's also a place to give a little more background on the problem, and show what you learned while researching the problem.
The introduction can usually be written first as a friday project. It can help make sure that all the team members are in synch about what they are really working on.
In general, the modeling will occur on the computer, so the challenge is to translate the code into words, and justify each step. In order to create these models for continuous problems, I would recommend having a clear understanding of how to solve differential equations, however many C-problems have not involved this. For the animal population problems, you would want to be able to write differential equations describing the relationship between the predator and prey populations, then numerically integrate them. Know what a partial differential equation is -- know the wave equation and the diffusion equation and what they mean. With this knowledge in hand, the concrete slab problem would have looked almost like an old friend!
Remember, this is the mathematical MODELING competition, so do not gloss over this section. It may be simple -- for the grade inflation problem, this section would merely involve simulating the actual grades for a class, then using some method to skew them due to inflation. In general, for the discrete problem, you want to be familiar with how to generate random number sets with different properties -- this can be very useful in constructing the sets to test your algorithms with. The programmer should be writing the code to create these models friday morning, and so this section should be roughed out on friday or saturday.
You MUST have more than one solution. Let me say that again: MORE THAN ONE SOLUTION. In order to show that you have a brilliant method of finding submarines or cross-sectioning gridded MRI data, you need a baseline, something to compare your solution with. You want to start with the simplest, most obvious algorithm possible, then gradually build on it, refining it until get to your best solution.
Often for the discrete problem, the simplest solution may be merely to make random choices. For the meeting scheduling problem, you might want to have one algorithm which just randomly makes up the schedules. Then when you compare your better solutions with it, they look good!
You want to show that you've explored the problem thoroughly, and that you've tried many different approaches. Even if you started with your best algorithm, then tried a bunch of blind alleys, in the paper you want to present things as if you started with the dumbest most basic solution, then gradually refined it and finally arrived at your best solution.
What if you tried a more sophisticated algorithm, which didn't work well? Put it in the paper! Show all the angles you tried, even if your best solution is not the most complex and interesting one. In real life, that happens very often!
However, you usually have to make some decisions in how you compare the results of your algorithms. In the MRI cross-sectioning problem, you can compare your algorithms' estimate of tissue density with the actual density created by your models for each of the thousand or so points. But do you just average the variance? Maybe you should look at RMS error? Are you concerned with making sure that no point is drastically wrong or that the overall error is small?
With a lot of problems there will be many ways to compare your different algorithms, and there's good reason to use more than one method to evaluate them. Evaluation methods should be one area of brainstorming that you keep working on all weekend.
The specifics of data presentation are difficult. If you can make graphs, by all means do so. In the MRI problem, we made residual plots for each of our algorithms and each of our data sets. But ultimately if you've thoroughly explored the parameters of your models, algorithms, and comparison methods, you're going to have a huge quantity of numbers to present.
Give then the numbers from all your results in tabular format, but don't expect them to read the tables. You want to create a narrative in the text, going through the tables, pointing out the general trends, the exceptions to the rules, and the overall results.
IMPORTANT: Many teams create a model, a solution, run a test of their solution, present the results, and stop. You must run MULTIPLE tests! You must find out if your solution is stable! Will it hold up under slightly different circumstances? At this point your code is debugged and generating useful information -- take just another 20 minutes and run a few more cases, varying the parameters just a bit. If you're doing the Escaping a Hurricane problem, run your code with a few more cars, or a few less -- see how flexible your results are. If you're doing the MRI Problem, test your routines on several different simulated organs. If you're doing the Air Traffic Control problem, throw the planes at your simulated airport a bit faster, a bit slower, or take a runway out of comission and see how your program copes. Prove to the judges that your solution is flexible and stable, or honestly admit that your solution doesn't work as well against certain challenges. Your paper will look a whole lot better!
You need general numbers which summarize everything, so figure out a way to somehow average all the data and distil this into a few numbers which numerically rank the algorithms. The results section is where you say 'Algorithm A worked better in these circumstances, but B had the advantage when we did this.' In the conclusions section, you have to boil it down and say `A is best.' This is also what you will need to put in the summary, so be sure you get specific overall results.
Strengths and weaknesses is a great way to go over the key things -- explain the good and bad points of your algorithm. I like to use a bulletized list. Nothing new should go into S&W -- you are summarizing. The main points of your results section should be here, along with the shortcomings, and any limiting assumptions as well.
In order to show that you are mature in your approach to the problem, a future work section may also be useful. What would you do if you could work on this problem for the next few months? Were there any algorithms that you thought would be great, but just could not impliment on the computer? The MCM is very limiting, so this is a place to show that you can see the big picture.
We've talked about the summary (THE most important part of the paper), now what about the skim? Things that may get noticed are headings, bulletized lists, tables, diagrams, and figures. What you don't want are large unbroken blocks of text, they make the paper look boring, and may never be read completely. You want the words to be clear and easy to read, and the text to be broken regularly by headings, lists, figures, diagrams, anything you can think of to keep it interesting.
Summary
Make sure you all look at this outline and discuss it -- it will help you all stay focused on the same goal. When you're down in the trenches trying to code out some algorithm or analyze some data it's easy to lose sight of the big picture and spend several hours trying to do something that's not completely essential. By keeping the outline of your ideal paper in your mind, you can let the paper direct where you spend your time. There WILL be some things that you want to do that would look great in the paper, but may just be too hard to do for one reason or another. By working our your paper, even before you've worked out the solutions, you can stay focused and do only the work that needs to be done to make the paper look like it should.
Right now, think of what role you can fill, and how you can best prepare.
Make sure that you know what you'll be programming in, and that you're comfortable with everything. C/C++/Matlab/IDL/Fortran, whatever does the does the job. If you're doing the continuous problem, do some practice and get some templates built. Make up a little program that integrates an ODE with 2nd order Runge Kutta. Do you know what I'm talking about? -- If not, you should!
The bibles are Numerical Recipies and Numerical Methods that Work. These are almost certainly THE most important books you will ever use during the MCM if you're going continuous, and maybe even if you aren't. Diff EQ integrators, a whole bunch of interpolation routines, and just about anything else you might need. This is where you want to look when creating your algorithm. All the codes from Numerical Recipies are up on the web, so you don't actually have to type them. As practice, you should get at least one integrator and one interpolator running. Visualization is also very important. Make sure you've got good software for looking at your data sets. Again, this may or may not be important, but in the MRI problem it was key. MATLAB is great, as is IDL if they're available. Just make sure that you know how to plot out data.
The paper must be written very, very clearly. It must say things very simply and precisely. You do not need to make things sound complicated -- anyone can do that. Your program is already more than complicated enough. As writer, your goal should be to make everything as simple as possible. Don't write in that phony 'The data were collected.' style. Use personal pronounds: 'We collected the data.' This makes the writing much more active, and much less dry. Also, the key to interesting writing is often a good verb. If you've got a sentence that's dry and boring, try to find the action in it -- what HAPPENS! -- and try to find a good verb to rebuild the sentence around.
READ THE PAPER OUT LOUD! Let me say that again: read the paper OUT LOUD. You never know how things sound until you actually hear them -- it makes problems so much more easy to spot. If things are even the slightest bit confusing, then they must be changed. Remember, you're in the middle of the competition -- if you don't quite understand it, the judges won't have a clue.
In the end, I think that paper writing should be a completely team project, but someone has to take the lead. The writer's goal should be to create a thorough draft of the paper by noon on sunday, covering everything.
You must get everyone to critique every part of the paper, and one of the hardest parts is learning not to take that critisim personally. Writing without an ego is difficult, but that's what the MCM requires. As writer, you need to get chunks of the paper written, then circulate them around, get feedback, and go back and write again. Be comfortable with writing, and rewriting, and rewriting over and over again.
As preparation, you need to do a whole lot of reading. Read every MCM paper you can get your hands on, especially the outstanding ones. The outstanding papers in the UMAP Journal will have a judges commentary, which is EXTREMELY important. This is the only place where you actually get to look into the mind of the judges and see what they are thinking. After you read an outstanding paper, try to predict what the judges will say -- do your best to get inside the judges' heads! Get a notebook and jot your ideas down, looking for things that you like and things that you don't. You need to know what makes a good paper!
It's also probably the writer's responsibility to get familiar with whatever word processing package the final paper will be written on. Be sure you know how to do equations, headings/subheadings, bullet lists, etc. I'm partial to LaTeX, but Word has a good equation editor. Make sure you know the basics.
The first big hurdle is research. Find out as much as you can about the problem, and possible ways to solve it. To be useful in the MCM, research has to be very specific. Dig through math texts looking for specific things that can be implimented on the computer. Get to know Numerical Recipies & Numerical Methods that Work really well, and look for things you can use.
You should be involved in writing as well. Be a sounding board for what the writer has done, and make sure that everything is very, very clear. Everything should flow and sound completely natural. Don't just be a reader of course. This should be a colaboration all the way -- everyone should write.
Computer stuff -- Can you program? If not -- learn! One of the best things any team can have are two people who can program well. When I did the MRI problem, I had one team member who did not know C, but by the end he knew quite a lot. Get in there and learn as much as you can. If you can help with the programming/debugging, you definitely should!
If you know a bit less, then you need to be around for the data collection phase. Sometime on saturday (or sunday at the latest), the code must be frozen, and you need to start generating results to quantitatively support your work. The data sets have been created, and most of the algorithms are done, so it just takes a fair bit of time for all of the algorithms to be tested on each data set, and compared with all the methods.
If the programmer is the only one who actually runs the programs, then the team is in SERIOUS SERIOUS trouble. In the MRI contest, I worked at the programs until I thought they were running perfectly, then I gave them to the third, explained what he had to do, then told him to start generating data to support our work. Naturally, the code that worked perfectly for me broke within seconds for him, so I found the bugs and gave things back to him. After about three cycles of this the programs stopped bugging out, and we started generating usable data that ended up in the final paper. I think one of the most important roles for the third is to take the code out of the programmers hands and generate the actual data which will go into the paper. In my MRI team, all three of us ran the programs, although the writer had almost no programming experience to start with.
Spend about twenty minutes or so brainstorming. This means
Look for other, less generic ways to break down the problem. You want to chunk out the problem into managable pieces that can be attacked one at a time. Can you break the problem up using a timetable -- a certain sequence of events? What about different classes of strategies?
Identify whether the problem is well focused or very diffuse. If the problem is very big and broad then you have a lot of choice in what problem to do, and how to formulate this in mathematical terms. Later when you read papers from other teams, you'll be amazed that the teams weren't really doing the same problem! Remember this throughout the contest -- You are not only solving a problem, but creating the problem as well. When I did the submarine problem (the grand-daddy of all diffuse problems!) we formulated things in one way, then found that we couldn't solve it, and spent the rest of the contest banging around that blind alley. If it's very diffuse, there may be hundreds of possible problems that you can chose to solve -- chose the one that you can solve in the best and most interesting way.
That being said, some MCM problems are well focused and you don't have a lot of options -- there really weren't too many ways to approach the MRI problem. Right from the beginning, try to recognized how focused the problem is and what choices you have.
At this point you should make a tentative decision about which problem to do. If you focus on one problem the whole time then you will avoid wasting resources. The next step after deciding on the problem is research. Hit the library and find as much information as you can about all aspects of the problem. Get the resources and find out what is there and what needs to be read.
Each time I participated, I held the record for most consecutive hours without sleep. (I don't remember exactly how many I managed -- things got kind of fuzzy near the end.) But you know your own limits. This contest is about pushing yourself to the limits, but don't go beyond them. This isn't about making yourself sick! You want to focus every lucid moment of the day on the problem, but you also need to maximize the number of lucid moments you have!
After a jaunt through Numerical Recipies & Numerical Methods that Work, the programmer should start hacking out code -- either thursday night or friday morning. You have three huge subroutines to create and you need to get started as soon as possible. Usually the model, creating the data sets, can be done first -- get that running as soon as possible. Get a good head of momentum going and sit there programming solid for as long as you can stand.
On friday, the writer and third should begin with lots of research. Most MCM problems can be seen as specific examples of a general type of problem -- MRI was an interpolation problem, submarines and the concrete slab problem had partial differential equations. Find out what type of problem you're doing, and learn as much about it as possible. Go to school Read textbooks. You have to teach yourself everything you can on the subject. When we did the MRI problem, all three of us put each other through a short course in interpolation methods.
Papers work out best if you can use some established 'textbook-type' math to solve your problem. When I did the Velociraptor problem, I think our biggest weakness was that we failed in the research side of thing, and ended up having to create all the strategies ourselves. Later, in reading other problems I discovered that other teams had found ways to incorporate geometry, game theory, and differential equations into their solutions -- and the power of the established mathematics made these solutions incredibly effective. Sometimes it's obvious what kind of math you can use (interpolation methods for the MRI problem). Other times you will have to take some vaguely related area of mathematics, and shoehorn it into the problem, trying to make it fit as best you can. This should be a big research goal -- find something established that you can apply.
The writer should start on a draft of the introduction as soon as possible. If you get that done, keep going, rough everything out as thoroughly as you can. It is your job to keep in touch with the programmer -- make sure everything he/she puts into the code actually gets into the paper. Get everyone to read everything you write and get lots of feedback. By saturday, research should be over, and you should be rewriting and rewriting. This is all subject to the whims of the problem of course -- in the MRI problem, on saturday both the writer and the third were running the code generating final data because the paper was looking pretty good.
Keep in touch with each other! Don't get fragmented -- this is especially a danger for the programmer. Check in with each other every few hours and explain to each other what you are doing. If you feel like you aren't doing something important or that you are wasting time SPEAK UP! You are responsible for making sure that every minute of your time is spent on something vital! If it's not, then find something to do! This is VERY VERY important!
When I did the Velociraptor problem I had one team member sitting largely idle throughout much of saturday. The person was working, but not on anything which would go into the paper -- and I think this really hurt us. If you see this happening, take action! Don't be afraid to speak up and find something for this person to do -- You must use all your resources if you want to win!
Once you get your final results (reversing the freeways allows South Carolina to complete a hurricane evacuation 29\% faster), this is the point where you need to run a few more cases to demonstrate the stability of your work. Vary the parameters, the data sets, the number of airplanes, cars, or dinosaurs. Are your results very sensitive to these things, or do they not make much of a difference? It is very important to find out, and to show the judges that you've really put your model and solution through a thorough test.
Also on Saturday, my feeling is that the writer should be done writing. The bulk of the paper should be fleshed out by this point -- all the necessary ingrediants should be there. In order to see writing objectively, you have to look away from it for a while, so I advise the writer to go help with data collection for a while.
The hardest thing about this contest is knowing when to stop. You're involved in this because you enjoy a challenge. You want to do more than just turn in your homework and get a passing grade -- you want to really understand what's going on. You're tired of the wading pool: You want to swim in the ocean. But that means it will be very difficult for you to say ``This is far enough," to end your work, stop programming, stop making figures, and focus your whole team on serious writing.
At the end of the contest, all you will submit is your paper, and there's one secret to writing a good paper: Spend a lot of time on it. If you spend a lot of time writing your paper, it will be a good paper. If you spend only a little time, it will not.
So here's the hardest thing, perhaps the biggest challenge you will face during the contest: Can you set a deadline for Sunday at noon, when all work must stop, and everyone puts 100\% into writing the paper? Can you stick to this deadline? Can you stop when you are just ten minute away from some great new data? I have known only a few teams with the strength to hold this deadline, and they have all produced excellent papers. After you've written the paper together during Sunday afternoon/evening, you can go back and get those last few things, and add them to the paper. Think about this very carefully: Can you set this deadline? Can you stick to it?
Okay, in my opinion, here's what put my MRI team over the top and won us the outstanding. On Sunday afternoon we all stopped what we were doing, we read over the draft of the paper, discussed it a bit, and then we threw it away.
Together, we spent the next few hours writing our entire paper on the blackboard. The draft written by the writer at that point was very good, and it made sure that all the important ideas were in the air and that nothing was forgotton. However, no paper written by one single member of your team will ever be as good as a genuine collaboration.
We went through the paper from beginning to end, writing it all as a team, up on the blackboard. We argued over sentence structure and word choice, sweating over each phrase for several minutes, reading it out loud, trying to find a better way to say things. In some places, the existing draft was excellent, and we copied this up on the board -- but putting it on the board took it away from any one person and gave the paper to all of us. We filled up every chalkboard in sight, and that sunday afternoon/evening was what put us over the top.
When you're writing the paper like this, make sure you're all relaxed and comfortable, and don't try to get things done quickly so you can get back to your code. THIS is the single most important task you will do during the entire contest. Relax and don't be afraid to express your thoughts. Each of you should be talking, suggesting ideas, bringing up things you need to include, complaining that a sentence 'doesn't sound right.' If only one or two people are doing the talking, then something is seriously wrong. If any sentence sounds even the slightest bit confusing to you SPEAK UP! Each team member will have a very different perspective on things, and only together can you write a really good paper. Every sentence in the paper should be spoken OUT LOUD at least three times before you go on to the next! Also, regularly trade off who holds the chalk -- it helps keep everyone involved.
Okay, by the time you all crash on Sunday, you should have the entire paper worked out. You may or may not have the summary done, but the rest should be complete. Yes you might want to gather a little bit more data for your tables, or find a better way to make a picture of some data, but by monday morning, the contest is just about over -- programming should cease!
The summary should be done by 7:00 on monday -- three hours before the contest ends (adjust this for different time zones). At 7:00, all work on everything must STOP, and you MUST print out THE FINAL version of the paper. Just for the record the printer WILL JAM, the computer WILL CRASH, and everything that can possibly go wrong WILL GO WRONG on monday afternoon. The danger of losing the competition just because you could not get the paper printed out in time is VERY REAL. At 7:00 on monday, drop everything, and work as a team to get a final version of the paper printed out. After you have a final version, if there are one or two things you want to fix -- great, work right up until the end. See if you can make another final version (or fix a couple of pages), but do not even think about it until you have a paper which you could seal in an envelope!
Let's look again at the tasks your team must complete during the contest.
The most important of these goals is the last one. A well written paper with so-so models/solutions/data will usually trump a so-so paper with well developed models/solutions/data. So how do you make sure to write a good paper? I can give you lots of suggestions and ideas, but the reality is that it's mostly an issue of TIME. If you can sit down as a team with your paper, and spend 15 minutes or so on each paragraph -- read it out loud, look for things that aren't completely clear, talk about ways to rearrange it -- then you will end up with a top notch paper.
Let's talk about time a little more. When are you likely to waste time? When will you be rushed? Typically, on Friday and Saturday the contest feels very long and it's easy to waste a lot of time. The pressure will grow as Sunday passes way too quickly, and you will be incredibly rushed on Monday afternoon. You end up hurrying through the one task you should spend the most time on!
The roadblock that wastes all your time can often be task #3 -- trying to impliment your ideas on the computer. My team spent most of Friday, Saturday, and Sunday on that task when I did the submarine problem. When we finally did get something, it was already Monday. Even if we'd got glorious results, by Sunday night it's too late. We did not have time to spend on the paper, which was lousy as a result, and that's the trap: You spend all your time fighting the computer, so that when you do go to write the paper, you don't have enough time to write a good one.
So how do you beat the trap? In a way I was lucky that we beat it when we did the MRI problem -- I happened to know exactly how to impliment our ideas (thanks to Numerical Recipies), so that we had almost all the data we needed by the end of Saturday. The problem clicked with what I knew, so we had a huge amount of time to throw at the paper. You can't count on being so lucky.
In order to guarantee that you will have lots of time to spend on the most important goal, you need to set up harsh time limits on the other tasks, then stick to them as closely as you can. Make yourself stay up Thursday night and Friday night in order to meet the deadlines, so you don't have to stay up Saturday or Sunday nights -- which can be deadly.
To do well, you team needs to make Friday the most productive day of the contest by DEMANDING that things get done. One simple way to do this is to come up with your strategies as soon as possible, and insist that they be working on the computer by midnight Friday. If your programmer doesn't think he/she can get the code finished and running by Friday midnight -- then you need to make things simpler. This contest is about spending 96 hours on an 96 day problem. Make your programs quick and dirty, but get them working! Stay up Friday night and make sure the code is DONE before Saturday rolls around. If it's friday at 6 pm and you're not going to get the code done within the next few hours, then you're trying to do something too complicated. Regroup, do something simpler, but get that code working as fast as possible.
The trap is an issue of time, and if you're aware of it, you should be able to beat it. Do whatever it takes to make sure that all the research, the programming, and the data collection is DONE by Saturday night at the very latest, then get a good night's sleep. Even if it means rushing through things at the beginning, it's worth it to save the time for the paper. If your team can devote all of Sunday to the paper, then you've already defeated the vast majority of the other teams.
The art of using a library is a whole subject in itself, but I can give you a few tips. Once you've scanned through your own textbooks, make a list of the things you want to research and do things systematically. You'll most likely be looking for textbooks, not current research or conference proceedings. Remember: Keep it simple. Start with the basics. Find the general classification that your problem falls into, and learn as much as you can. Then try to creatively apply that knowledge to the specific problem that the MCM has given you.
All that being said, there are a number of books that do cover a lot of territory and have information that could be applied to many past problems. These books are generally about solving problems, often with examples of computer programs included to make your life easier. If you find any such books that might be useful to others -- please e-mail me and we'll add them to the list! (kline@carroll.edu)
Good advice from a university in Ireland
INFORMS -- One of the sponcering organizations
Nice page from University of Puget Sound, they've been continuously involved since '92.
Page from Eastern Oregon University, where I competed three times.
Page from Stetson University
Page from Grinnell.
Page from Tempere University.
A site on Mathematical Writing
Old papers: This is from a calpoly team in '97. And here's another from the same guy in '98.
A page from U Mass describing their involvement in the the contest.
kcline@carroll.edu