In article <[EMAIL PROTECTED]>,
Amir Karger <[EMAIL PROTECTED]> writes:
> Before I'll say anything, let me mention that I'm glad there's no
> flaming at all going on about this and people basically just want to
> find a fair solution. That said....
>
> First of all, someone needs to make a decision about which solutions
> will be valid for Autoedit. I still don't know which solution to
> upload.
I suppose it's up to mtve to decide here. I know from private conversation
he will probably allow the big memory solutions, but I think he should
announce it here to make it "official".
>
> Second: is it illegal to test eof in Autoedit? The generic rules say
> input could be STDIN rather than a file. So while my 51 solution worked
> with testsuite 8, it would not work from STDIN. If it's *not* legal,
> then I think the rule in the generic rules should explicitly mention
> eof(STDIN) not working, because I'm not sure it's clear right now.
One of the rules says that you may assume that once you get EOF on a handle,
later reads will also get EOF. So if you test with STDIN on a terminal, it's
ok to press ^D (or whatever causes EOF on your system) as many times as
needed to stop the program.
I think with that rule your STDIN eof() test should also work. If not,
please give a counterexample. I was actually surprised there were no
eof() based solutions, since you can indeed use that to predict you
are on the last line.
The "can be a file or something else" rule is mainly to disallow fileposition
operators like "tell" and indeed to make tests on a tty valid. It also makes
sure that a testsuite is allowed to use pipes to communicate with the
testprogram (e.g. if we ever have a program that must play a game against
the testsuite).
>
> Third and most importantly, I think we need a new rule for Perl
> Golfing. I propose that if a solution passes the testsuite two days (48
> hours) or less before the end of the contest, then that solution is
> valid, even if someone finds edge cases afterwards. Why? Because (1) we
> have a globally distributed group of players, and if the test suite is
> changed 12 hours before the end of the contest, the Australians might
> sleep through it all, (2) A lot of people can't work all day every day
> so they'll maybe pick one day earlier in the week when they have lots
> of time to work on the contest, and then not check in until near the
> end, and (3) If the test suite is changed too near the end, you might
> not have time to fix it. (In this case, the fix was trivial (255->3e4
> or whatever, but then Ton pointed out that the fix might be illegal.)
> and in other cases it might be the whole basis of your algorithm that
> needs to change.)
>
> I know this isn't completely "fair". Some people might be smart enough
> not to use solutions that don't allow edge cases, and then they are
> unfairly penalized for being careful. Still, if the vast majority of
> people don't see the problem, I think it's still right to use the test
> suite as the solution. That said, people should definitely try in the
> first few days of the contest to send in any edge cases that they find,
> and contest organizers should be careful to think of as many test cases
> as possible.
>
I don't completely agree. Passing the testsuite has never been the final
arbiter of validity of a solution (except in the cases where you can
enumerate all possible valid inputs).
I think people should actually have realized that 256 substitutions is not
enough, and if they did, they should have worked out the proper maximum for
themselves. Properly understanding the complete problem is part of golfing.
This is unfortunately one of the places where not having a runtime judge,
bites, because now you only get feedback after the contest.
Having said that, if an important new edge case is discovered close to
the end, I'd rather extend the deadline. We could make this a formal rule:
A contest end may never be before latest testsuite+48 hours.
> Memory issues are probably tougher to deal with and will have to be
> decided on a case by case basis. My opinion on this particular contest
> is still that if the vast majority of people didn't realize the memory
> problem, then the contest shouldn't be judged that way. Even though
> careful Ton gets penalized, I don't know if it's fair to penalize every
> other player instead.
>
Well, I wasn't really playing, I only arrived back home from a vacation in
the last 20 hours of the contest (and almost at once realized the memory
problem when I started trying the golf a bit). So for me all this is
purely theoretical. If I were the judge on this golf though....
For the record, tybalt89 retracted his 47 and submitted a 49 instead when
this issue was discovered. The last day he most likely didn't try for
multiplier based solutions anymore. So this cost him at least 2 strokes.
Even if we retroactively accept his 47, he lost almost a day.
Someone with only little memory on his computer could get crashing or
extremely slow programs if he tried the multiplier method, and would be
forced to try other methods.
These people would be unfairly punished if these solutions are allowed.
And of course the people who used it would be punished if they were not
allowed (to my mind not unfairly, but I seem to be in a minority position
there).
> Anyway, let's get over this problem and move to another contest. Um,
> after I've had time to get some sleep.
>
Fortunately for the current golf it will very likely not matter.
Also notice that I updated the two memory rules a bit, hopefully making
them clearer. I would appreciate it if people would review them.
