This conversation reminds me a lot of one we had at our last team meeting. The outcome was this: that we want to make it harder, but not impossible, to download the Large when you haven't solved the Small; and that we don't want to change the user interface in the middle of this year's competition, because it could easily cause more confusion than it saves. So it's a great idea, and we have a couple of possible UIs in mind, but we're going to save them for later.
On Sat, Sep 19, 2009 at 10:52 AM, Carlos Guia <[email protected]> wrote: > In my opinion, not knowing if you solved the small correctly hardly sounds > acceptable, that information can be found in 3 different places > - The submission box > - The scoreboard > - The "your last ..." message on top of the pages > > I understand pressure makes us unable to think right, but this contests do > measure how you behave under pressure. > > Also think about this situation: there are only about 5 minutes left of > competition when you finish a problem, solving the small won't get into > qualifying positions but the large will, you think you have the right > solution, you have to go for the large now, it's your only hope. > > Carlos Guía > > > > On Sat, Sep 19, 2009 at 12:17 PM, Blub <[email protected]> wrote: > >> >> >> Yeah, having a solution for the small input does not mean it also >> works for the large input. >> I agree that this is very similar to real live and don't oppose >> against making it part of the contest to >> let the competitors estimate the usability of their large input code >> without beeing able to test ist. >> >> However, in my case, the code at first did not even work for the small >> input. I overlooked that I failed >> on the small input and tried the same code on the large input. Later >> on, when I realized that my code was >> buggy, I wasn't able to resubmit the large input file. >> >> Unless it should be also part of the contest to avoid such stupid >> mistakes, I see two solutions to improve the situation: >> >> 1. A warning, when you try to submit code/output file for the large >> input when you havn't solved the small input first. >> 2. Entirely revoking the possibility to submit for the large input >> unless you have solved the small input first. >> >> >> >> >> >> On 15 Sep., 12:17, rahul chhabra <[email protected]> wrote: >> > One more point, I have previously read in this group mail is:- >> > Our applications if they are working for small data set does not mean >> > that they 100 % also work for large data set. >> > So, this is exactly simulation of real-life scenarios. >> > If you don't take care, application is gone. >> > >> > On Tue, Sep 15, 2009 at 12:46 PM, ulzha <[email protected]> >> wrote: >> > >> > > The idea of not allowing resubmit is exactly that - are you or are you >> > > not able to write correct programs without being assessed by an >> > > oracle. >> > >> > > In real life, you do not want to throw together a quick and elegant >> > > system and deploy it to hackers for intrusion. You do want to cover >> > > each and every breach by QA already. >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-codejam" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-code?hl=en -~----------~----~----~----~------~----~------~--~---
