Programming Contest for Newbies 2005

[shahriar_manzoor]

C'mon Wai, who's old

A good problemset, but hardly qualifying as 'newbie'. Wonder what an 'elite' contest would look like...

Did anyone solve A without a prefab bigint class?

The champion did not have much trouble solving all the problems quickly. I am always woried about it that a team will solve all the problems in quick time (during EPP contest ofcourse). I think if we the administrators did not make mistake and if the small mistakes in the problems were not there then it would have been a bit easier contest. Also it is always safe to call a contest easy. In the regional warmup we called a contest question difficult and a team solved all the problems in 3.5 hours (blush)

But I think the champion (the name matches) is a member of last year's IPSC winner (junior group) school team (I dare say A newbie ). And some other top teams are red coders (topcoder) as well. So it was a good contest as many good teams did reasonably well.

[Raymond Chun]

Hello! I was another guy who had prepared for the contest. (Probably you will know if you have noticed that little name at the bottom of task C ) I feel sorry that we (and in fact it was me) made a mistake when making the input data for task C, and didn

[sohel]

I think the problemset was a perfect one and infact one of the very best that I have ever encountered..
.. and I also think the name of the contest was a deceiver as many failed to solve more than one problem.

I advised some of my junior friends to attend the contest as I thought it was going to be an easy one, but they left one hour after the commencement of it.

You guys should hold contests regularly... how about once every month.

[shamim]

Overall the contest was very good, but like others I have to agree that, the term Newbie was inappropriate...

This contest did not have any geometric or mathematical problems, I think it would be a good touch if some mathematical problems were included.

[Observer]

Thanks for all your advice.

Actually we had included a math problem (Parallelepiped) in our contest, but afterwards we found that there is a task in Volume 6, which is nearly identical to ours... That's why we have the current task C - Travel in Desert, and F - Trouble of 13-Dots.

[shahriar_manzoor]

[quote="Raymond Chun"] I feel sorry that we (and in fact it was me) made a mistake when making the input data for task C, and didn

[Observer]

Well we do have alternate solutions for our harder problems (e.g. Problem E and F), yet they fail to spot the mistakes...... This definitely means that we are not experienced in setting problems.

If you enjoy this contest, we will try to hold some more in the future~ Hope you all support us~~~

[shahriar_manzoor]

I did not mean that you must have alternate solution for harder problems, but I said it becomes often difficult to get someone write solution for a very hard problem. But if you have time crisis then you must write alternate solutions for easy problems. Because when an very easy problem has mistakes it spoils the contest and when a harder problem has mistake it disturbs the contest a little. For example assume what would have happened if your easiest problem had a big mistake.

As you said that you had alternate solutions but still there was mistake. The solution to this can be not to discuss the how to solve issue with the problem setter (I am not saying that you shared) when another person writes a solution. For very hard problem this can become a problem.

Although I am giving you so many suggestions, it does not mean that our contest don't have mistakes. Still wanted to share some experiences gained so far . Also use assert() function (in case of C) to check that the input data is not invalid or write a input validator just to check that the inputs r ok, The input validator can be written by a non-problemsetter. We also cannot always follow these precautions due to lack of time.

[Observer]

Wow thanks very much for all your valuable advice!

Next time we'll be more careful...

[little joey]

If you enjoy this contest, we will try to hold some more in the future~ Hope you all support us~~~

Please do! It was a good problemset and the little things that went wrong, were all cured in time. As Shahriar said, it's next to impossible to get it all 100% right beforehand: 200 contestants always find things that you overlook, how good your team might be. You did an excellent job as 'newbie' problemsetters!

About the title: we now know what a newbie contest looks like, so there's no need to change the name in the future.

[Per]

The problemset was ok, was a pity that I only had time to participate for the first 1.5 hours, of which I spent a bit too much of my time trying to figure out which of my asserts on Problem C that went off, when I really should have spotted a very stupid algorithmic error in my solution. But at least I found an error in the input.

Regarding the title, perhaps "Elementary Programming Contest" would be more suitable.

And about things going wrong, I think the "worst" thing that happened was the problem of finding the problemset in the beginning of the contest, though I have no idea who is to blame for that (if anyone at all).

[Observer]

Thank you all~~~ Sorry again for all our mistakes......

By the way, we would like to know which problem(s) in the contest you like best, or which of them you hate the most.
Your opinion will help us when we set up new tasks in the future. Thx.

[stubbscroll]

Some opinions from someone who started competing in October 2004 (which makes me a newbie, I guess):

A: I don't like bignum very much, but some of you say it's possible to solve without. I wish I could program in Java
B: I liked it, it's nice to have one or two easy problems in a contest and it wasn't overly trivial either.
C: Nice one, I thought it was straightforward, but numerous WA proves otherwise.
D: I can't comment too much on this, as I wasn't 100% sure about what the problem was about after reading it. Maybe one more sample case could be nice. I tried to code it anyway but got only TLE.
E: Maze problems are a favourite of mine, this one is very hard and I found no good way to solve it during the contest.
F: Straightforward knapsack problem I thought, but couldn't solve it (TLE again).

I guess that makes E my favourite and A my least favourite (I'm in doubt about A since I can't see a non-bignum solution, if there is a brilliant non-bignum solution, then it is of course a good problem).

[Per]

A: I don't like bignum very much, but some of you say it's possible to solve without. I wish I could program in Java

Java wouldn't really have helped you here. Knowing Java is more of a handicap than an advantage when it comes to solving UVA problems.

I'm in doubt about A since I can't see a non-bignum solution, if there is a brilliant non-bignum solution, then it is of course a good problem

It all depends on what you consider to be a "non-bignum"-solution. Since the numbers are at most 10^30, you can represent them using two long longs, and implement a simple division/remainder for this special case, which is fairly easy (at least compared to the general case).


I think I liked problem C the best, because it taught me a well-needed lesson in humility.

[stubbscroll]

A: I don't like bignum very much, but some of you say it's possible to solve without. I wish I could program in Java

Java wouldn't really have helped you here. Knowing Java is more of a handicap than an advantage when it comes to solving UVA problems.

Doesn't Java come with a built-in bignum library?