Announcement

IOI problems are here!

by bbi5291 on Aug 23, 2009 - 2:57:08 am UTC
  • (2/0)
I have begun to add the problems from past IOIs. This will probably be completed sometime within the next week. I am intentionally omitting interactive problems (these are difficult to set up right now; this will hopefully be fixed soon), problems for which I wasn't sure that the "official" solutions were actually optimal, and problems that already appear on the USACO training pages.

I know IOI seems a bit intimidating, but trust me, it is not as impossible as it may seem. Most IOI problems are far from trivial but in earlier years most of you should be able to get significant partial points on most of the problems (with a bit -- or maybe a lot -- of work, of course.)

Now, as these problems are being added in a hurry there wasn't enough time to fully check everything. I did not have time to write solutions to these problems, so I don't know how difficult they are. I will be examining submitted solutions and I may raise or lower the point value, or perhaps check/uncheck the partial score option depending on what seems fair. You can also complain if you think that the value is too low.

So far 11 of the problems have required custom judges (that is, it is not as simple as just checking if your output is the same as the judge output, so a different program is required to grade your output). And there are more to come. I had to write all of these and did not test them extensively. If your program seems to be giving correct output but it is marked wrong, or you think that the score you deserve on a testcase based on the grading info at the bottom of the problem statement is different than the score you got, tell me and I'll fix it. (Note that "judge output" can be misleading; in fact for most of these problems, if your program's output is the same as the "judge output" shown, it will be wrong.) Again, I will be monitoring submissions to try to catch these mistakes.

Finally, if there is something wrong with a problem statement (for example if the sample data was copied incorrectly) then obviously do tell so I can fix it.

Comments (Search)

Yay! How do you guys add problems? Does your judge not care about the exact name of each input/output file?

Are you allotting points based on relative difficulty of the problems?

Anyways, good job adding problems. :)

I have set point values based on how difficult the problems seemed to me; since I have not solved most of them I cannot really judge how difficult they are, but I peeked at the solutions.

Programs always read from stdin and write to stdout, we just redirect the input and output. Most of the problems have custom judges, as I remarked.

Ah. Very interesting. What I mean is your Judge has to decide which files to redirect, right? So does it just scan the files folder and matches .in files with .out files and tests, or does it do something special? (I mean normal problems that is.)

Nah... it's all stored in the database. More flexibility, less elegance I guess

Ah. I see, thus the folders and input files. But wouldn't it be a pain to weight/time limit each custom input files?

The time limit is the same across all test cases (and the weighting usually is too).
Most of the time I just use a script to make a list of the data. It's just that making things custom gives us the option of batching, custom weighting, etc.

Ah. I see. So when you want uniform data just use a macro or something, but leave the customization option available for other stuff. Neat. Thanks. :)

Yeah, I usually write a quick-and-dirty bash script like the following:
 
for i in {1..10}
do echo blah/blah$i.in, blah/blah$i.out, 10
done

The output is then pasted into the "Edit Problem" box, and this is internally parsed and stored in the database.

Ah. Very nice. Though I don't know exactly what the code does...I can guess a bit. So how long would you say you guys have worked on your Judge? It seems pretty advanced, with custom grading and contests and such.

Eventually, I'm going to set up a system in which stdin and stdout are actually named pipes, so as to unify (in the GUT sense, lol) batch and interactive problems. However, I predict that this will require some messy reconfiguration of the backend, so it's not happening any time soon. (I suspect that SPOJ does this, because Adrian Kosowski once told me that on SPOJ your program reads from a pipe - which is inconvenient if you use assembly.)

Pipes? In what ways are those better than just doing
g++ -o blah -O2 blah.cpp
./blah < input.in
?

Pipes are two-way (you can read and write) so interactive judges would be much easier to write.

Oh yeah...that was what we used to test the interactive ones...sort of a pain to get right until you get it right. Hehe. :)