When to allow flexible input/output

Question

First, I hope this isn't a duplicate (I've tried my best to search through for similar questions, but I very well may have overlooked one).

In the spirit of being fair to inflexible programming languages, I added a rule in a challenge of mine allowing for flexible IO. In this rule I said,

You may take the input differently, within reason (feel free to ask me if you have a specific kind of input in mind), if it would be very hard or impossible to handle input in this format in your language.

However, I'm not looking for golfing to be done in the input format. e.g. if you're in Python and want to save calling str.split('\n') on the input, you may not ask for the input as a list of strings to save you those bytes.

I realized once an answer asked for a different input that I had no way of qualifying what constitutes the "very hard" case.

This answer would benefit from a 20-30 byte reduction if the input were changed, which I initially wanted to allow for it. But I have no real way to justify that this is allowable over the hypothetical Python answer which would also benefit from a different input format.

So, to my question,

Is there a general way to rule on what is an acceptable input modification?

I am not particularly looking for specific cases here, I mean to ask what criteria a programming language needs to meet to allow for it to claim a different input (if the challenge allows for that).

Answer 1

Always (if possible)

Any picky criteria we end up giving here will end up being completely arbitrary. Therefore, always strive to allow as flexible I/O as possible in a code golf challenge that isn't about processing input or producing a very specific output. In other words, unless the challenge would not be complete without the input/output requirements, allow flexibility.

For instance, why not give that Python user an opportunity to save the call to split? Is the purpose of the challenge to do a bunch of input munging, or is it to actually compute something? If it's the latter, letting that Python user save that call (and all other users save their own random string processing calls) will make the challenge more fun for everyone.

Always err on the side of keeping the actual point of the challenge front and center, and don't get bogged down in details like this. Always err on the side of what will be the most fun.

Answer 2

Always allow flexibility, within reason

You should allow flexible input/output to keep it "fair". By that I mean: No single language (or group of languages) should have an advantage / disadvantage due to the input/output format.

Normally it's sufficient to say:

The input / output formats are optional.

People will then assume all the following are allowed if the input is a list of numbers: 1 2 3, {1,2,3}, [[1],[2],[3]] and so on. Specifying all the different allowed styles is hard, and will lead to questions: "Are (1;2;3) and list(1,2,3) accepted?"

People will also assume that different types of input and escape characters are allowed in strings (if necessary): "It's OK/not OK", It''s OK'/not OK, ['It/'s OK/not OK"].

Except for the occasional new user, no one will attempt to do all the processing in the input, and let the code simply be: f(x)=eval(x).

You will get the occasional:

• Is a list of single character strings OK?
• Can I take the string as comma delimited ASCII-values?
• Can I take the list of integers as: 1+2+3?

If you get these questions, then use your best judgement.

---

Also, remember that different languages have different limitations. For instance, a matrix such as:

1 2 3
4 5

is impossible in MATLAB/Octave. The only way to get this matrix, is by creating a string where we concatenate each line with the newline character ASCII code point 10. ['1 2 3', 10, '4 5']. This is really cumbersome. By allowing optional input/output formats, you will allow:

{[1 2 3];[4 5]}

which is pretty much the same.

Answer 3

We should have guidelines for what's acceptable when the input is of a fairly common type

We have a well-regarded meta question for methods of taking input and output. Many questions have inputs and outputs which are of simple, well-known types (e.g. integers, strings, 2D arrays, and the like). We don't, however, have a single meta question listing what's acceptable for those.

Some of the existing questions on the subject (I've chosen my own titles for these links, to clarify what I think the question that the answers address is):

• Can integers be input/output in unary? (Current outcome: only when that's the most natural way to represent numbers in the language.)
• How should numbers be represented in text streams like stdin/stdout? (Current outcome: no firm consensus, and the post hasn't had much attention.)
• Can you input or output a number as the byte with that number as codepoint? (Current outcome: yes, unless the challenge is about producing or parsing characters with a given character code.)
• What data structures can be used to input and output strings? (Current outcome: the same structures you could use for a list of characters.)
• Can you output in decimal, but using the null string for 0? (Current outcome: no.)
• Can numbers be output as truth values which are treated the same way as the number by the language? (Current outcome: there are multiple upvoted posts that disagree, but probably yes?)

It took me a while of searching to find these questions, and I've likely missed many. It's also quite easy to observe contradictions here, e.g. the last two answers strike me as fairly inconsistent with each other (and outright contradict in the case of Perl, which uses the null string as the falsey output of most bultins that return Booleans).

Having an faq question whose answers list acceptable input/output formats (with the acceptability determined via voting on the answers), and closing all the existing I/O-format questions as duplicates of it, strikes me as likely being the best solution here; there'd be a lower perceived barrier of entry to proposing formats there than there would be to ask an entire meta question, and having all the information in one place would be both easier to reference, and tend to reduce the chance of contradictions. The I/O-method question works very well (and out of all the posts on PPCG and PPCG Meta, it's likely the one that I link most often). Why not do the same thing for I/O formats?

If a question wants something really weird as input (e.g. "a symbolic equation"), it would likely have to come up with its own rules, something which the other answers to this question deal with, but that's not a very common occurrence.

Answer 4

It's up to you

I see no issue what-so-ever with restricting IO formats. I agree we should enable all sorts of languages to compute (i.e. not require STDIN, allow functions rather than programs, etc.), but I don't think question askers should be expected to weaken their specifications to reduce overhead on certain classes of languages.

I disagree that there is anything 'unfair' about requiring output of two intergers, for example, to be of the format "%d: %d" if it makes sense in the context of the challenge.

For example, Calculate Exponents bit by bit. The question here specifies a perfectly logical output format, and if the question asker expects it to be followed, then it should be. I for one think that the constant requests for weakening specifications is ridiculous, and having these slowly morphing specs undermines the work of people who like the challenge of working to a spec, rather than (what I sometimes see as) trying to undermine it.

Note that I have absolutely no issue with having flexible IO (and I agree it's often for the best), but I don't like the aggressive perusal of it by answerers outside of the sandbox, and I strongly support the right of askers to ask questions which require some effort for IO: people regularly comment on just how much of their code is devoted* to parsing input or rendering output, but whenever you have more code, you have more opportunity to golf, and if one language has strong IO processing abilities, then we should jolly well let it shine now and then and not pull it down by demanding weak specifications. (*often if any of your code is 'devoted' to parsing IO, then really you are missing an opportunity to pack some logic in their as well, and input formats often guide the design of the entire program, they are not just an inconvenience that is bolted onto the start and end).

I know the general argument is that questions should deal with the task at hand, and not the IO, but a massive part of programming is processing other peoples data, and passing it. If a question wants you to produce some petty output ("given an integer, square it") then why not provide some meaningful petty output ("a*a = b"). The way I see it, there are a lot of boring questions, which could be made half interested by adding some IO restrictions, and some which devolve into who can pick the right input format for feeding to some language specific built-in.

More generally, I disagree that questions should be 'fair' in any way, and that this even applies here. Enabling (most any) language to answer is great, but trying to even the field is necessarily doomed to fail. If you restrict the format, then it's down to the language's ability to handle that format. If you open it wide, then the advantage is the language with the broadest set of 'acceptable' input formats. In other words, flexible IO gives a consistent advantage to a specific group of languages (looking at MATLAP/Mathematic). But this is fine, it's a feature of those languages that they can chew up almost anything. It's only a problem if we insist on allowing them to chew up anything whenever they want.

I can't imagine this will be a terribly popular post, and I respect the judgement of the community as a whole, but I doubt I'm the only person who feels this way and I felt it should be represented.

Answer 5

In my humble opinion, if the main point of the challenge is not about input format (e.g. "read from an xml file") then I don't see much point in specifying the format. Most good challenges are really about finding a good algorithm to solve the problem and then outputting it in the format specified. In fact, in many cases I don't even thing the output format is important. For ASCII art, yes it is important. It must look like the specified output. For a pair of results from whatever integer manipulation, does it matter if they are comma separated or output as an array or a list? I don't think so. I guess it is all up to the context of the question and therefore up to the OP to decide.