Re: Contest Update
Andy Serpa wrote:
>
> Derek Parnell wrote:
> >
> >
> > If I may weigh in here, the EOF marker is not bad data. It is perfectly
> > allowable in text files and *any* program that reads a file as a text file
> > ought to take it into consideration, as you have said. However, who said
> > they were going to be text files?
> >
> > The confusion might come about because it was assumed that the test files
> > would be 'text' files. There is no statement in the rules that this would
> > be the case. All it says, and I quote rule 13, ...
> >
> > "The file should only contain bytes in the range #00 - #7F, and you can
> > consider those to be ASCII characters."
> >
> > A better program would most likely validate the input rather than assuming
> > it to be correct.
> >
> > I'm sorry I didn't make it too easy for people, but this specification is
> > still a whole lot better than most specifications received from a client.
> > So yes, I could have told you how to open the file, how to hash the tokens,
> > how to store the lists of tokens, how to sort or order the tokens,
> > how to ... etc... but I didn't. I wanted you to work out some of the
> > 'traps' that might be there.
> >
> > Its a game more than a contest, so one needs a bit of an interesting
> > challenge.
> >
> > If anyone wants to withdraw, just let me know.
> >
>
> I just figured you wanted this to be a programming challenge rather than a
> "rule-reading"
> challenge.
Yes I did. But I submit that 'programming' is more than 'coding'. It also
includes understanding the specs amongst other things.
> I would submit that your referring to the tokens as "characters" rather
> than "bytes" (at least in some places) would allow one to assume that the
> inputs are
> *supposed* to be text files.
Yes again. That was one of the 'traps' I included. I refer to 'token text'
and characters. The idea behind this was so that one might make the
assumption that the file itself was a true ASCII text file, rather than
a file that contained ASCII text tokens. However, it is also quite possible
that some might not make this assumption, and many people did not.
> "Characters" only exist in text, at least in a Euphoria
> context (maybe if this were C, where a character might be assumed to be any
> single
> byte).
A 'binary' can contain text though, no? Have look at your typical .EXE
file and while mostly it is not text, you can see text embedded in it.
> I also thinking making assumptions about the intentions of the creator of the
> input file (maybe the EOF is supposed to be there, and you are NOT intended to
> read
> past it) is questionable.
Yes, you are right again. So did anyone question this before the contest
started? Time was made available for clarifying the specification. This
point was not brought up, so I didn't clarify it. Didn't want to make it
a perfect spec, did I?
> If the scope of the contest is to include the possibility
> of an ambiguous program specification where the true wants of the
> (hypothetical) "client"
> are therefore unknown, then my interpretation is just as valid as yours, and
> the programmer
> should only be penalized if his program handles the same (ambiguous) situation
> inconsistenly
> with different input files.
So, you want to withdraw then? Want your money back? No problems.
Look, a number of people tripped on this one, and few even fixed it
up themselves. But as I could see that some others were having an issue
with it, I tried to help with a 'hint'. It's a game. If I was a real
client I would have mentioned this much, much earlier. That's what
prototypes are good at doing - defining the real specification.
> Or, alternatively, as I said before, if you (as the "client") remove such
> ambiguousness
> from the rules/specification.
Okay, seeing the 'trap' has been sprung, I'll clarify the rules. Happy?
--
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
