One of the biggest problems with ACM contest-type sites like the UVa Judge is that it’s hard for a newbie to determine the difficulty of any given question. That’s where Felix Halim’s uHunt has, for me, proven invaluable. It starts you out with the most trivial problems (seriously trivial – I’m talking fifteen minutes coding effort for some of these), and then works up through the more difficult. The big trick with this kind of programming, as with any skill, is consistency. Tackle 2-3 problems per week if you want to see results.
That said, here are some details about the site:
- My current rank is 23,904. 16 AC, 80 submissions, for a submission/acceptance ratio of 5 to 1. There’s room for improvement here.
- My rank when I started recording it was an even worse 33,450. 9 AC. 63 submissions. My ratio was a lot worse, averaging 7 submissions per AC.
- Solving each problem, at least at the lower rungs, boosts your rank by about 1,000.
- Number of current “authors”: 140,116 (The worst of these had 27 submissions with 0 AC. So fear not. There’s room at the bottom.)
- Your rank, should you happen to get 100 problems correct: 5,649.
- Your rank, should you happen to get 500 problems correct: 575.
- There’s one guy with 18 problems solved, but 440 total submissions. You just know he’s hating his life.
- The top guy on the site has 3930 problems solved, 3970 problems tried, and 13,981 submissions. That makes his ratio between 1 in 4 and 1 in 3 (actually, slightly more than 28 percent). One in three is good, but not nearly as good as some of his competition. On this site, solutions beat submissions any day.
- SPOJ has a better ranking algorithm, where you are judged based on problem difficulty. They’re also more flexible about what language you use. I’ve had a lot of fun with Haskell problems on their site.
- Java is less-used than C++, but so what? Any interview I’m in will probably favor Java. Once you get a solution in Java, porting it to C++ will be trivial. (Assuming you know C++, which I do.)
On the last point, I have noticed some problems that are a lot more suited to C++ than to Java. For instance, Problem 458 “The Decoder”. The problem is a simple substitution cypher, and can be solved by an absolutely trivial operation on each character. But here’s one place where Java’s I/O cruft causes more problems than it’s worth, because of one of the problem’s caveats:
Your program should accept all sets of characters that use the same encoding scheme and should print the actual message of each set of characters.
In Java, you don’t normally have to worry about character encoding, because Java assumes the universe is in the shape of UTF-16. Which means any other kind of character encoding scheme (e.g., UTF-8 or CP-1252) is going to be transformed into UTF-16 unless you specifically compile your code to respect a different character encoding. The very act of reading your input into a string in Java can change the character encoding. This caused a lot of headaches with wrong answers that I knew should be correct.
Fortunately, I know C.
It turns out that C doesn’t care about your silly encoding strategies. In C, every character looks like every other character, because characters are essentially identical to integers. In some ways, this makes C easy to deal with. The solution in C turned out to be trivial.
char c;
while ((c = getchar()) != EOF) {
if (c == '\n') {
putchar(c);
} else {
// do the transformation, and call putchar on that
}
}
return 0;
The one thing I have to thank this problem for is how it forced me to come to grips with a bit of ignorance I wasn’t aware I had: I currently don’t know how to write character manipulation in Java that is absolutely agnostic as to its character encoding.