This question already has an answer here:

(Closely related in the original premise, but both the question and its answers go off in a different direction: this meta post.)

Something I've noted in many challenges which are fundamentally about storing a large amount of data in the program (e.g. most challenges with large output) is that languages which natively use 8-bit (or 16-bit, but that's much rarer) encodings have a large advantage. Unlike most challenges, where most of the challenge is in writing the code, in this sort of challenge, the program is likely mostly going to be formed by a large string literal (or the language's equivalent), and so the score obtained for a particular algorithm is going to be based primarily (not exclusively, but close to it in most cases) on how efficiently the data can be stored in that literal. If the language uses a 7-bit character set, or a UTF-8-like character set, then many codepoint sequences won't be allowed inside the literal, and thus will run the compression ratio of the program. This seems to unfairly discriminate against languages in much the same way as, say, banning flexible I/O formats does.

It's also a problem because it makes submissions hard to compare in challenges where the algorithm is more interesting than the actual implementation of it (e.g. this answer of mine is much shorter than the next-shortest answer, and most of that comes from algorithmic improvements, but I found it easiest to write it in Jelly and many people are going to end up assuming that the score is based on the language, as they're used to seeing Jelly outgolfing JavaScript and Mathematica by that sort of ratio on challenges which are more about the implementation than the algorithm).

Now, one way to solve this problem would be to ban characters with the high bit set, thus forcing all languages to use a 7-bit character set (this is different from as I don't see a reason to ban nonprintable ASCII here). This would work well for the vast majority of languages (and is something that I've seen suggested at least in the comments of some of these challenges), but rather fails on languages where many builtins contain non-ASCII characters and have no alternative encoding (as it'll make the "code" part of the program much harder to write).

An alternative is to use bonuses/penalties. In particular, I was wondering if it would in general be a good idea to offer a 12.5% bonus if none of the characters in the program have their high bits set. I'm aware of the normal arguments against bonuses/penalties, which make sense for most situations in which they're used, but this is somewhat different, as the decision is likely to be clear-cut, and yet different per language (languages which "natively" use ASCII have no reason not to go for the bonus, languages which use all 256 possible octets typically have no trouble representing them in string literals and thus wouldn't benefit from the bonus at all). The bonus size of 12.5% places the 7-bit and 8-bit (and 16-bit) encodings on an exactly level playing field, and thus will help the focus be on the algorithm, which it really should be in this sort of challenge.

So the question is: is this sort of bonus a good idea? Would it be a good idea even on other types of challenge, or just compression-related ones? Are there other ways we can help avoid unfairly discriminating against languages due to the way in which they store string literals (or the equivalent)?


marked as duplicate by Mego, mbomb007, Blue, Wheat Wizard, Pavel Jan 8 '17 at 8:03

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 3
    \$\begingroup\$ "It makes submissions hard to compare in challenges where the algorithm is more interesting than the actual implementation". I don't disagree, but surely this applies to golfing languages in general? And attempts to penalize golfing languages don't seem to go down well here. \$\endgroup\$ – James Holderness Jan 6 '17 at 4:05
  • 1
    \$\begingroup\$ @JamesHolderness: The point is that this doesn't actually penalize the golfing language, because it has just as many useful bits as the non-golfing language does. If you took the golfing language and made it into ASCII via inserting a zero bit at every eighth byte, under this method of scoring it'd have exactly the same score. The aim is to avoid penalizing the non-golfing language for not being able to store data in its string literals as efficiently. \$\endgroup\$ – user62131 Jan 6 '17 at 4:16
  • \$\begingroup\$ You could also avoid penalizing non-golfing languages by using a byte count of the Huffman encoding of their source rather than the source itself to make up for the fact that their built-in function names aren't stored as efficiently as golfing language built-ins. But however you phrase it, if you're changing the scoring system such that it benefits one language but not another, you're essentially penalizing that other language. \$\endgroup\$ – James Holderness Jan 6 '17 at 4:49
  • 1
    \$\begingroup\$ Related \$\endgroup\$ – Luis Mendo Jan 6 '17 at 13:41


The premise of this question is "Strings are less efficient in language X, so let's give them a boost".

However, if we do that, then why limit ourselves to strings? If my language only uses 3 or 4 characters (BF, whitespace), why don't we score each character as 2 bits?

Languages simply have disadvantages and advantages when it comes to golfing. Trying to place all languages on an equal playing ground doesn't work, which is why we don't compare Python and Pyth answers: it just doesn't make sense.

  • 1
    \$\begingroup\$ The difference in this sort of challenge is that the length of an answer is almost entirely determined by the strings in it, which normally differ by enough in terms of length that the rest of the answer doesn't matter. Thus, it is meaningfully possible to compare answers cross-language in this sort of challenge, not perfectly, but enough to be interesting. Doing this sort of competition as a winner-per-language doesn't work as the interest is not in golfing the language itself (and thus it would encourage stolen answers and the like). \$\endgroup\$ – user62131 Jan 6 '17 at 10:53

Explain comparisons unofficially

Compute what your score would be if the hard-coded string used a different character set, and point out how your score would then compare to one in a language that uses that character set. This isn't an "official" score, but a way to help readers compare the relative effectiveness of your compression methods.

  • 1
    \$\begingroup\$ In a similar vein, all answers could post the number of bytes minus the hard-coded string. This seems easier than figuring out how many bytes the string would be if compressed differently. \$\endgroup\$ – Riley Jan 7 '17 at 3:26