| Frequently Asked Questions
0. How are the programs graded?
There are no points for style: Only the result matters. The automatic
grader takes your source file, compiles it, and executes it against 4
different input files. Each time the output is compared with that produced
by the reference solution, which is provided by the person who wrote the
problem. You only mark points if your output matches the reference output
(no partial credit). It is possible to mark points on some input files and
get zero on another, just because they test for different things.
1. Do the problems require knowledge of a particular
(graphical or other) API?
No. All problems are exclusively file-based (the input and the output are
files) and are not interactive.
2. Is there a good way to prepare for the
MPR?
Obviously, taking a look at problems from the
previous editions wouldn't hurt. One thing that I could recommand,
because it has caused plenty of trouble (and heartbreaks) to many teams in
previous editions, is to make sure that you really master the file
input/output formatting options of your language of choice. Each year there
are teams that spend an absurd amount of time just getting their programs
to parse correctly the input files. In the heartbraking category, the extra
space at the end of output lines figures prominently.
3. Can I use the [insert name]
library?
Most likely the answer is No. For example, no, you should not try to use
the mathematical routines of OpenGL, Direct3D, or MFC in your code. You
cannot expect any non-standard library (I will check and post later a
separate note for STL) to be available on the computer that will be running
the automatic corrector (more accurately, output checker), or for the
project templates that the corrector will be using. Basically, single-file
(no separate header file) ANSI-strict C or C++, and Java JDK 1.2 are the
only safe choices.
In particular, Micro$oft's "enhancements" of Java and C++ are evil.
Using Windows libraries, in particular including the sinister
windows.h header, besides staining your soul and pushing you one
more step to the Dark Side, is an invitation for problems with the
automatic grader.
4. Should a team write all its programs using the
same language?
No. Members of a team can use different languages, but a team can only
submit one solution for a given problem.
5. What if I find a bug in a solution that I just
submitted?
Tough luck! Once your solution has been deposited in the drop box, we will
not accept a new submission from your team for that problem. Make sure that
everything (in particular, names of input and output files) is correct
before submitting your solution.
6. What are the most common dumb
mistakes?
Here are a few:
- Giving incorrect names to solution programs (incorrect team number is
the most common error). We will try to challenge the "production of
a better idiot" evolutionary process by making the drop-box system secure
(or "idiot-proof") this year;
- Expecting incorrect name of input files and/or giving incorrect names to output
files;
- Printing results to the console (DOS window) instead of writing them
to a file;
- Statically allocating a "large" array ("it should be big enough")
instead of doing a dynamic allocation once the data have been read from the
input file;
- (in C or C++) dynamically allocating an array that is "one too
short";
- Adding one extra space at the end of output lines;
- Not checking for limit cases: If the problem says that the input
string has at least one character, but not more than 1000," you can bet
that there will be input sets testing the lower and upper limits;
- Extrapolating from the data example provided.
Trust the text of the problem more than the examples, in
particular regarding input data formats and values. If the problem states
"words are separated by one or more spaces," it means that there could be 2
or 3 or more spaces between words, even if all the examples only show one
space. Don't expect object indexes (node indexes in a network) to start
from 1, unless the problem explicitely states so, etc.
7. What are the best team
strategies?
There are really two aspects to team strategy. The first one concerns the
sharing of work/responsibilities in the team. The second concerns the
choice of problems that the team will try to solve. On the first aspect,
all sorts of combinations work. Some teams have specialized members
(algorithms, coding, debugging), some work as 2 sub-teams of 2, other as 4
independent programmers, each working on a different problem (in this case,
it is often a good idea to present one's algorithm to another member of the
team to get feedback/criticisms before begining to code. One method that
does not work well is three or four programmer working together on the same
problem.
Some teams (all top teams) prefer to solve only the "big" problems (those
that bring more points), possibly with a time bonus. It is always good for
the moral of the team, though, to make some points on a simple problem or
two. For the middle-rank teams, there is no "best strategy". All
combinations have been encountered.
Also, do not forget that there is only one computer per team! Definitely
define rules within your team for access time to the computer. That will
avoid conflicts and frustrations late in the day where a team member
monopolizes the computer ("Just five more minutes! It's almost working!")
while the other cannot type or check their solution.
8. Can I have a look at
problems from previous editions?
Sure, but since Bishop's University (Quebec anglos) only joined the Race in
1999, all editions prior to that year only had french versions of the
problems:
|
