8
\$\begingroup\$

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).

\$\endgroup\$
  • 4
    \$\begingroup\$ I generally think that we should allow flexible input, but in the case of your fish challenge I understand why you want to restrict the input. One purpose of the challenge is to parse <>< code, and splitting the string is arguably a part of the parsing process, as is padding the lines with whitespace. I don't think there is any general rule that works in all cases. \$\endgroup\$ – fergusq Mar 27 '17 at 8:12
14
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ In fact, I would say, not only should we allow flexible input, we should even explicitly mention some alternate input format in the question itself. A question that asks about a 2d language perhaps should even allow a 2d character array, and that option should be mentioned withn the question body itself. \$\endgroup\$ – Rohan Jhunjhunwala Mar 26 '17 at 22:42
10
\$\begingroup\$

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.

\$\endgroup\$
6
\$\begingroup\$

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):

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 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.

\$\endgroup\$
  • \$\begingroup\$ I would support having 'defaults' for different IO formatting concerns (as per Default for Code Golf: Input/Output methods). If the default is to be flexible, then that is fine by me, but we must allow askers to side-step them if they wish. Hopefully this will automatically improve questions from new members, and keep people miserable STDIO advocates like me happy also. \$\endgroup\$ – VisualMelon Mar 28 '17 at 23:56
  • 2
    \$\begingroup\$ Amusingly, I compiled almost the exact same list of meta posts yesterday, although for a somewhat different proposal. \$\endgroup\$ – Martin Ender Mar 29 '17 at 19:40
4
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I feel like this is partially addressed by the other answers given, but not made obvious. In some challenges, part of the challenge is to parse input. In this case, making the input flexible makes part of the challenge moot. But if the focus of the challenge is not partially on parsing the input, how it's given (within reason) shouldn't matter. \$\endgroup\$ – cole Mar 27 '17 at 16:55
  • 3
    \$\begingroup\$ Indeed, I agree that the other answers do provide a balanced discussion (not so keen on the headings), but I still think that there is an unwritten rule that unless the input format is integral that it must be ditched, and I think that is wrong. If someone wants you to output csv (they don't need a reason why), then you should output csv, not ask if you can output an array. I agree that for a lot of challenges flexible IO is a good thing, but I feel that there is a lot of negativity toward arbitrary IO criteria, and I think there shouldn't be. \$\endgroup\$ – VisualMelon Mar 27 '17 at 16:59
  • 1
    \$\begingroup\$ I was on the fence before, but this is a really solid argument. +1 from me. The only time I'd really push for a "any kind of format works", is if the challenge was one of our standard (catalog) challenges that we want answers in every language. \$\endgroup\$ – Nathan Merrill Mar 27 '17 at 21:58
  • \$\begingroup\$ MATLAB can't chew up everything. For instance, it's impossible to read a string that's over multiple lines. You have to concatenate a string with the numeric value 10 to get a newline. Requiring that the program/function must handle input over several lines rules out MATLAB completely. A requirement that the input must integers in a list of lists on the format: [[1,2,3],[4,5,6]] rules out MATLAB completely. The only way this can be handled is if it's taken as a string, then using regexes to get rid of the brackets, and split the input into cells, then finally into a matrix. \$\endgroup\$ – Stewie Griffin Mar 28 '17 at 11:51
  • \$\begingroup\$ A strict format rules out a bunch of languages, or makes it incredibly cumbersome to use. If I see a challenge requiring that the only format that can be used to input matrices is [[1,2,3],[4,5,6]], or 1 2 3\n4 5 6 (where \n is substituted with a newline, then I can tell you straight away; that's a downvote from me. (Unless the input parsing is an important part of the challenge of course) \$\endgroup\$ – Stewie Griffin Mar 28 '17 at 11:54
  • \$\begingroup\$ I agree with large parts of your answer though... :) It's sometimes annoying that I have to allow formats that don't really make much sense. \$\endgroup\$ – Stewie Griffin Mar 28 '17 at 11:57
  • 1
    \$\begingroup\$ You seem to focus a lot on unfairness. I think you're missing the point why people who like to use esolangs complain about rigid input formats. Many esolangs are fun to golf, when the problem at hand can be solved in ~30-100 bytes. After that, in many of them the program just gets so complicated, that you know you're far from optimal and that the optimal program is essentially impossible to find and there's no longer a structured way to make progress. If I have to add 200 bytes of code to read and write decimal numbers, then I'll likely skip an interesting problem in an interesting language. \$\endgroup\$ – Martin Ender Mar 28 '17 at 16:02
  • 2
    \$\begingroup\$ This applies especially to simple challenges. Squaring a number can be a really interesting problem in esolangs that don't have multiplication. I'd love to solve that. But if I then also have to format the output in a specific way, that really distracts from the interesting part and I'll no longer feel like I'm able to come up with a satisfactory solution. Strict I/O formats are less of a problem for complicated tasks, because they won't be tackled in these languages anyway, and the parsing won't dominate the problem so easily. \$\endgroup\$ – Martin Ender Mar 28 '17 at 16:06
  • 4
    \$\begingroup\$ Really the only reason I think that "trivial" challenges are fun is because they're interesting in esolangs (they're often the only problems solvable and golfable in esolangs). Don't lock those languages out by making the challenge "more interesting" with a rigid I/O format. \$\endgroup\$ – Martin Ender Mar 28 '17 at 16:07
  • \$\begingroup\$ @StewieGriffin admittedly my MATLAB isn't fantastic, and I definitely didn't phrase that well: I was trying to say that MATLAB has a good many low-cost ways of representing data rather than that it is good at 'traditional' IO. That said, it's one top-level command to parse CSV and such (is that just from files?), and presumably it can take multi-line strings as input to functions? \$\endgroup\$ – VisualMelon Mar 28 '17 at 17:20
  • \$\begingroup\$ @MartinEnder that's certainly a perspective I might have missed, and I certainly don't want to clobber esolangs; I've probably not made this very clear (I do tend to rant) but I'd rather we have a mix of the flexible I/O and stricter I/O stuff. I tend to disagree with the sentiment that rigid I/O makes questions less interesting, and if there are any languages where they could make it more interesting, then it would be esolangs, because they have so much opportunity to influence the rest of the code. \$\endgroup\$ – VisualMelon Mar 28 '17 at 17:30
  • 1
    \$\begingroup\$ All that said, I do recognise that even if (for some) it might be more fun/interesting to have I/O formats in esolangs, it will certainly be a lot more work than the bland C#/Java/Python/whatever answers which will inevitably clog up the answers pages. I do think that allowing a mix is the right thing to do - people shouldn't feel pressured into removing I/O formatting (this is what I'm really complaining about) if they want it - which would hopefully will create opportunities for all languages to compete in interesting ways. \$\endgroup\$ – VisualMelon Mar 28 '17 at 17:30
2
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .