您好。
对于这个问题，我想没有一定的规矩，就是“到什么时候为止最好做完什么事情。”和任何比赛一样，时间的把握完全是因人和因事情而定的。从这一点上，美赛和国赛也是很不同的。
事实上，美赛对于中国学生来说，英语的翻译写作和资料的查阅会占很多时间。与国内赛明显不同的是，美赛题目更加开放，需要学习很多知识。它应该至少被安排一天的时间。之后要及时的开始自己unique的工作，否则学习得再充分也会被认为是没有价值的。由于题目的开放性，队员可以自由选择适合自己的角度和方法，所以学习的内容和任务量完全是可以控制的。
另外，摘要的写作仍然十分重要。建议用最后的12个小时进行摘要和文章的修改。其他的细节应该因情况而定。由于没有人的工作会真正相同，所以完全可以有自信，不用完全依照别人的经验。自己采取的时间安排就是最恰当的安排。
我可以推荐您一个特等奖的time table。比较经典，可以参考：（请注意，这是以美国时间为参照的：）
-- 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
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.
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!
Sometime 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:
Sunday 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?
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!
Monday 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!
顶
斑竹谢谢了
他的摘要太晚写了
个人看法
好
这个time table花了这么多篇幅谈写论文，看来论文一定要下功夫写啊。
版主辛苦了
[em07][em07][em07][em07]
| 欢迎光临 数学建模社区-数学中国 (http://www.madio.net/) | Powered by Discuz! X2.5 |