R
Latex--，，，，
python--matplotlib绘制二维图形
Mathtype--公式编辑器

introduction to background information and history of the contest, more
information about each of the different problems and information about
the different types of interdisciplinary problems that are possible
http://www.comap.com/undergraduate/contests/mcm/Instructions.pdf

team members:
who is confident and experienced
with programming with one student who is confident they can lead
the writing effort for the team and a third student who can fill in different
roles and complement the skills of the others.
what matters is brainstorming and working together.

suggestions for prepration:
we do not focus on mathematical preparations during our training but
rather on interpersonal skills, community building, competition time management,
and brainstorming sessions for previous problems.
3 The Team
I’m including this section not because there is one right way to break up the responsibilities during that contest – that’s silly – but to try to get you to think about what role you will fill, what responsibilities you can assume: to show you one way to form a team that happened to work. This is how we broke things up when I did the MRI problem and it was very effective. When you tell one team member that their #1 reponsibility during the contest is to write the paper it assures that writing begins right from the beginning and that lots of time is spent on rewriting and revision – not just Monday afternoon! Assigning a team member to take charge of computer work can also be very useful. It is possible to do some problems purely on paper, but the MRI problem was one which demanded a lot of computer work, so if possible you should go in with at least one person ready to handle that area. Therefore I think this way of assigning roles is not completely arbitrary. Right now, think of what role you can fill, and how you can best prepare.
3.1 Computer Person
Most successful teams do a lot of computer work, and this was the role I filled in my second two attacks on the MCM. This could mean programming in a language like C++ or Java, or it could mean setting things up in Mathematica or Excel. If you’ve got someone on your team who knows how to program in C, that’s good. If not, use the skills that you have. Most complex models require a computer to make their predictions. The computer person must first implement the mathematical model so it is capable of making predictions, then set up the solution methods to tell the mathematical model what we are going to do, then deal with the resulting data and compare how different solution methods work out. You’ll never know what works or what doesn’t until you actually get through the third step in the process. This will often involve a HUGE amount of time in front of the screen. Before the contest, make sure that you know what computer tools you’ll be using, and that you’re comfortable with them. Books on numerical methods can be very useful, depending on the type of problem that you get. One very good one is called Numerical Recipes in C and the entire book can be downloaded off the web in pdf: http:\www.library.cornell.edu\nr\cbookcpdf.html Visualization is also very important. Make sure that you’re ready to make lots of plots and graphs, in Excel, Mathematica, or whatever you’re using.
3.2 Writer
The paper is what your team is judged on, period. If it’s not in the paper, it doesn’t matter. 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 pronouns: ‘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
10
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 criticism 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.
3.3 The Third
Writing is the cornerstone of every attack on the MCM, and computer work can be almost as important, there are many other important tasks. In order for a team to win, all three people must be working at their peak, so the third must look for things that need to be done. 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 implemented on the computer. Get to know Numerical Recipes and 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 collaboration all the way – everyone should write. Computer stuff – Are you good with computers? If not – learn! One of the best things any team can have are two people with good computer skills. When I did the MRI problem, I had one team member who started out not knowing C at all, but by the end that had changed. Get in there and learn as much as you can. 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 computer model must be frozen, and you need to start generating results. The model has been set up, and most of the solution methods are done, so it just takes a fair bit of time for all them to be tested and compared with all the methods. If your team is writing computer programs, and the programmer is the only one who
11
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 fill up the tables. 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. the code out of the programmer’s 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.
3.4 Teamwork
One dangerous pitfall that many teams fall into is that when a disagreement comes up, they vote, two people on one side, one on the other, the majority rules and the thoughts of the third person are ignored. Several times I have seen a team member frozen out in this way, who then feels disenfranchised and left out. Instead, decide right from the beginning that voting is off the table: No voting allowed. Instead, all decisions need to be made by consensus or not at all. If there’s a 2-1 split then you need to sit down and talk things through, and the two need to listen very carefully to the thoughts of the third, to understand where he or she is coming from, and to figure out what the other two are not seeing. It’s always important to spend time listening very carefully to your teammates. Usually the most talkative person ends up being the team leader, and more quiet students are more easily ignored. However being talkative has little to do with intelligence, and some very smart people are quiet and a little bit shy. You need to listen, to make sure that everyone is participating, and if someone on your team isn’t speaking up, it helps to specifically ask for your teammate’s opinion. As a general principle, I recommend that you avoid absolute language when talking with your team. Rather than using phrases like “This is it!” “This is right!” “This will never work!” that tend to close off issues and shut down discussion, it’s a lot more useful if you can phrase things cautiously and tentatively: “Maybe we should look at this.” “I dont see why this makes sense.” “Perhaps we could try that.” Cautious language opens up discussion, and encourages others to voice their own thoughts. During the contest you should never find yourself out of a job, with nothing to do, picking away at some peripheral detail that will never make it into the final paper. If you ever find yourself spending time on something that is not really important, not really contributing, then be sure to recognize this as a huge warning sign. A successful team must have every person spending every minute on something really vital. This goes especially for more junior members of a team. If you’re a freshman or a sophomore, and you’re on a team with an upperclassman or two, it may be harder to find ways to contribute, to stay in the thick of things, and to add important ideas when everyone else seems to be an expert on all this. You must keep yourself involved because there is far too much work for them to do this without you, or with you idling along at half throttle. If you find yourself in this situation go to your teammates and tell them point blank: “What should I be doing? How can I contribute?” If you’re a more senior member of a team, then don’t take everything on your shoulders. Work with your teammates and don’t be afraid to delegate. My biggest problem the second time I did the contest was that I tried to do everything important myself, carry the entire load, and
12
I utterly refused to ask my teammates to do anything really important. We got an honorable mention, but I know we could have done a lot more if we’d been working as a team, instead of me selfishly hoarding everything vital all for myself. So if you’re a freshman or a sophomore, what should you do? How can you contribute? What role should you play? First you must make sure that you understand the math that your team is using in every detail. Suppose your teammates come up with some really cool algorithm to solve the problem: Step one of explaining their ideas in the paper should be to explain things to you. Make them explain things until they become absolutely crystal clear. Remember you have probably the freshest perspective on things, so whether or not you are the official team writer, try to act as a gatekeeper for material to get into the paper. Look for things that don’t make sense, that are vague, that are fuzzy and unclear, and then make a big stink about it until the smoke is blown away. A freshman is in a great position to be the official team skeptic. Ask lots of questions, every question you can think of. Why did you do this step? What does this mean? Where does this equation come from? Your final paper should be written in much the style of a textbook, it should be written in order to teach someone about the methods that you used. Of course the best way to evaluate a textbook is to give it to a class of freshmen and see if they can understand it at all, or if the whole thing is just a confusing jumble of jargon. Don’t let your teammates snowplow you: If they can’t explain what they’re doing to you, they don’t have a prayer of explaining it in the paper.