The Wayback Machine - https://web.archive.org/web/20161010045027/http://meta.codegolf.stackexchange.com/questions/4708/can-numeric-input-output-be-in-the-form-of-byte-values

current community

your communities

more stack exchange communities

company blog
Stack ExchangeInboxReputation and Badges
tour help
up vote9down votefavorite

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.

share
    
This is a standard procedure in brainfuck. Let me look up an off-site precedent. – Jan DvorakJan 26 '15 at 13:08
    
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. – Peter TaylorJan 26 '15 at 14:20
    
@PeterTaylor Thanks, that is much clearer. – Martin Ender♦Jan 26 '15 at 14:26
    
It would save me 139 characters :P – undergroundmonorailJan 26 '15 at 16:57
2  
This also affects Java - compare System.in.read() to new java.util.Scanner(System.in).nextInt() – YpnypnJan 29 '15 at 16:55
up vote12down voteaccepted

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

share
up vote0down vote

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.

share
    
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. – Martin Ender♦Jan 26 '15 at 17:59

You must log in to answer this question.

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

close