You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some contest control systems do not round the penalty for each problem to the minute but use some other penalty resolution.
The main option I have seen is to sum submission times with seconds resolution and round down to the minute at the end, but just using penalty as seconds also makes sense.
Also, some contests (e.g. Atcoder rounds) use last-submission time instead of sum-of-submissions.
I think it should be possible to specify these changes in the Contest object, a penlty_time is specified, not forced to be equal to 20 minutes.
So my proposal is, to add the following fields in the contest object:
problem_penalty_resolution it can be either an integer (in seconds or in milliseconds?) or enum (MINUTE, SECOND, etc).
total_penalty_resolution in a similar way
penalty_algorithm which is enum, whether sum or last, maybe some more options if someone comes up with them.
This change is easy to implement in CCS'es - they can just send objects correctly to them not making it configurable, if it was not. And reasonably easy to implement in scoreboard calculation.
Questions need to be accurate with:
We should decide if penalty_time is specified in minutes or in problem_penalty_resolution units. Both make sense to me.
The text was updated successfully, but these errors were encountered:
Contest penalty_time is the only time that's in integer minutes, and one of only 3 places where we even say minutes in the spec. As per issue icpc#150, it also blocks non-integer penalty times.
This changes it to use RELTIME, which improves both issues. It does not attempt to address anything else in issue 150, namely no attempt to add additional scoring algorithms.
Contest penalty_time is the only time that's in integer minutes, and one of only 3 places where we even say minutes in the spec. As per issue icpc#150, it also blocks non-integer penalty times.
This changes it to use RELTIME, which improves both issues. It does not attempt to address anything else in issue 150, namely no attempt to add additional scoring algorithms.
Some contest control systems do not round the penalty for each problem to the minute but use some other penalty resolution.
The main option I have seen is to sum submission times with seconds resolution and round down to the minute at the end, but just using penalty as seconds also makes sense.
Also, some contests (e.g. Atcoder rounds) use last-submission time instead of sum-of-submissions.
I think it should be possible to specify these changes in the Contest object, a
penlty_time
is specified, not forced to be equal to 20 minutes.So my proposal is, to add the following fields in the contest object:
problem_penalty_resolution
it can be either an integer (in seconds or in milliseconds?) or enum (MINUTE, SECOND, etc).total_penalty_resolution
in a similar waypenalty_algorithm
which is enum, whethersum
orlast
, maybe some more options if someone comes up with them.This change is easy to implement in CCS'es - they can just send objects correctly to them not making it configurable, if it was not. And reasonably easy to implement in scoreboard calculation.
Questions need to be accurate with:
We should decide if
penalty_time
is specified in minutes or inproblem_penalty_resolution
units. Both make sense to me.The text was updated successfully, but these errors were encountered: