Important Instructions for Contests

Sep 21st, 2018
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.48 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 cases 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. Each and every problem should have at least 2 independently written codes which get AC.
  19. 3. 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.
  22. 2. Input File Formatting:
  23. Make sure that the formatting inside your input files are perfect. White-spaces matter for languages like Python while parsing it.
  24. 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.
  25. Your file should end with a new line. That is, there should be exactly 1 empty line at the end of the file.
  26. 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.
  28. This needs to be tested using the functions given in this dummy code:
  29. 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.
  30. 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.
  31. 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.
  32. This takes care of both asserting bounds and formatting.
  33. Note that the stderr page is accessible only by the problem setter, and co-authors.
Add Comment
Please, Sign In to add comment