Can numeric input/output be in unary?

Question

Some string-based languages (including but not limited to sed, Retina, ///) can't really handle integer arithmetic in decimal (or other normal bases). Therefore, these almost always have to start by converting the input from decimal to unary, and the output back from unary to decimal, which can easily outweigh the actual solution, which is often quite elegant.

Should (by default) unary input and output be acceptable for code-golf challenges dealing with integer input/output? (This default would apply to all languages, not just the string-based ones.)

• xnor: I think it would be worth clarifying that this would not apply to fastest algorithm, since traditionally runtimes are given in terms of the input size, and this would let you artificially state lower runtimes.
• Martin Ender: @xnor It's tagged "code-golf", but I can mention it in the question.
• DLosc: Does this apply similarly to other bases (binary, hex, etc.), with the same option for the question to specifically disallow them?
• Martin Ender: @DLosc make an answer for it and we'll see :)
• Luis Mendo: How about mixed formats? Having an input in decimal and another in unary. Is there some agreement on that?
• Luis Mendo: Question about mixed bases posted here for discussion
• negative seven: What exactly counts as unary? Is the "digit" that is repeated restricted to being a certain value/character (I usually see 1 used), or does it not matter?

Answer 1

Yes, but only for languages such as sed, Retina, ///, etc.

Only where it is the language's most natural integer representation.

I'm in general a fan of taking input in the most natural format for a given language. If a language has no integer type / integer processing capabilities, then the most natural format may well be a unary string, and so in that case, and only that case, it should be allowed.

One precedent for this is Brainfuck and other similar languages which typically take numeric input as a byte of that value.

Of course, this can be overridden by the poster. If someone says "input is space separated decimal integers", then that's that.

Thanks to @randomra for some ideas.

• Martin Ender: I can sort of get behind this (although I find it a little vague), but the byte value precedent is actually an argument for allowing unary in general.
• izzyg: @MartinBüttner To quote your rationale on that question, It's similar to allowing each language to use its native string representation of arrays when talking about list-based questions. It's that argument that I'm refereing to, not the specific conclusion.
• Martin Ender: Right, but even in those cases it's not that we require each language to use its native string representation. It's just the sane thing to do in 98% of the cases.
• BrainSteel: I am generally against the idea of treating separate languages with separate rules. Truly, is there any harm in allowing Java to take numeric input as a unary string? Even in languages with nice natural integer representations, it is often inconvenient to take input as an integer. (e.g. Fission/BF/half a dozen other esoteric languages) I can't see how allowing unary does anything but encourage diversity and creativity, which is precisely what we want, right?

Answer 2

Yes, unary I/O should be acceptable by default

Challenges where unary input would defeat the purpose of the task or make it trivial (hypothetical example "Add two numbers") can always override this default by specifying something like "Given two decimal numbers..."

• xnor: Would this apply to inputs that are lists of numbers?
• Martin Ender: @xnor I'd say so.
• Nathan Merrill: I feel like Unary could easily be used as a loophole, and that loophole would not be obvious to the OP.
• Martin Ender: @NathanMerrill In most "normal" languages, converting the input to unary will take very few characters ... so if the challenge is trivial in unary but tough in decimal, this won't really make a difference. Also, experience users are still around to keep an eye out for cases where banning unary would be a good idea.
• Digital Trauma: Here is a sed testcase for this answer.
• hmatt1: I ported Digital Trauma's answer to Perl to show that it beats the existing Perl answers. That bothers me a bit. I also think its unclear for new question writers that with could be allowed as default when they are asking questions. codegolf.stackexchange.com/a/51640/29438
• Martin Ender: @chilemagic How many bytes would it be if you converted a decimal input to unary manually?
• hmatt1: @MartinBüttner good question. Gotta run, but you can do stuff like this echo 3 | perl -pe'$_=1x$_'.

Answer 3

Yes, I/O in unary, binary, octal, decimal or hexadecimal should be acceptable by default.

These conversions are generally simple, and for most languages they are trivial. For most languages and challenges, this won't make any kind of difference, but this could make a significant usability improvement for some of our most beloved esoteric languages. Challenge posters may of course ban any or all of these in cases that an unfair advantage may exist.

Answer 4

Yes, I/O in any base should be acceptable by default

Binary or hexadecimal, e.g. could be similarly useful for some languages. In the interests of consistency, they should also be allowed for input. Again, the challenge author can specifically disallow this if s/he wants.

• BrainSteel: I tentatively support this idea, but I have concerns that people will start requiring input in obscure bases, and in some challenges people may even opt to require input in non-integer bases which would very quickly turn into an unfair advantage and a standard loophole. I think this would be better with clear limits, like only allowing unary/binary/octal/decimal/hexadecimal.
• xnor: Please no. For languages without short built-ins for base conversions, this would let you avoid doing a real part of the work, which feels like cheating.

Answer 5

No, unary I/O should not be acceptable by default

• Martin Ender: -1 from me (can't vote)

Answer 6

Is this still open? I'm not sure what the rules are on meta policy polls, and I don't think anyone's suggested this alternative:

I think that unary should only be forbidden if parsing decimal numbers using built-in functions is forbidden for languages that have them. If working with decimal numbers as strings is an explicit part of the challenge, that should be, well, explicit. Questions that specify decimal input but don't forbid e.g. atoi or int.Parse should be assumed to be sloppily worded.