Judging the Southeast Region

Here it is – the 2013 Southeast USA Regional Division 2 problem set. You can download the text from here.

Note: For security reasons, the blog won’t upload files with a “.py” extension. The Python programs have extension “.txt”, which will need to be changed to “.py”

Here it is – the 2013 UChicago Invitational problem set. You can download the text from here.

A Russian contest is going to use this problem set in about a week, so we can’t post the data to the public just yet. I’ll post the usual problem breakdown in about a week, but for now, here’s the problem set & data for the UChicago 2013 Invitational contest. The data is encrypted and password protected, so that only participants can see it.

Problem set: UChicago Invitational 2012 Problem Set

Data: data

Here it is – the 2012 Division II problem set. You can download the text from here.

Here it is – the 2012 Division I problem set. You can download the text from here.

This post is for general discussion of the organization of the North American Super-Region, and questions of how the super-regional organization might be changed to encourage more participation, give more teams a next-level contest experience, and improve North American performance.

Here it is – the problem set. You can download the text from here.

Here is a video of a webcast of the Chief Judge (me) discussing each of the problems in the 2011 problem set. The original lecture was given at Georgia Tech on Thursday, 11 November. The video is about 90 minutes long. The real content starts at about the 2 minute mark.

[flv:http://vanb.org/ser2011/vanb_ser2011_lecture.flv X 640 480]

In the problem statement for Vive la Difference, we make the claim that if all four numbers are less than 2^n, then it will converge in no more than 3n steps. This PowerPoint presentation outlines a proof.

Here it is – the 2011 problem set. You can download the text from here.

sundaydrive.java

Here’s the Call for Problems that was recently sent out to all SER coaches and Problem Selection Committee members:

Summer is upon us, World Finals is over, so it’s time to start thinking, just a little bit, about the Southeast USA Regional Programming Contest. It’ll be a little bit earlier this year, on Saturday, 29 October. So, spend your summer dreaming up programming problems! Also, we’re looking for people to serve on the Problem Selection Committee. Putting together the problem set for SER is an intense, rewarding process. If you’re interested, send me an e-mail (at vanb@biltmorecomm.com).

As usual, the Problem Selection Committee will be responsible for putting the problem set together. The PSC will also be responsible for judging, so problem providers won’t have to judge. Because of this, you can provide a problem, and also coach your team, and attend the contest with them at your chosen site. Anyone can submit a problem for consideration – however, although a problem submitter can also act as a coach, they cannot be a contestant, whether or not their problem is chosen for the set. In other words, if a student submits a problem, they are ineligible to compete.

Candidate problems should be e-mailed to me (at vanb@biltmorecomm.com). A statement of the problem is all that’s necessary, either in text or in MS Word format (right in the e-mail is fine). If you wish to include a solving program and/or test data, that’s very, very helpful, but not necessary. If you have a rough idea and want to talk about it, feel free to e-mail it to me, and I’ll be happy to work with you.

Problems should be sent by Friday, 9 September to be eligible for consideration. That’s the Friday after Labor Day. I’ll remind you again, but I’m sending out the call for problems early, to get you thinking!

Below you will find an excerpt from the Call for Problems issued from World Finals this year. It’s a good set of guidelines for candidate problems. If you are thinking of submitting a candidate problem for Southeast Regionals, you should read through it. I will add a couple of constraints of my own:

1. The problem should be original. It should not be a restatement of a problem that has been used previously in the Southeast USA, or any other ICPC regional, World Finals, or other contest environment such as TopCoder or Google CodeJam. It also should not come from a book, such as “Programming Challenges.” If it has its own Wikipedia page, then it’s too well-known.
2. The output for any given input should be unique. Try to add constraints to your problem so that there is exactly one answer for each input case.

Don’t forget about the blog to talk about judging at our contest. It’s at:

http://serjudging.vanb.org

Feel free to drop by and give suggestions – however, do NOT post candidate problems on this site. It is open to everyone, including students. Any problem posted on the site cannot be used in the contest.

————- Some excerpts from the World Finals call for problems: ————-

Problem Statements

1. Each problem must be unambiguously described in English.
2. All problems must require input.
3. Unless the core of the problem is input/output related, the formats chosen for input data and the displayed results should be relatively simple. Still, the format of the input data and the appearance of the expected displayed results must be described in suitable detail.
4. Multiple data sets testing different cases are appropriate; make the problem statement include iterative data sets as input to avoid using separate input files.
5. Anticipate questions about special cases. Where appropriate, explicitly state that certain special cases will not appear in the input data. It is not necessary to specifically identify the special cases that will appear.
6. Indicate the precision that is required for real results.
7. Contestants must write solutions for problems in a short time. While very simple problems are not appropriate, neither are problems that require a great deal of code; a few hundred lines of Java or C should be an upper limit on what can be expected in a solution.
8. The program and chosen test data should not require excessive execution time. Contestants’ solutions may be less efficient than yours and so a generous margin is allowed for execution. If your test data requires the program to execute for a long time, then incorrect student solutions (e.g., those with infinite loops) will take an excessively long time to judge. We would like to avoid those situations.
9. The problem description (excluding sample input/output) should generally require at most one page.

Submission of Problems, Solutions, and Test Data

1. Use electronic mail and send all files as either MS Word document, or flat ASCII.
2. Do not put your name in documents, or the body of e-mails, containing the problem statement, solution, or test data. This will simplify the transformation from your form to the one used for ranking.
3. Be discreet about problem statements and solutions. It is not appropriate to discuss problems with people not involved with the contest.

This post is to discuss our outreach to schools that are not currently participating in regionals. More content forthcoming, as soon as the minutes are available.

This post is to discuss our outreach to high schools and high school students. More content forthcoming, as soon as the minutes are available.

This post is to discuss how to allocate wildcards in the North America super-region, including such methods as regular or random distribution among regionals, or a super-regional. More content forthcoming, as soon as the minutes are available.

This post is to discuss additional tiers in our contests, particularly getting credit for local contests that schools are already running. This is about tiers below regionals. Tiers above regionals (i.e. a “super-regional”) will be covered in the Wildcards post. More content forthcoming, as soon as the minutes are available.

This post is to discuss additional awards that might be given at regional contests to encourage participation. More content forthcoming, as soon as the minutes are available.

This post is to discuss additional activities at regional contests. More content forthcoming, as soon as the minutes are available.

Here it is – the 2010 problem set. You can download the text from here.

The Southeast USA Regional Programming Contest will be held on Saturday 6 November this year, and I will once again be Chief Judge.

As usual, the Problem Selection Committee will be responsible for putting the problem set together. The PSC will also be responsible for judging, so problem providers won’t have to judge. Because of this, you can provide a problem, and also coach your team, and attend the contest with them at your chosen site. Anyone can submit a problem for consideration – however, although a problem submitter can also act as a coach, they cannot be a contestant, whether or not their problem is chosen for the set. In other words, if a student submits a problem, they are ineligible to compete.

Candidate problems should be e-mailed to me (at vanb@vanb.org). A statement of the problem is all that’s necessary, either in text or in MS Word format (right in the e-mail is fine). If you wish to include a solving program and/or test data, that’s very, very helpful, but not necessary. If you have a rough idea and want to talk about it, feel free to e-mail it to me, and I’ll be happy to work with you.

Problems should be sent by 13 September to be eligible for consideration. I’ll remind you again, but I’m sending out the call for problems early, to get you thinking!

Below you will find an excerpt from the Call for Problems issued from World Finals this year. It’s a good set of guidelines for candidate problems. If you are thinking of submitting a candidate problem for Southeast Regionals, you should read through it. I will add a couple of constraints of my own:

1. The problem should be original. It should not be a restatement of a problem that has been used previously in the Southeast USA, or any other ICPC regional, World Finals, or other contest environment such as TopCoder or Google CodeJam. It also should not come from a book, such as “Programming Challenges.” If it has its own Wikipedia page, then it’s too well-known.
2. The output for any given input should be unique. Try to add constraints to your problem so that there is exactly one answer for each input case.

Based on suggestions from last year’s regional contest, I have started a blog to talk about judging at our contest. It’s at:

http://serjudging.vanb.org

Feel free to drop by and give suggestions – however, do NOT post candidate problems on this site. It is open to everyone, including students. Any problem posted on the site cannot be used in the contest.

————- Some excerpts from the World Finals call for problems: ————-

Problem Statements

1. Each problem must be unambiguously described in English.
2. All problems must require input.
3. Unless the core of the problem is input/output related, the formats chosen for input data and the displayed results should be relatively simple. Still, the format of the input data and the appearance of the expected displayed results must be described in suitable detail.
4. Multiple data sets testing different cases are appropriate; make the problem statement include iterative data sets as input to avoid using separate input files.
5. Anticipate questions about special cases. Where appropriate, explicitly state that certain special cases will not appear in the input data. It is not necessary to specifically identify the special cases that will appear.
6. Indicate the precision that is required for real results.
7. Contestants must write solutions for problems in a short time. While very simple problems are not appropriate, neither are problems that require a great deal of code; a few hundred lines of Java or C should be an upper
   limit on what can be expected in a solution.
8. The program and chosen test data should not require excessive execution time. Contestants’ solutions may be less efficient than yours and so a generous margin is allowed for execution. If your test data requires the program to execute for a long time, then incorrect student solutions (e.g., those with infinite loops) will take an excessively long time to judge. We would like to avoid those situations.
9. The problem description (excluding sample input/output) should generally require at most one page.

Submission of Problems, Solutions, and Test Data

1. Use electronic mail and send all files as either MS Word documents, or flat ASCII.
2. Do not put your name in documents, or the body of e-mails, containing the problem statement, solution, or test data. This will simplify the transformation from your form to the one used for ranking.
3. Be discreet about problem statements and solutions. It is not appropriate to discuss problems with people not involved with the contest.

We considered this problem an E/F, World-Finals level of difficulty. There were 3 correct solutions – on only 7 submissions, and the first came only 65 minutes into the contest. It had the highest solution percentage of any problem outside of the two A/Bs (Knitting and Minesweeper). That means that few teams knew how to solve it, and few tried, but those who knew it, knew it well, and got it quickly and accurately.

Take a look at the Judge Input, the Judge Output, the main Solving Program, and another java solution.

A solution is in the spoiler.

[spoiler]
The key to understanding this solution is to see a column of the mosaic as a bitmap – with the bit set (=1) if there’s a tile there, and unset (=0) if not. Since there are at most 10 rows, that gives us 1024 possible bitmaps, which is manageable.

Try to build a Mosaic, column by column. Since the pieces are 2×2, you can’t fill a column without leaving some residue in the next column. So, you need to figure out, for any bitmap j representing a residue from the last column, how many ways can we fill this column and leave a residue of bitmap k in the next column? The following picture illustrates one way of filling 1001101001 (617) and ending up with 1111011110 (990).

Here’s an interesting thing – that depends only on the number of rows. So, you can compute all of that a priori, before you start reading the data, rather than doing it over and over for each data set. A recursive algorithm will do the trick.

Once you’ve got that computed, then for each input, you need to fill the columns so that you start with a bitmap of 0 (on the edge, no residue), go through m columns, and end up with a bitmap of 0 (no residue – nothing hanging off the edge of the mosaic)

     
// Assume n rows and m columns.
// Let p be the number of bitmaps if there are n rows.
// So, p = 2^n, or 1<<n
int p = 1<<n;
       
// Let next[k] be the number of ways of achieving bitmap k
// on the next column
int next[] = new int[p];

// We'll start at the very beginning (a very good place to start)
// with one bitmap of 0, and no others.
next[0] = 1;

// Go through all of the columns
for( int i=0; i<m; i++ )
{
    // Swap current and next - last iterations' next[]
    // is this iteration's current[]
    int temp[] = current;
    current = next;
    next = temp;
            	
    // Start afresh
    Arrays.fill( next, 0 );
            	
    // Go through all possible bitmaps.
    for( int j=0; j<p; j++ ) if( current[j]>0 ) for( int k=0; k<p; k++  )
    {
        // Assume that ways[n][j][k] is the number of ways of getting from 
        // bitmap j to bitmap k if there are n rows. (In the actual code, a linked list 
        // is used for efficiency, since this matrix will be sparse.)
        //
        // If there are current[j] ways of getting to bitmap j on the current column,
        // and ways[n][j][k] ways of getting from there to bitmap k, then we've
        // just found current[j]*ways[n][j][k] more ways of getting to bitmap k
        // on the next column. So, add them in.
        next[k] += current[j] * ways[n][j][k];

        // Mod to keep the numbers manageable.
        next[k] %= 1000000;
    }
}

// We're done! How many ways were there of achieving bitmap 0
// on the last iteration - that is, we nicely filled in the mosaic with
// nothing hanging over?
System.out.println( next[0] );

[/spoiler]