Important Instructions for External Rated Contests

Feb 24th, 2019 (edited)
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.83 KB | None | 0 0
  1. 1. Test Files and Time Limits:
  3. For every submission submitted, the back-end judge on SPOJ gets occupied for a time, which is a product of number of test files and time limit of that problem. Let's call this product P. For example, if a particular problem has 10 test files, each with a time limit of 3 seconds, that would lead to a product of P = 30 seconds for which the judge could potentially be occupied.
  5. During rated contests, because of the huge number of submissions, even though we ramp up the number of judges, it gets overloaded if P is too high. And then the users end up having to wait for a long time for their verdict, and in worst cases has even led to contests being cancelled. So it is very vital that you keep this in mind.
  7. In particular, for Cakewalk problems, P should be 1. That is, a single file, with time limit of 1. This is very very important because the load is particularly high at the beginning of the contest due to everyone submitting the Cakewalks.
  8. For Simple, you should have P <= 4.
  9. For Easy, P <= 8.
  10. For Easy-Medium, P <= 12.
  11. For harder problems you can have upto 20.
  13. If you need to go above any of these limits, please get an explicit approval from one of our admins.
  16. 2. Input File Formatting:
  17. Make sure that the formatting inside your input files are perfect. White-spaces matter for languages like Python while parsing it.
  18. There should be no extra space at the end of a line. For example, if you are giving n elements of the array, you'll have a space after every element, but there shouldn't be a space after the last element.
  19. Your file should end with a new line. That is, there should be exactly 1 empty line at the end of the file.
  20. And generate the test files on an Unix machine (eg. Linux, Mac). Not on Windows. Because the differing newline characters messes up things in certain languages.
  22. This needs to be tested using the functions given in this dummy code:
  23. The functions should be self explanatory mostly. k=readIntLn(a, b); reads an int and asserts that the value is in [a, b] and that this int is followed by a Line Break (ie. this is the end of the line). Similarly, k=readIntSp(a, b); would assert that this int is followed by a space.
  24. Please write a code for each problem using the above template, which only takes the input using these functions, and outputs nothing. After submitting it, go to My Submissions. On the row corresponding to this submission, look at the first column. That is your SUBMISSION_ID. Now, go to the link of the form (For eg.
  25. Here, scroll down to the end, and you'll see the "STDERR:" section. For every data set (ie. every test file), you should see "SUCCESS" written there. If not, then there is some issue, and you'll have to fix them.
  26. This takes care of both asserting bounds and formatting. Send these submissions to the admin for each problem.
  27. Note that the stderr page is accessible only by the problem setter, and co-authors.
  30. 3. Each and every problem should have at least 2 independently written codes which get AC. Also, make sure to submit the different codes from different accounts. Not from the same account. So that it is easier for us to verify them. So, get access for the contest for multiple campus usernames, if you don't have them already.
  33. 4. At least one code for each problem should have proper asserts. That is, all the constraints mentioned in the problem statement should be asserted in the code.
  36. 5. After one of our admins have verified a problem, do not make any change in the testdata without informing them. In particular, once the contest has started, do not make *any* change without intimating and getting the permission of an admin. Do not rejudge any solutions once the contest has started without the admin's permission.
Add Comment
Please, Sign In to add comment