17
\$\begingroup\$

This answer just prompted a question, which I've wondered about a few times when answering challenges in esoteric languages:

For some esoteric languages, the only means of input/output is reading and writing individual bytes from STDIN to STDOUT, and interesting golfing of numeric challenges is near impossible with decimal input, since 80% of your code will be implementing atoi() and itoa().

If a challenge specifies that a program should take a number as input, can that number be taken as the value of a byte read from STDIN? The same question applies to output (although answers may of course address these two parts individually and with differing opinions).

For the purpose of this question, please assume that the limitations on the range of inputs/outputs is not an issue for the challenge in question.

\$\endgroup\$
5
  • \$\begingroup\$ This is a standard procedure in brainfuck. Let me look up an off-site precedent. \$\endgroup\$
    – John Dvorak
    Jan 26, 2015 at 13:08
  • \$\begingroup\$ It's not entirely clear what character codes have to do with this question. Is this an accurate restatement of the question? If so, I think clarification as to the scope of the question would be useful for two reasons: firstly, many non-esoteric languages seem to fall into the same category (e.g. Java); secondly, the linked answer also seems to output raw bytes rather than implement itoa. \$\endgroup\$
    – Peter Taylor
    Jan 26, 2015 at 14:20
  • \$\begingroup\$ @PeterTaylor Thanks, that is much clearer. \$\endgroup\$
    – Martin Ender
    Jan 26, 2015 at 14:26
  • \$\begingroup\$ It would save me 139 characters :P \$\endgroup\$
    – undergroundmonorail
    Jan 26, 2015 at 16:57
  • 2
    \$\begingroup\$ This also affects Java - compare System.in.read() to new java.util.Scanner(System.in).nextInt() \$\endgroup\$
    – Ypnypn
    Jan 29, 2015 at 16:55

2 Answers 2

Reset to default
25
\$\begingroup\$

Yes, numerical input and output may be given as a character code

As long as this doesn't give an unfair advantage (e.g. for a challenge that is "given a character code, output the character"), I don't see any problem with this. It's similar to allowing each language to use its native string representation of arrays when talking about list-based questions.

The languages in question are probably not going to win normally anyway, and I don't like to discourage answers in interesting esoteric languages, just because the author couldn't be bothered to include the atoi implementation.

PS: Also, technically, taking numbers as just the value of a byte or byte stream is in some ways more natural than reading its decimal representation encoded in ASCII characters. ;)

\$\endgroup\$
1
  • \$\begingroup\$ Is this also allowed for argv? Is the C-Code int=*(int*)argv[1] legal? The problem is that argv[n] is a string, and a string ends with '\0'. So to input 0 you have to end the string. But you can work around that (on some machines at lest, but it uses UB), by using more than a single string. i.e. ./myprogram '1' ' ' '' '' may result in the value 0x00200031 (end of string, space, end of string, '1'). Or ./myprogram '' '' '' '' to input 0. \$\endgroup\$
    – 12431234123412341234123
    Jul 19 at 11:33
-2
\$\begingroup\$

No, numerical input and output as a character code should not be valid by default

(I say "by default" because, like any good rule, it can be broken. If the question asker specifies then it should override whatever this thread decides.)

Part of the challenge of using languages like brainfuck is that even incredibly simple things become massive undertakings. What would be "read an int" becomes "read all characters of input, subtract 48 from each cell, multiply the leftmost cell by 10 and move it on top of the cell to the right until there's only one character remaining". That's what brainfuck is all about.

But more importantly than my ideology about bf, I don't like the idea of giving some languages an advantage because they're hard. Sure, this isn't technically giving an explicit advantage for any one language since anyone could choose to do i/o this way, but it's even mentioned in the question that this would be helpful for certain esoteric languages. There are no other languages (that I'm aware of, at least) where the community has decided "this feature is hard to use so let's change the way questions work to make it easier". The difficult feature is a part of the language.

We don't give Java a bonus because there's a lot of boilerplate, we don't give golfscript a penalty because it's short (though, people have proposed these, and I wasn't a fan then either). I don't feel we should make a rule change like this for the purpose of throwing a specific set of languages a bone.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I don't think "If the question asker specifies then it should override whatever this thread decides." is relevant here. I don't see anyone thinking of and explicitly overruling this default, as it's quite an edge case. Regardless, I see where your coming from, but I think penalties or bonuses for language terseness is quite a different issue. The question is about input encoding, and in that I think it's not much different from allowing CJam to expect arrays like [1 3] and Python like [1,3]. If anything reading a byte is more natural than an ASCII-encoded decimal number. \$\endgroup\$
    – Martin Ender
    Jan 26, 2015 at 17:59

You must log in to answer this question.

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