Change the total number of submissions to the number of submissions p… #2722
Conversation
|
I'm not very familiar with Twig, but I believe there would be a more efficient approach in terms of time complexity if implemented in the controller. However, given the scale of the competition's data, the difference may not be significant. |
Optimize time complexity
|
|
This is from this year's finals: I wonder how this would look with log scale (I tried making that work but didn't succeed, perhaps someone else has an idea). There is another minor thing we might want to improve: in case the contest duration is not just 5 hours, but say 1 week or even more we create too many data points. We could decide to always use a fixed number of buckets, e.g. 60 - in a 5h contest this would group things together in 5min buckets. That should work well for most contest durations. |
I think the number of buckets can be fixed, and it's not difficult to change this. Should we make this change in this PR itself? Or should we discuss it later? I feel that 60 might be a bit too few. |
|
If it's going to be buckets (whether they're gonna be 1 minute or 5 minutes or some other size), maybe a bar chart would work better than a line graph? There's no continuity between each subsequent pair of buckets 🙂 |
I think this is a good approach, although in very dense situations, these two charts might look quite similar. |
|
I'm fine with doing the bucketing in a separate PR as this is already an improvement. I also wondered what a (stacked) bar chart might look like. Do you want to give this a try now or later? |
Since I'm not sure if the bar chart would be better, I'll implement the bar chart version in another branch and then submit a PR for you to compare the differences. Does that work for you? |
|
👍 |
| }, {}); | ||
|
|
||
| submissions.forEach(submission => { | ||
| let submission_minute = Math.round((submission.submittime - submission.starttime) / 60); |
There was a problem hiding this comment.
Small detail: this should not be rounded, but the floor taken. A submission at 57 seconcs into the contest is in minute 0, not minute 1. Above contest_duration_minutes should be taken the ceil though, to make sure that 0 <= submission_minute < contest_duration_minutes always holds.
There was a problem hiding this comment.
If a contest lasts 300 minutes, can a submission be made at 299 minutes and 59 seconds? Is it possible to submit during the 300th minute? If not, then should contest_duration_minutes be taken as the floor (rounded down)?
There was a problem hiding this comment.
Oh, sorry, I understand now. It was my mistake.
| @@ -388,7 +409,7 @@ nv.addGraph(function() { | |||
| .showYAxis(true) //Show the y-axis | |||
| .showXAxis(true) //Show the x-axis | |||
| .forceX([0, {{ (current_contest.endtime - current_contest.starttime) / 60 }}]) | |||
| .forceY([0, {{ submissions|length *1.10 }}]) | |||
| .forceY([0, {{ max_submissions_per_minute * 1.10 }}]) | |||
There was a problem hiding this comment.
Maybe I overlook something, but where is max_submissions_per_minute ever updated?
There was a problem hiding this comment.
That was my oversight. I've fixed it.
I think a bar chart would be clearer, but I'm fine with doing that in a second iteration. |
|
Do I need to squash them to a single commit? |
Preferably yes, at least for bugfixes. You can do that either locally with |
…er minute. Beta Optimize time complexity. fix count miniute edge bug
Tracking issue
issue
Description
Change the cumulative number of submissions over time to the number of submissions per time interval.
Screenshots