34
\$\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
    Commented May 30, 2015 at 22:04
  • \$\begingroup\$ @xnor It's tagged "code-golf", but I can mention it in the question. \$\endgroup\$
    – Martin Ender Mod
    Commented May 30, 2015 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
    Commented Jun 1, 2015 at 1:42
  • 1
    \$\begingroup\$ @DLosc make an answer for it and we'll see :) \$\endgroup\$
    – Martin Ender Mod
    Commented Jun 1, 2015 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
    Commented Feb 3, 2016 at 0:40
  • 1
    \$\begingroup\$ Question about mixed bases posted here for discussion \$\endgroup\$
    – Luis Mendo
    Commented Feb 3, 2016 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\$
    – negative seven
    Commented Sep 6, 2019 at 20:24

6 Answers 6

Reset to default
38
\$\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\$
    – Martin Ender Mod
    Commented May 31, 2015 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
    Commented May 31, 2015 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\$
    – Martin Ender Mod
    Commented May 31, 2015 at 11:28
  • 16
    \$\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
    Commented Jun 1, 2015 at 1:08
32
\$\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
    Commented Jun 2, 2015 at 0:30
  • \$\begingroup\$ @xnor I'd say so. \$\endgroup\$
    – Martin Ender Mod
    Commented Jun 2, 2015 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\$
    – Nathan Merrill
    Commented Jun 2, 2015 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\$
    – Martin Ender Mod
    Commented Jun 2, 2015 at 0:36
  • \$\begingroup\$ Here is a sed testcase for this answer. \$\endgroup\$
    – Digital Trauma
    Commented Jun 10, 2015 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
    Commented Jun 12, 2015 at 15:07
  • \$\begingroup\$ @chilemagic How many bytes would it be if you converted a decimal input to unary manually? \$\endgroup\$
    – Martin Ender Mod
    Commented Jun 12, 2015 at 15:16
  • \$\begingroup\$ @MartinBüttner good question. Gotta run, but you can do stuff like this echo 3 | perl -pe'$_=1x$_'. \$\endgroup\$
    – hmatt1
    Commented Jun 12, 2015 at 15:24
21
\$\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\$
-4
\$\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
  • 5
    \$\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
    Commented Jun 1, 2015 at 16:36
  • 4
    \$\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
    Commented Jun 2, 2015 at 0:29
-7
\$\begingroup\$

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

\$\endgroup\$
1
  • \$\begingroup\$ -1 from me (can't vote) \$\endgroup\$
    – Martin Ender Mod
    Commented May 30, 2015 at 15:06
-12
\$\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 .