Frustrations with the ACM contest

[Mike C]

Hi

If anyone else was involved with the ACM contest this Saturday, they
might agree/disagree with me on the following points.

I don't mean to sound like I'm on a rant, I had the same
advantages/disadvantages as everyone else, I just want to know if anyone
feels the same way.

First of all, I found dealing with stdin rather unnecessary, especially
given that our choice of language was restricted. It would have been
much simpler to work with data in the form of a function argument as
opposed to a line of raw text.

But I think my biggest problem was with the lack of sample data, there
were no more than two cases given for any problem. This wouldn't have
been a problem had the submission interface provided more detailed
feedback. For example, when I would submit a solution that was
incorrect, it would just say "wrong answer". This is especially
frustrating because my code worked for the few sample cases, and to the
best of my knowledge was correct. Had the interface provided information
about the test that failed, it would have been more helpful.

One might argue that this is bad software engineering practice (since
you should be getting it right the first time) but since we were being
penalized for each incorrect submission, so if help was given to the
coder they were paying for it.

Anyway, my kudos to the organizors of the event for putting it all
together, I'm sure a lot of work was put into it. Regardless of my
frustration, I plan to attend the next contest.

Also, thanks to DCS for the pizza.

-Mike

[David Warde-Farley]

Post by Mike C
If anyone else was involved with the ACM contest this Saturday, they
might agree/disagree with me on the following points.

Shoot! I completely forgot that the competition was today. I thought I
had another week or something. Anyway, sour grapes already eh Mike? :)

Post by Mike C
First of all, I found dealing with stdin rather unnecessary, especially
given that our choice of language was restricted. It would have been
much simpler to work with data in the form of a function argument as
opposed to a line of raw text.

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

br.readLine();

Voila.

Dealing with stdin in any of the chosen languages is fairly trivial,
actually (fgets/scanf, cin, and the above). And assuming your submission
was to be a fully fledged program, then the input text would have to be
changed in the source and recompiled every time it was run. Not exactly
feasible.

I suppose you could've been asked to write something that compiled to a
.o and linked against the rest of their sample implementation but that's
too much hassle when dealing with multiple possible source languages.
I'd say that stdin is more equitable to people who haven't done explicit
filesystem I/O programming but may well be capable of writing the
algorithm. Practically every programming intro involves reading
something from the keyboard.

Post by Mike C
But I think my biggest problem was with the lack of sample data, there
were no more than two cases given for any problem. This wouldn't have
been a problem had the submission interface provided more detailed
feedback. For example, when I would submit a solution that was
incorrect, it would just say "wrong answer". This is especially
frustrating because my code worked for the few sample cases, and to the
best of my knowledge was correct. Had the interface provided information
about the test that failed, it would have been more helpful.

Yeah, I've done competitions like this in the past and had similar
complaints. The best thing is to keep asking for clarification from the
overseers, I find.

[Mike C]

Post by David Warde-Farley

Post by Mike C
If anyone else was involved with the ACM contest this Saturday, they
might agree/disagree with me on the following points.

Shoot! I completely forgot that the competition was today. I thought I
had another week or something. Anyway, sour grapes already eh Mike? :)

Theres another one in two weeks

http://www.cs.toronto.edu/~igor/acm/next.html

[v***@gmail.com]

I attended the conference and had a nice time.

The new Scanner class in Java 1.5 provides a simpler input
functionality, compared to BufferedReader (Thanks to whoever wrote it
on the board there).

However, the following kept bugging me and I still need to figure this
out:

code like:

Scanner s = new Scanner(System.ini);
while (s.hasNext())
{
String str = s.next();
System.out.println(str);
}

printed out the string, but the pop-up input dialog box *just won't go
away*.
int input (...while (s.hasNextInt())..) at least exited the input
dialog box if invalid input was entered (like a string).

[Albert Yu Cheong LAI]

You may find it understandable that all the limitations follow
faithfully those of the regional and world final contests. (Most of
them ask you to read from a text file of a given name, but even then
the content format is exactly like what you have experienced.) These
even include the triviality of the sample data.

[David Warde-Farley]

Post by Albert Yu Cheong LAI
You may find it understandable that all the limitations follow
faithfully those of the regional and world final contests. (Most of
them ask you to read from a text file of a given name, but even then
the content format is exactly like what you have experienced.) These
even include the triviality of the sample data.

I suppose the triviality of the sample data is intended to separate the
boys from the men in terms of who cobbled together a solution based on
their muddy understanding of the test data, and those who rigorously
followed the specification. This of course necessitates the
specification being complete to begin with.

At one year's competition, a team programming tournament, we had no time
to debug our clearly incomplete solution, so we output a randomly
generated positive integer in what we figured was a reasonable range for
the cases we couldn't handle correctly. It guessed one right. That
earned us an extra 5 of 80 points or something like that for that
question. :)

Ah, good times.

[Daniel Wigdor]

Post by Mike C
But I think my biggest problem was with the lack of sample data, there
were no more than two cases given for any problem.

No doubt the ACM folk are smarter than the Durham Board of Education
organizers and this is not possible, but in case it helps: what my high
school team used to do was include a function call in every submission that
would write the test data to disk. That way, if a test failed, we could go
through their input and see what went wrong. Quite handy if your program
doesn't work right the first time.

D
---
http://www.dgp.toronto.edu/~dwigdor

Post by Mike C
Hi
If anyone else was involved with the ACM contest this Saturday, they
might agree/disagree with me on the following points.
I don't mean to sound like I'm on a rant, I had the same
advantages/disadvantages as everyone else, I just want to know if anyone
feels the same way.
First of all, I found dealing with stdin rather unnecessary, especially
given that our choice of language was restricted. It would have been
much simpler to work with data in the form of a function argument as
opposed to a line of raw text.
But I think my biggest problem was with the lack of sample data, there
were no more than two cases given for any problem. This wouldn't have
been a problem had the submission interface provided more detailed
feedback. For example, when I would submit a solution that was
incorrect, it would just say "wrong answer". This is especially
frustrating because my code worked for the few sample cases, and to the
best of my knowledge was correct. Had the interface provided information
about the test that failed, it would have been more helpful.
One might argue that this is bad software engineering practice (since
you should be getting it right the first time) but since we were being
penalized for each incorrect submission, so if help was given to the
coder they were paying for it.
Anyway, my kudos to the organizors of the event for putting it all
together, I'm sure a lot of work was put into it. Regardless of my
frustration, I plan to attend the next contest.
Also, thanks to DCS for the pizza.
-Mike

[Mike C]

Post by Daniel Wigdor
No doubt the ACM folk are smarter than the Durham Board of Education
organizers and this is not possible, but in case it helps: what my high
school team used to do was include a function call in every submission that
would write the test data to disk. That way, if a test failed, we could go
through their input and see what went wrong. Quite handy if your program
doesn't work right the first time.
D

Good idea

Since the code is run on a judges machine, it would be cool to set
something up with sockets so that my machine could recieve the input
data. I can't see that being against the rules.

[Albert Yu Cheong LAI]

Post by Mike C
Since the code is run on a judges machine, it would be cool to set
something up with sockets so that my machine could recieve the input
data. I can't see that being against the rules.

Aww please don't do that. You can blame me for not laying down all
the rules up front, but in the regionals and finals they have rules
specifically disqualifying contestants whose programs do network
connections or extra I/O. I cannot find you an online copy of these
rules, but every time I went to a regional or final I received a paper
copy.

[Mike C]

Post by Albert Yu Cheong LAI

Post by Mike C
Since the code is run on a judges machine, it would be cool to set
something up with sockets so that my machine could recieve the input
data. I can't see that being against the rules.

Aww please don't do that.

I won't, but only because you asked me nicely.