# Should I always give every minimum detail and specifications about a challenge or we can rely also on intuition?

Regarding my challenge: Help me I'm lost in the ocean! I went to read: What details should always be given for a code golf task? and a question raised in my mind. I hope I can ask that here in Meta, if not please let me know and I will delete my question.

My original idea was to produce a challenge that could be easily solved with a basic simple formula, but that maybe it could also seems to be complicated for someone, because I wanted to see how people would intepret it and if someone could produce creative or complex solution to a very simple problem.

To achieve that, I gave all the basic, but complete, minimum information possible that could be needed to solve the problem (which could represent a real life scenario). I didn't add a diagram on purpose, because it would be a visual spoiler of one possibile solution. I didn't say that at this scale the Earth's curve can be fairly approximated to a plane, and other things.

My question was edited and added with many details, diagram and other information that (in my opinion) was implicit in the original simple text.

I have no problem with that and I thank everyone who commented, helped, edited, etc. They did a great job and I appreciated that a lot.

I understand that many questions was asked to me in comments to clarify what I thought to be implicit (and was so) or to be understood with intuition that ultimately the simplification of the problem was to solve a right triangle.

So my question: is mandatory for all the challenges to give complete specifications of the problem, diagrams to every little detail if that means to almost give the way to solve the problem? In other words: Are possible challenges that have some kind of mistery, or implicit information, in them so that people must use intuition and discernment to get the solution in the most efficient way?

Example: I have a problem for which the solution is 2*2=4, I want to represent the problem in a way that is not so intuitive that one have to do just 2*2=4 but there could be many other more complex solutions.

(NOTE: I originally posted the question in the sandbox for more than one day and nothing was commented of what came out later when published on the main site.)

• I believe that as long as there's enough detail to write a submission that's valid beyond any shadow of a doubt, the challenge is fine. However, challenges which seem elegant but come down to implementing a simple formula may be looked down upon. See, for example, Compute the kangaroo sequence, which came down to golfing a simple formula for most languages; it's currently at +30/-6. Nov 24, 2016 at 15:37
• As you mentioned the sandbox, I'd recommend leaving drafts in there for at least a few days, as not everyone will see it every day. I also tend to ask in Code Golf Chat once a few days have past, to see if there is any last minute feedback before posting. There are usually people around who haven't yet seen it. Nov 26, 2016 at 11:05
• Thank you all for the advices and clarifications. I'll do my best to improve for the future. Nov 27, 2016 at 17:12

To achieve that, I gave all the basic, but complete, minimum information possible that could be needed to solve the problem

I disagree, but assuming for the sake of argument that it's true...

So my question: is mandatory for all the challenges to give complete specifications of the problem, diagrams to every little detail if that means to almost give the way to solve the problem?

It is mandatory to give sufficient specifications that there is no ambiguity as to whether an answer meets them or not. If that means that you have to draw diagrams and give an exact formula, do so. But even that isn't sufficient where the solution requires calculations with non-integer numbers: then you need to specify the range of possible input and the precision and accuracy required, and do some numerical analysis to prove that it's actually possible to meet the specifications.

Example: I have a problem for which the solution is 2*2=4, I want to represent the problem in a way that is not so intuitive that one have to do just 2*2=4

That's a rubbish question. Once one person figures it out, everyone else will do the same. The best that can be done is to incorporate a mechanism for hiding answers, which has been done once with a sequence question. It asked people to post md5 hashes of their answers until the deadline. The problem with questions with deadlines is that once the deadline passes they're closed to competition and become clutter.

• Would you consider this challenge underspecified? If not, how does it differ from the one you're complaining about?
– user62131
Nov 25, 2016 at 13:26
• @ais523, yes, I would. Nov 25, 2016 at 13:29
• I don't know which sequence challenge you mean, but this KotH and this puzzle used hashed submissions. Nov 25, 2016 at 14:46
• @MartinEnder, found it by using data.stackexchange.com to search comments. Nov 25, 2016 at 15:31
• Peter, would you consider the challenge @ais523 mentioned underspecified because it doesn't specify the required accuracy, but consider it otherwise unambiguous? Nov 26, 2016 at 11:02
• @trichoplax, just the accuracy. Nov 26, 2016 at 11:08
• Thank you for your advices. I'll do my best to improve for the future, even though I did this type of concise challenge on purpose, remembering when in university sometimes we was given math and geometry problems based on textual descriptions, and we had to deduce the best possible answers related to the main practical problem :) I understand that this site is not the place for this type of challenges. Nov 27, 2016 at 17:10

I don't think it's necessarily mandatory for every submission to treat the problem in the exact same way, especially given an approximate problem like this that will have an approximate solution. Would it be fair to disqualify programming languages based on the details of the way they did floating-point rounding?

I consider the problem that inspired the question to be clearly stated in this case; it doesn't explicitly state the accuracy required in the input, but it does imply it in the test cases given (it's pretty clear that a sufficient accuracy is either 1 centimetre or half a centimetre at a range of approximately 100 metres, presumably 1 centimetre on the basis that that's the approximate accuracy of the obvious formula that most users have used); I think that even less accurate answers could potentially be allowed if they had a proof explaining why the accuracy would be acceptable in the situation. If you were trying to solve this as a practical problem (which is how it's framed), that sort of accuracy would be easily enough, and working out that it's enough is part of the problem! And as such, specifying why your answer is accurate enough would be part of the solution.

Or to put it a different way, I don't think we should automatically close problems just because they require knowledge of the real world and a little common sense. If the question specifies enough information to deduce what sort of answers are acceptable, then people will give those sorts of answers (and that's what happened in the puzzle in question; people widely used the same answers, especially as there were comments stating that that sort of formula was acceptable). When you encounter a practical problem in real life, you don't have a magic puzzle fairy letting you know how accurate you need to be with your answer; if you require that information, you need to figure it out for yourself.

• If this were a site for solving practical problems then this would be a reasonable argument, but it's a site for competing in programming challenges. If some people read the spec as requiring them to run a 200m race and others as requiring them to run a 100m race, it isn't a fair competition. Even Usain Bolt can't run 200m in the time I take to run 100m. If small angle approximations are valid then it's not necessary for the problem statement to say that explicitly, but it should be possible to deduce it from explicit statements of input bounds and required accuracy. Nov 25, 2016 at 12:30
• And it should never be necessary to read the comments of a question to get the full spec. Nov 25, 2016 at 12:30
• We already have strong consensus that challenge writers should avoid having rules inferred from test cases. The specification should stand alone. Nov 26, 2016 at 11:08