|
我可以推荐您一个特等奖的time table。比较经典，可以参考：（请注意，这是以美国时间为参照的：） Thursday evening-- Spend five or ten minutes reading the problems carefully. If everyone agrees which problem to do right off the bat -- go with it! The more fun and interesting the problem is to you, the easier it will be to work like hell on it. One of the hardest choices is if you have one problem which looks totally cool and one which is less interesting but you think you could do a better job on it. Given my own experience and that of people I know, I say go with what is most interesting -- you'll be more motivated, and you may surprise yourself. Remember, this contest is not about what you know at the beginning, but what you have taught yourself by the end. Spend about twenty minutes or so brainstorming. This means - Set a loose time limit.
- Appoint one person to write down all ideas on a blackboard. If each person writes down their own ideas then they become personal property. Instead every idea should be public.
- Get every idea you can think of on the board.
- Try to build on the thoughts of your team mates.
- No criticism or negative comments allowed! That's for later.
After brainstorming, go back over things in a more organized manner Break each problem into the three main parts: What are you modeling? What ideas for algorithms do you have? How will you compare the algorithms? Every problem has these three components, and you MUST be able to see exactly what they are. Without breaking down the problem, you can never get a foothold on it. Also, breaking down the problem into these standard pieces keeps you from neglecting a potentially important area. Spend some time discussing all three sections, and make sure you all agree on precisely what the three parts involve. 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. FridayOn 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! SaturdaySometime on saturday, the code should be ready to be turned over to the third for data collection. Complete debugging of the code will never happen until someone other than the programmer actually runs it. Hopefully by this time you will have played around with the code sufficiently to spot check your algorithms, but at some point you have to start generating real data which goes into the paper. 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 almost finished 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. One particular worry sometimes pops up at about this time: You've got your teeth into the problem a bit, you've got something running, and you've got some results, but you're worried that you haven't done anything that every other team hasn't done too. You may be concerned that you've only done the simplest, most obvious things to do, so there is nothing to set your team apart, nothing to really give you that extra edge in this grand competition. If you and your team find yourself worrying about this, I have three suggestions: - First and most importantly, whatever type of math you're doing, do it well, do it precisely, do it carefully, do it right, make sure that you understand this corner of mathematics at the deepest level, and then explain it so well and so clearly that the concepts just melt off the paper. The best papers are often ones that do something fairly simple, fairly basic, but they do things and explain things so carefully that it is obvious that they really understand the methods that they're using. That is the mark of a great paper: Use the right mathematical tool for the problem, and make it clear that you understand this tool inside and out, its strengths, its weaknesses, its limitations, why it is useful, and where it will fail.
- You will often find that your problem is a specific type of a general problem (e.g. a `knapsack' problem, an interpolation problem, a `traveling salesman' problem, a differential equation problem), and that a lot of smart people have worked on this type of problem so that there are well established methods for dealing with it. So learn these methods thoroughly, explain them well, and then customize them to your particular problem. Read the problem statement very carefully looking for the specific details and idiosyncracies that make your problem unique, that distinguish it from the general case. I think this is what really put my MRI team over the top: We recognized right off that we had an interpolation problem, so we hit numerical recipes and a couple of textbooks to bone up on what interpolation was and how it worked. Then we noticed that in the problem statement they said that they didn't want to blur out the boundaries between different types of tissue. So to customize our algorithm, we put together a method for finding these boundaries, and turned off our interpolation routines whenever they hit a boundary. I think that was what made our paper stand out from the crowd. We found the right tool (interpolation), we did our homework so that we could explain it in crystal clear detail, and then we adapted this method around the specific details of our problem.
- Of course it never hurts to strive for some real creativity. Saturday is probably a really good time to go back over your initial brainstorming and hunt for other methods and angles on the problem that you have not pursued. Get your team back together and try to do some more brainstorming from scratch. Try to see if your problem might fall into more than one general category: Could this be approached as either an interpolation problem or as a differential equation problem? That could make for a truly awesome paper if you could show how two very different mathematical tools could be adapted to the same particular problem, allowing you to compare and contrast their effectivness and their limitations.
Sunday MorningSunday morning, tie down the loose ends and GET THE FINAL DATA! Work on visualization, graphing, making pretty pictures etc. You MUST have virtually ALL the data that will go into the tables in your paper by Sunday at noon! 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? Sunday AfternoonOkay, 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! MondayMonday morning should be reserved for writing and rewriting the summary. If you agonized over every word of the rest of the paper, here you should be sweating blood! Find a blackboard and put your summary on it. Don't try to do this on a computer screen!! You MUST make the summary community property. Go over it and over it and over it. Make the summary a work of art, and try every possible way of structuring it that you can think of. Spend time discussing what should and shouldn't go into the summary. Remember, the summary is THE most important thing you will create. 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! | 
[复制链接]
IP卡
狗仔卡
发表于 2005-1-5 19:59
转播
淘帖
分享
收藏
支持
反对
微信
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
显身卡
发表于 2005-1-6 16:08
