On Sun, Sep 08, 2002 at 09:11:55PM +0200, Eugene van der Pijll wrote:
> I agree with you, partially. But a course can also be too hard. We have
> had courses in the past with more beginners than veterans. I'm afraid
> that the hole was too difficult for most beginners this time. Next month
> should be an easier hole, probably.
The difficulty was my main fear, but the consensus amongst the
referees seemed to be that the problem was interesting enough to
balance the difficulty. I think we also had some grade-A self-delusion
there, along the lines of "it's easy to find an algorithm for this
using Google, so lots beginners are likely to enter".
> In fact, this month's hole was so difficult that after a days work I
> still had no working solution. Unfortunately, my attempts failed at the
> longest test, and I nearly gave up on this hole.
Yeah, The maximum input size was too long. All of the same benefits
could have been gotten with (say) 1000 characters. I don't think it
cut out many strategies due to performance, but some of the regexp
trickery was apt to segfault in the longest tests [1]. Also testing
took too long.
And while we're talking of problems... Some things that future
golf referees (and players) might want to consider:
* The long autogenerated tests were a partial failure. They probably
caught most of the bugs that weren't related to the handling of
whitespace or negative numbers. However, they were too difficult
to debug. Some tests of about 100 characters should also have been
autogenerated, with all numbers being unique (for easier testing).
* The examples shouldn't have only shown a few examples of the
transformation, but also included the main features of the spec
as it had been intended. Most of the rule-related problems could
have been avoided had there been examples showing leading zeros,
and whitespace in all allowed positions.
* The "assume 2**32 bytes of memory" and "run in reasonable time on
spec machine for any input" rules probably conflicted. Luckily,
all of the programs that used unreasonable amounts of memory were
also unreasonably slow for other reasons.
* I promise that the next time I'm playing, I'll write down a
description of my algorithm in the comments of the first
submission. And possibly more details on the changes. Trying to
figure out what some of those programs were doing was painful. Of
course this isn't as bad with 50 stroke programs.
[1] The most cruel case being Greg Allen's solutions under 200. The
code worked on Activestate, but segfaulted on stock 5.6.1 on
Linux. No experimental regexp features. And it would have worked
with a maximum input size of 9980!
--
Juho Snellman
