Teams from the California Institute of Technology and the University of
Nevada, Las Vegas will advance to the Contest Finals, to be held March 1,
1995 in Nashville, Tennessee.
A total of 36 teams participated, representing 23 different institutions.
In the chart below, "Number Solved" represents the number of problems (out
of six) correctly solved in five hours, "Penalty Runs" gives the number of
rejected runs submitted for problems that were eventually solved, and "Score"
is the cumulative time to solution for all solved problems in seconds
(including 20 minutes for each "Penalty Run").
Number Penalty
Team Name Solved Runs Score
--------- ------ ---- -----
1 Caltech #2 5 4 57180
2 Caltech #1 4 2 25368
3 UNLV #1 4 0 32868
4 UC Santa Barbara #2 4 1 51468
5 Harvey Mudd College #1 4 1 54048
6 UC San Diego #1 4 5 68688
7 UCLA #1 3 2 20736
8 Cal Poly SLO #1 3 0 26556
9 Cal Poly Pomona #1 3 0 33636
10 Cal Poly SLO #3 3 3 44016
11 Harvey Mudd College #2 2 0 11604
12 UC Irvine #1 2 2 15444
13 Cal Poly SLO #2 2 0 21564
14 Cal Poly Pomona #2 2 0 24204
15 CSU Northridge #1 2 1 34464
Marc K. Furon
Director, Southern California Region
ACM International Collegiate Programming Contest
[congratulations to the fifteen schools whose names I just deleted ;)]
How many people out there believe that students in programming contests
should be able to use whichever compiler they choose?
The reason I bring this up, is that I am going to be participating in the SE
regional contest this weekend. Myself and my teammates are very
unix-oriented (ie we dont even use DOS/Windows on our own PCs) and since we
are required to bring computers to this contest, we inquired into using
Linux for it (we run it on our machines). The response was no, because
National ACM mandates that we use Visual C++, Visual Basic, or Turbo Pascal
(yes I know its not an MS product).
I figure that the basic skills and concepts involved in programming
are independant of the system used, and that us using Linux would help level
out the playing field, so to speak (when everyone uses their favorite
compiler).
What do you all think?
--
-----------------------------------------------------------------------------
Bill Sirinek sir...@rex.cs.tulane.edu
Windows is not the answer. Windows is the question. "No" is the answer.
-----------------------------------------------------------------------------
> I figure that the basic skills and concepts involved in programming
>are independant of the system used, and that us using Linux would help level
>out the playing field, so to speak (when everyone uses their favorite
>compiler).
>What do you all think?
The problem is, letting everyone bring their own compiler makes
judging a logistical nightmare. There would have to be a matching
computer, operating system and language in the judging area for each
individual system the contestants bring.
--Mark
> [congratulations to the fifteen schools whose names I just deleted ;)]
> How many people out there believe that students in programming contests
> should be able to use whichever compiler they choose?
I'm not sure about the "whichever ... they choose" part, but I think
there should definitely be a better selection here.
> The reason I bring this up, is that I am going to be participating in the SE
> regional contest this weekend. Myself and my teammates are very
> unix-oriented (ie we dont even use DOS/Windows on our own PCs) and since we
> are required to bring computers to this contest, we inquired into using
> Linux for it (we run it on our machines). The response was no, because
> National ACM mandates that we use Visual C++, Visual Basic, or Turbo Pascal
> (yes I know its not an MS product).
I *think* that the majority of regionals are held on UNIX machines
(most of the seem to be Suns). That really makes me wonder about the
taking 50 steps backward and running the national contest on Windows
PCs. As far as I know, none of my team has even seen Visual C++, let
alone used it (anyone want to donate a copy ;-), so we have to spend
most of the next 3 months learning it. I'm really stuggling to not
comment on the use of BASIC (why are they trying to make us forget
that it is an acronym) for the National ACM Programming Contest
finals!
> I figure that the basic skills and concepts involved in programming
> are independant of the system used, and that us using Linux would help level
> out the playing field, so to speak (when everyone uses their favorite
> compiler).
I agree. However, they can't very well have people setting up their
own machines, and allowing Linux would mean having to allow OS/2,
386BSD, etc, etc. That works out to a pretty large number of possible
configurations, surely more than the ACM has resources to keep track of.
> What do you all think?
I think that nothing we say is going to change their mind. The evil
empire certainly won't yield, no doubt sure that once forced to use
VC++ we'll just buy 12 copies and use it forever (sigh).
Steve Lumos
UNLV ACM Student Chapter President
--
*<A HREF="http://www.unlv.edu/engineering/ACM/slumos/">Steve Lumos</A> *
*GCS d? H+>+++ s:++ g+ p? !au a- w++ v- C++++ US+ L>+++ P+>+++ 3- E+>++*
*N++>- K W--- M-- V -po+ Y+ t+ 5++ j R G? tv- b++ D--- B e+ u---(**) h *
*f r++ n+(----) y+ 2.1 "People with clue use OS/2!" *
National ACM mandates contestants use those at the finals or regionals
or what? If ACM requires contestants to use only those three
products, that is stupid. If true, I'd like to talk with whoever made
that rule and tell him/her/them a few things.
Unix boxes should be used at the contests, and there should be a much
richer set of languages available to contestants. As usual there
should be C, C++, and Pascal. But there ought be other languages
available such as Scheme (or maybe Common LISP), Prolog, Standard ML,
and Modula-3. Maybe also a few other languages such as Icon and
Eiffel. If a team has knowledge of several languages, they should be
allowed to choose the language to use to suit the problem. Doesn't
that just make sense? I mean if the problem calls for a lot of text
processing, pattern matching, etc. and a team is familiar with Icon,
why the hell should they be forced to use C or Pascal? The only
reasons I can think of is that contest organizers are too lazy or
they're not as knowledgable about programming as they should be. The
fact that Visual Basic is one of the language choices this year tells
me the latter is true at least.
Having more languages available will make more work for the judges,
but requiring makefiles with submissions would help with that. Since
some types of problems that have been used in contests in the past
might actually become trivial when certain languages are allowed, it
will be a little more difficult to create challenging problems.
Contest organizers will just have to deal with that. These days it's
just too easy for people to generate a question built around
implementing the ubiquitous arbitrary length integer arithmetic
package. We can be more creative.
My hope is that some teams would use other languages at contests, if
they are available, but I might be totally mistaken on this account.
It might turn out that even if 10 languages were available, still
nobody would use anything but C and Pascal. I think that's too bad,
and maybe ACM should investigate ways of promoting other languages.
Allen Condit
National ACM Member
con...@cs.unlv.edu.
The contest, overall, was great; the one thorn that I always disliked was the
fact the results of your submission (Accepted, Rejected<what_reason>) were
sent as a message rather than a mail.... You'd be typing, and the message
would pop up -- then disappear with the next keystroke. The Windows
environment didn't leave enough space for you to see the reason for a
program's rejection, either.
Quick Question... is it too late to file protests, or at least talk to the
chief judge about the contest? Our team is of the opinion that some test data
was used on one of the problems that didn't match up with the program specs,
and our coach is too happy with our other team's performance to care about
such trivialities....
=Michael Gaudet=
internet://mpg:engr.latech.edu voice://+1.318.257.2408
postal://box.4168.ts:ruston.la:71272 http://info.latech.edu/~mpg
That is a good point. But forcing people to use
DOS/Windows/other-similar-systems is not a good answer. it really
puts a great disadvantage on people used to and thus comfortable with
UNIX, which is the main OS used in universities for "real work"
(i.e. not dumb terminals, or app specific usages). For many people,
running on DOS is quite constraining and confusing. Many people do not
run/use DOS at all, including those owning PC's.
Making it run on UNIX/gcc or at least giving that as an option
would be nice. Even cc is okay if it is not a brain-damaged one that
chokes on ANSI or anything other than K&R.
Over the last decade, the Southern California contest has been run on VAXes, CDC
Cybers, PCs with MS/DOS, and UNIX machines of different types. The best teams
consistently do well, regardless of the environment. Generally contest problems
are not particularly dependent on any advanced features of one environment--they
mostly do simple reads from standard input and writes to standard output--so the
differences between environments are less important. We generally try to stick
with systems that provide ANSI/ISO compilers (except for the years with Turbo
Pascal).
: Making it run on UNIX/gcc or at least giving that as an option
: would be nice. Even cc is okay if it is not a brain-damaged one that
: chokes on ANSI or anything other than K&R.
Moreover, gcc doesn't exclude only-DOS-users : gcc has its DOS port (DJGPP) !
I don't even know whether I would have participated if we had to work
with DOS/Windows stuff. Would rather look like a crash contest, wouldn't it ?
(Oops. Who was sponsoring this contest ? ;-)
Greetings
Bruno
--
Bruno Van Wilder
University of Ghent, Flanders / Belgium
E-mail: Bruno.V...@Rug.Ac.Be
> Interestingly, the results in our region tend to show that the platform the
> contest is run on makes virtually no difference in the results! One might th
> that having experience on the platform used for the contest would be a large
> advantage, but history has shown this not to be the case.
> Over the last decade, the Southern California contest has been run on VAXes,
> Cybers, PCs with MS/DOS, and UNIX machines of different types. The best team
> consistently do well, regardless of the environment. Generally contest probl
> are not particularly dependent on any advanced features of one environment--t
> mostly do simple reads from standard input and writes to standard output--so
> differences between environments are less important. We generally try to st
> with systems that provide ANSI/ISO compilers (except for the years with Turbo
> Pascal).
Mind telling us exactly how one reads from standard input and writes
to standard output from the Windows enviroment? Maybe we can make a
(shudder) DOS program with Visual C++, but even that is impossible
with Visual BASIC! While I agree that experience with the platform may
not give a large advantage, I think you missed the "visual" part of
Visual C++. We are talking about an integrated enviroment here,
people who are familiar with the enviroment are going to be zipping
through compiles by clicking lots of icons while those who aren't are
going to be stuck searching. This is not a complaint, this is advice
to all of the teams: Get VC++ (I recomend BORROWING [legally] over
BUYING) and practice, practice, practice.
There are two things about the situation I dislike:
1) The luck factor is going to be through the roof, since we
have to use the crashiest operating *enviroment* on earth.
2) BASIC? I mean c'mon, BASIC?!
>Unix boxes should be used at the contests, and there should be a much
>richer set of languages available to contestants. As usual there
>should be C, C++, and Pascal. But there ought be other languages
>available such as Scheme (or maybe Common LISP), Prolog, Standard ML,
>and Modula-3. Maybe also a few other languages such as Icon and
>Eiffel. If a team has knowledge of several languages, they should be
>allowed to choose the language to use to suit the problem. Doesn't
>that just make sense? I mean if the problem calls for a lot of text
>processing, pattern matching, etc. and a team is familiar with Icon,
>why the hell should they be forced to use C or Pascal? The only
>reasons I can think of is that contest organizers are too lazy or
>they're not as knowledgable about programming as they should be.
I think you're being way too harsh, and that you really need to spend
some time on the organizing and judging end of a contest. It is a LOT
more work than I think you think it is. Plus, bear in mind that it is
all volunteer work. The organizers and judges are anything but lazy.
*************************************************************
mark schnitzius isx corporation schn...@east.isx.com
<a href="http://east.isx.com/~schnitzi/schnitzi.html">me</a>
|> Mind telling us exactly how one reads from standard input and writes
|> to standard output from the Windows enviroment? Maybe we can make a
|> (shudder) DOS program with Visual C++, but even that is impossible
|> with Visual BASIC! While I agree that experience with the platform may
|> not give a large advantage, I think you missed the "visual" part of
|> Visual C++. We are talking about an integrated enviroment here,
|> people who are familiar with the enviroment are going to be zipping
|> through compiles by clicking lots of icons while those who aren't are
|> going to be stuck searching. This is not a complaint, this is advice
|> to all of the teams: Get VC++ (I recomend BORROWING [legally] over
|> BUYING) and practice, practice, practice.
The "visual" aspect of Visual C++/Visual BASIC is indeed something the
Southern California regional contest staff has been wondering about. I've
not used those products myself (yet). One way to get around this problem
would be to do text file I/O for input and output. Also, is it possible
to redirect "standard input" from a text file in the Visual C++ environment?
I would think it should be, since there are existing applications that read
from standard input that one might like to work with...and standard output
could appear on a window opened by default for the purpose. (The Macintosh
C environment I worked with behaved this way.)
I'll know more when I get the product installed. I wouldn't like to see the
contest problems require a team to spend much time dealing with the Windows
interface.
By the way, all the teams that entered the Regional (I believe this is true
of all regions) have received/will receive a copy of Visual BASIC and Visual
C++, so the software will be available to everyone for practice.
|> There are two things about the situation I dislike:
|> 1) The luck factor is going to be through the roof, since we
|> have to use the crashiest operating *enviroment* on earth.
I don't have enough experience developing Windows applications to comment
about this.
|> 2) BASIC? I mean c'mon, BASIC?!
I can't say that this would be my first choice either. But one way to look
at it is that it's just another tool in the arsenal; and if it happens to be
the best suited for the job at hand, you can use it. How often would BASIC
fall into this category?
I read recently that over a million copies of Visual BASIC have been sold,
so I guess some people are doing development with it...
I must agree with this, based on personal experience. All members of
our team are anti-Microsoft advocates, one of us is even an anti-Intel
radical, and we only had about an hour of contact with VC++ prior to
the contest, still we got a 2nd place in the South-Central.
I have a theory to justify this: An emacs-gcc-gdb environment is much
superior for DEBUGGING; however, it's not any better than VC++ for
plain code entry. Since contest programs must work correctly as
designed or you'll lose anyway, improved debugging doesn't buy much.
--
Alex Ramos (ra...@engr.latech.edu) * http://info.latech.edu/~ramos/
> |> Mind telling us exactly how one reads from standard input and writes
> |> to standard output from the Windows enviroment? Maybe we can make a
> |> (shudder) DOS program with Visual C++, but even that is impossible
> |> with Visual BASIC! While I agree that experience with the platform may
> |> not give a large advantage, I think you missed the "visual" part of
> |> Visual C++. We are talking about an integrated enviroment here,
> |> people who are familiar with the enviroment are going to be zipping
> |> through compiles by clicking lots of icons while those who aren't are
> |> going to be stuck searching. This is not a complaint, this is advice
> |> to all of the teams: Get VC++ (I recomend BORROWING [legally] over
> |> BUYING) and practice, practice, practice.
> The "visual" aspect of Visual C++/Visual BASIC is indeed something the
> Southern California regional contest staff has been wondering about. I've
> not used those products myself (yet). One way to get around this problem
> would be to do text file I/O for input and output. Also, is it possible
> to redirect "standard input" from a text file in the Visual C++ environment?
> I would think it should be, since there are existing applications that read
> from standard input that one might like to work with...and standard output
> could appear on a window opened by default for the purpose. (The Macintosh
> C environment I worked with behaved this way.)
I only hope it is possible. Doesn't a system like this make things
much more difficult for the judges though? We had some really nice
working scripts for the contestant side of the contest, I assumed that
the judges had something similar. Does anyone know yet what the
submission/judging software is going to be like?
> I'll know more when I get the product installed. I wouldn't like to see the
> contest problems require a team to spend much time dealing with the Windows
> interface.
That is exactly what I'm worried about. From what I understand, VC++
and TP/W don't even have a command line style interface. I know that
Visual BASIC doesn't.
> By the way, all the teams that entered the Regional (I believe this is true
> of all regions) have received/will receive a copy of Visual BASIC and Visual
> C++, so the software will be available to everyone for practice.
We were there and recieved Visual BASIC. Any word when VC++ will be
coming? It could save us the trouble of scrounging up a copy somewhere
else so we can start practicing.
> |> There are two things about the situation I dislike:
> |> 1) The luck factor is going to be through the roof, since we
> |> have to use the crashiest operating *enviroment* on earth.
> I don't have enough experience developing Windows applications to comment
> about this.
Trust me ;-)
> |> 2) BASIC? I mean c'mon, BASIC?!
> I can't say that this would be my first choice either. But one way to look
> at it is that it's just another tool in the arsenal; and if it happens to be
> the best suited for the job at hand, you can use it. How often would BASIC
> fall into this category?
> I read recently that over a million copies of Visual BASIC have been sold,
> so I guess some people are doing development with it...
When you get it installed, you will see this, but the point of Visual
BASIC is that anyone can write Windows programs with it. The idea is
that you drag and drop your way into an interface (and more, you can
drop a spreadsheet or database access in) and then write somewhere
between very little and no BASIC to finish it off. Many of those
million copies went into developing cheesy Shareware applications.
True story: Shortly after Visual BASIC came out, I saw a file on a BBS
with a description like:
Real Windows application! Tell you the day
that Easter will fall on. Shareware: $15.
Requires VBRUN.DLL.
But I guess that's getting a little off track. The point is, while
Visual BASIC definitely has its place (which is Q&D in-house apps,
mostly dealing with database access), I doubt it will be much help
with the kind of problems you find in a national programming contest.
I'm not saying that having it available is going to hurt any team's
effort, but neither will it be very helpful. The thing is, doesn't it
make us look just a little bit silly? Here I was surprised (not really
bothered, just surprised) that FORTRAN was not available at the
regional.
BTW, I for one thought that the Southern California Regional contest
was run really well. I won't mention the specific snags involved, but
I wanted to say that none of it seemed to bother our team except where
it gave us more time to build up our own anxiety levels ;-) Anyway,
thanks to all of the staff who worked so hard for all of us lowly
students ;-)
--
*<A HREF="http://www.unlv.edu/engineering/ACM/slumos/">Steve Lumos</A>*
*GCS d? H+>+++ s:++ g+ p? !au a- w++ v- C++++ US+ L>+++ P+>+++ 3-E+>++*
> I must agree with this, based on personal experience. All members of
> our team are anti-Microsoft advocates, one of us is even an anti-Intel
> radical, and we only had about an hour of contact with VC++ prior to
> the contest, still we got a 2nd place in the South-Central.
As someone who now has experience with the enviroment, would you mind
sharing some of the things that you DID find that were different. Was
compiling, etc fairly intuitive? Was it as automatic (I mean knowing
what to hit/type/whatever) as things you were more used to?
The only other question is: Were there teams having to reboot often,
and do you think it made a difference in the final outcome?
> I have a theory to justify this: An emacs-gcc-gdb environment is much
> superior for DEBUGGING; however, it's not any better than VC++ for
> plain code entry. Since contest programs must work correctly as
> designed or you'll lose anyway, improved debugging doesn't buy much.
> --
> Alex Ramos (ra...@engr.latech.edu) * http://info.latech.edu/~ramos/
--
This is not a strong argument. From Visual C++ (2.0 beta):
File -> New -> Project -> Type == Console Application
read from standard input:
cin >> i;
write to standard output:
cout << "Hello, World!\n"
I'm not a great fan of MS-Windows; much prefer my X11. I just happen
to be working on something with my brother in this strange environment.
The tools aren't all THAT hard to pick up, although I see where a
little hesitation multiplied many times in a timed contest might be
your undoing.
--
Joe Yao js...@cais.com - Joseph S. D. Yao