As soon as you are marginally sure you have an idea of how to solve the problem you start hacking away Correct.
You use as few functions as possible, with as many global variables as possible You just should not try to add some artificial structuring and naming convention. You do what you do.
"asdf", or "dfjk" (easy to type). Not to this extent of course. You would not be able to read the code at all afterwards.
in giant global arrays of int's, each one of them bigger by at least a factor of two than it needs to be Dynamic data allocation is more convenient, especially if no limit on data size is implied in the problem. These guys in ACM do such things very often. This in nonsense at Russian regionals, and especially at Russian IOI (high school contest) regionals - all problems are absolutely correctly formulated, all input sizes and limits are specified.
You don't concern yourself with performance unless your first submission comes back with "Ran too long". Usually in contests like this one you don't have to concern yourself with performance at all, unless for example you have chosen a wrong algorithm that works n! time instead of n^2...
You don't concern yourself with stability unless your first submission comes back with "Runtime error". As soon as your program works on the sample input, you submit it. Nah, this is absolutely wrong. You can do things like this only in the very end of contest, when nothing can save your fate already. Usually in our team one thinks on the solution, and creates test data even before he gets to the keyboard. If no, some other member of the team creates test data. Testing rarely takes more than five minutes, while you save a penalty of twenty - that's a lot... However, sometimes you're just sure you couldn't have made any mistake... Then you can submit:))
Hi. I was the member of St.Petersburg team in the last 2 years (2nd and 9th place). St.Petersburg teams always use pascal, because it is times easier to find bugs in pascal programs under such a horrible time pressure.
Slashdot Mirror
As soon as you are marginally sure you have an idea of how to solve the problem you start hacking away
:))
// Oleg Semenov, St.Petersburg team 1998-1999
Correct.
You use as few functions as possible, with as many global variables as possible
You just should not try to add some artificial structuring and naming convention. You do what you do.
"asdf", or "dfjk" (easy to type).
Not to this extent of course. You would not be able to read the code at all afterwards.
in giant global arrays of int's, each one of them bigger by at least a factor of two than it needs to be
Dynamic data allocation is more convenient, especially if no limit on data size is implied in the problem.
These guys in ACM do such things very often. This in nonsense at Russian regionals, and especially at Russian IOI (high school contest) regionals - all problems are absolutely correctly formulated, all input sizes and limits are specified.
You don't concern yourself with performance unless your first submission comes back with "Ran too long".
Usually in contests like this one you don't have to concern yourself with performance at all, unless for example you have chosen a wrong algorithm that works n! time instead of n^2...
You don't concern yourself with stability unless your first submission comes back with "Runtime error". As soon as your program works on the sample input, you submit it.
Nah, this is absolutely wrong. You can do things like this only in the very end of contest, when nothing can save your fate already. Usually in our team one thinks on the solution, and creates test data even before he gets to the keyboard. If no, some other member of the team creates test data. Testing rarely takes more than five minutes, while you save a penalty of twenty - that's a lot...
However, sometimes you're just sure you couldn't have made any mistake... Then you can submit
Hi. I was the member of St.Petersburg team in the last 2 years (2nd and 9th place).
// Oleg Semenov
St.Petersburg teams always use pascal, because it is times easier to find bugs in pascal programs under such a horrible time pressure.