32
\$\begingroup\$

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

\$\endgroup\$
7
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – xnor
    May 30 '15 at 22:04
  • \$\begingroup\$ @xnor It's tagged "code-golf", but I can mention it in the question. \$\endgroup\$ May 30 '15 at 22:26
  • \$\begingroup\$ Does this apply similarly to other bases (binary, hex, etc.), with the same option for the question to specifically disallow them? \$\endgroup\$
    – DLosc
    Jun 1 '15 at 1:42
  • 1
    \$\begingroup\$ @DLosc make an answer for it and we'll see :) \$\endgroup\$ Jun 1 '15 at 8:34
  • \$\begingroup\$ How about mixed formats? Having an input in decimal and another in unary. Is there some agreement on that? \$\endgroup\$
    – Luis Mendo
    Feb 3 '16 at 0:40
  • 1
    \$\begingroup\$ Question about mixed bases posted here for discussion \$\endgroup\$
    – Luis Mendo
    Feb 3 '16 at 12:40
  • \$\begingroup\$ 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? \$\endgroup\$ Sep 6 '19 at 20:24
37
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ 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. \$\endgroup\$ May 31 '15 at 11:14
  • \$\begingroup\$ @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. \$\endgroup\$
    – isaacg
    May 31 '15 at 11:21
  • \$\begingroup\$ 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. \$\endgroup\$ May 31 '15 at 11:28
  • 15
    \$\begingroup\$ 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? \$\endgroup\$
    – BrainSteel
    Jun 1 '15 at 1:08
30
\$\begingroup\$

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

\$\endgroup\$
8
  • \$\begingroup\$ Would this apply to inputs that are lists of numbers? \$\endgroup\$
    – xnor
    Jun 2 '15 at 0:30
  • \$\begingroup\$ @xnor I'd say so. \$\endgroup\$ Jun 2 '15 at 0:31
  • 10
    \$\begingroup\$ I feel like Unary could easily be used as a loophole, and that loophole would not be obvious to the OP. \$\endgroup\$ Jun 2 '15 at 0:34
  • 1
    \$\begingroup\$ @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. \$\endgroup\$ Jun 2 '15 at 0:36
  • \$\begingroup\$ Here is a sed testcase for this answer. \$\endgroup\$ Jun 10 '15 at 5:16
  • \$\begingroup\$ 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 \$\endgroup\$
    – hmatt1
    Jun 12 '15 at 15:07
  • \$\begingroup\$ @chilemagic How many bytes would it be if you converted a decimal input to unary manually? \$\endgroup\$ Jun 12 '15 at 15:16
  • \$\begingroup\$ @MartinBüttner good question. Gotta run, but you can do stuff like this echo 3 | perl -pe'$_=1x$_'. \$\endgroup\$
    – hmatt1
    Jun 12 '15 at 15:24
18
\$\begingroup\$

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.

\$\endgroup\$
-2
\$\begingroup\$

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.

\$\endgroup\$
2
  • 4
    \$\begingroup\$ 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. \$\endgroup\$
    – BrainSteel
    Jun 1 '15 at 16:36
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – xnor
    Jun 2 '15 at 0:29
-5
\$\begingroup\$

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

\$\endgroup\$
1
  • \$\begingroup\$ -1 from me (can't vote) \$\endgroup\$ May 30 '15 at 15:06
-11
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

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