Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Meta

Comments on Default Rules: Loopholes

Parent

Default Rules: Loopholes

+9
−0

What sort of loopholes are assumed to be disallowed in any challenge on this site?

One loophole per answer, please. Vote up answers if you want them disallowed, and down otherwise.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+5
−0

Optimizing specifically for the given test cases

Applies to "code-speeding" or fastest-code where your program must run as quickly as possible, as well as compression challenges. Obviously, there is a finite amount of cases because we have to measure speed/compression somehow.

It's not in the spirit of the challenge if you optimize your program to work extremely quickly for some cases (E.g. hardcoding the test cases and mapping them to ASCII characters to compress them in one byte), but the program works much worse for other input.

As there is no way around test cases, the general conduct should be that an algorithm's performance on the test cases is representative of its performance on other cases.

Rule of thumb: if you make your algorithm do well on the majority of cases and the test cases happen to be in the majority, that's fine, but not if your algorithm does well on a minority of cases which happens to cover the test cases given.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

2 comment threads

Exceptions for certain challenge types (1 comment)
splitting data in training and test might be fun (1 comment)
Exceptions for certain challenge types
trichoplax‭ wrote about 2 years ago

Is it worth clarifying that this restriction applies to general challenges but has exceptions for specific challenge types? For example, optimising to the test cases is fine if the challenge is defined as a test-battery rather than a specification (that is, where the tests are the specification), and optimising to compress only one possible output is fine for a kolmogorov-complexity challenge.

Maybe the challenge types make this sufficiently obvious already.