1
\$\begingroup\$

Byte count is the default winning criterion in code golf. Counting bytes (as opposed to characters) is reasonable, because a language that uses more characters needs more bytes to define them.

Consider the last sentence but "negating both sides": a language that uses less characters needs less bytes to define them. Assume a certain language L only uses the 95 printable ASCII characters. A program written in L consisting of 30 such characters could for example be 256-encoded into 25 bytes (ceil(30*log2(95)/log2(256))). My proposal is that as byte count we use those 25 ("equivalent bytes"), not 30 (let me call those "byte-digits").

It could be argued that the language L should just use a character encoding with 256 characters, which avoids the problem: that way the language exploits all code space provided by each byte-digit, and byte-digits correspond to equivalent bytes. However, there may be reasons in favour of using only the 95 ASCII printable characters. Or it may be the case that the language has already been designed that way.

Consider that someone designs a new language M which simply takes a program in language L and 256-encodes it (with some correspondence between the obtained bytes and a set of 256 characters). So the program with 30 byte-digits in L becomes a program with 25 byte-digits in M. A compiler for M would be very simple: base-256 decode and call language L's compiler. Let's avoid that unnecessary and ugly step.

Of course, the winning criterion can always be defined in the challenge. So instead of "the code with fewest bytes wins" it could say "...multiply your byte count by log2(B)/log2(256) and round up, where B is the number of characters your language uses". I propose to make that the default criterion.

\$\endgroup\$
13
  • \$\begingroup\$ Related and related (but different) \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 1:13
  • \$\begingroup\$ Also related. \$\endgroup\$
    – Addison Crump
    Jan 23, 2016 at 1:16
  • \$\begingroup\$ @FlagAsSpam But the "handicap" I'm proposing is objective, easy to define and to apply \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 1:17
  • \$\begingroup\$ Yes, but it is nonetheless a handicap. :P \$\endgroup\$
    – Addison Crump
    Jan 23, 2016 at 1:18
  • 1
    \$\begingroup\$ What defines using a character? Most languages' built-ins have only printable ASCII characters in their names, but they can use arbitrary Unicode characters inside strings. \$\endgroup\$
    – Dennis
    Jan 23, 2016 at 1:58
  • \$\begingroup\$ @Dennis That's a good point. What's the Jelly approach to that BTW? Can it use Unicode in strings? How does that fit with its special character encoding? \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 2:02
  • \$\begingroup\$ Jelly can use exactly 256 different characters in its source code; all others are either aliases or simply ignored. Being able to encode arbitrary Unicode characters in string literals is a planned feature, which will use a custom encoding consisting of those 256 characters. \$\endgroup\$
    – Dennis
    Jan 23, 2016 at 2:05
  • \$\begingroup\$ @Dennis I see. Thanks for the explanation! \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 2:13
  • \$\begingroup\$ It's trivial for someone to write a transpiler and name the compressed languages. When someone actually does, they'll be valid; however no one seems to want to. \$\endgroup\$
    – lirtosiast
    Jan 23, 2016 at 3:22
  • \$\begingroup\$ This seems to be aimed at ๐”ผ๐•Š๐•„๐•š๐•Ÿ :) \$\endgroup\$
    – Mama Fun Roll
    Jan 23, 2016 at 4:17
  • 3
    \$\begingroup\$ So how do you propose to address the issue that most sane languages can use arbitrary Unicode in strings and some even in variable names? \$\endgroup\$
    – Martin Ender
    Jan 23, 2016 at 8:59
  • \$\begingroup\$ @MartinBüttner That's a problem I hadn't thought of \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 11:05
  • 3
    \$\begingroup\$ Also related (would be a dupe except that the previous one didn't explicitly propose a policy). And this. The topic in general has been discussed many times, and if it were a panacea it would already have been adopted. \$\endgroup\$
    – Peter Taylor
    Jan 23, 2016 at 13:16

5 Answers 5

Reset to default
21
\$\begingroup\$

Do not make it a default

That introduces another barrier to entry for code golf: a scoring method that makes no sense without explanation. Surely not every new user reads meta, so we'd have to explain to each new user who posts a code golf challenge why people's scores don't match up with the number of characters in their source code. (Ignoring for the moment some of the more atypical encodings.)

If you want to post a challenge that uses this as a scoring criterion, go right ahead! But this definitely shouldn't be the default for code golf.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ That's a good point indeed \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 1:26
  • \$\begingroup\$ ...except that scores don't match the number of characters anyway \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 1:28
  • 1
    \$\begingroup\$ @LuisMendo Sure, but submissions in languages which use atypical encodings such as Jelly and Seriously typically link to the definition of a byte for that language anyway. For the majority of languages, barring any insane source compression, the character and byte counts are the same. \$\endgroup\$
    – Alex A.
    Jan 23, 2016 at 1:33
8
\$\begingroup\$

Encourage anyone who make new golfing languages also make codepages

This kind of rule changes doesn't really help much for most non-golfing languages. But I can see that the current scoring rule is making new golfing languages less understandable. The problem is, we only need to make use of the 256 codepoints to make programs in a new language shorter, not the CP437 or ISO8859-1 symbols. It's better to also invent a new code page, and attach a program to convert between it and other code pages such as UTF-8. If we can know your answer can be made into those number of bytes in other ways, you don't have to use CP437 or ISO8859-1 just to prove that.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Oh, yes, we will need one BILLION esolangs! twiddles pinky \$\endgroup\$
    – Addison Crump
    Jan 23, 2016 at 21:44
  • \$\begingroup\$ so how to make the codepages? my research tells me it is very hard/ impossible \$\endgroup\$
    – Bald Bantha
    May 18, 2016 at 21:14
  • 2
    \$\begingroup\$ @BaldBantha Just invent it. You don't need to have it get supported in specific systems... \$\endgroup\$
    – jimmy23013
    May 19, 2016 at 4:23
2
\$\begingroup\$

I think against:

And here's why.

In choosing a programming language in non-CG, you essentially contract yourself to being tied to its advantages and disadvantages. While normally this has to do with efficiency, ease-of-access, and other reasons, here, it means signing yourself to the verbosity of the language.

So no.

Because it is your choice to use a language and it is your loss if your language is more verbose. If you wish to use a less verbose language, then it is up to you to learn it and use it (or make it), not for a handicap to be put into place to allow for better scores in more verbose languages that you yourself chose.

\$\endgroup\$
7
  • 4
    \$\begingroup\$ I would upvote this, but it implies that challenges are more of competitions between languages, when we have been putting forth a lot of effort to emphasize that they are competitions within languages primarily. \$\endgroup\$
    – user45941
    Jan 23, 2016 at 1:40
  • 1
    \$\begingroup\$ @Mego While that is true, there are inherent disadvantages in code size to using one language over another (i.e. bf vs. Pyth). \$\endgroup\$
    – Addison Crump
    Jan 23, 2016 at 1:42
  • 1
    \$\begingroup\$ @FlagAsSpam That's the point of within-language competition; in nearly all cases Brainfuck won't be competitive against Pyth. \$\endgroup\$
    – Alex A.
    Jan 23, 2016 at 1:46
  • \$\begingroup\$ @AlexA. I think this question relates to the "winners" of a competition by those who won overall, though. Within-language doesn't really have to do anything with this question, because the same language will have the same amount of reduction. \$\endgroup\$
    – Addison Crump
    Jan 23, 2016 at 1:51
  • \$\begingroup\$ Yes, I was thinking of absolute winners. @Mego: I like this idea of within-language competition. What's this effort you speak about? Can you give me some link? And how is that compatible with the "shortest code" winning criterion? \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 1:54
  • \$\begingroup\$ @LuisMendo It is general practice to compete with the language you choose, and winners therein are decided, but not awarded, as victors for their language. They only get the "accepted answer" through the shortest code overall (that's why Pyth/CJam/Retina always "wins"). There's still a competition, though. \$\endgroup\$
    – Addison Crump
    Jan 23, 2016 at 1:56
  • 1
    \$\begingroup\$ Both competitions are going on in parallel: Some people pick a language and compete against other solutions in the same language. Other people try to find the language that will allow the shortest code for the given challenge. Neither competition excludes the other. \$\endgroup\$
    – trichoplax is on Codidact now
    Jan 23, 2016 at 20:58
1
\$\begingroup\$

Nah, that's too complicated, and doesn't change much

In particular, what does it accomplish besides making Pyth answers even golfier? Python, for instance, can use all the printable characters, but it will still be verbose even if you make this change.

In practice, pretty much no one is doing the re-encoding that you describe in their answers, so it seems like the specific problem you are addressing is not actually a problem in practice. (I'm not sure I would consider it a problem even if they were.)

\$\endgroup\$
8
  • 2
    \$\begingroup\$ No one is doing the re-encoding that you describe in their answers But that's my point! Let's not require anyone to actually do it, when we just know what the result be. Let's use that result directly. It's like in mathematical proofs: "Let x be the 1000-th prime..." you don't stop the speaker and ask "wait, which number is the 1000-th prime"? You can use that number implicitly because a) you know it exists and b) you know its properties \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 1:23
  • 1
    \$\begingroup\$ We already don't require anyone to do it...and no one does. You're trying to save people trouble that they don't currently trouble themselves with? \$\endgroup\$
    – quintopia
    Jan 23, 2016 at 1:45
  • \$\begingroup\$ My idea is rather to bring small-character-set languages an improvement that they could reclaim anyway, but explicitly achieving it is boring. Continuing with my example, you can accept that there is a 1000th prime, that it is a large number and that it is odd, without actually going through the pain of actually computing it \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 1:50
  • 2
    \$\begingroup\$ ...so this is really about giving some languages a handicap? What do you hope to accomplish by that? \$\endgroup\$
    – quintopia
    Jan 23, 2016 at 1:53
  • \$\begingroup\$ The aim of my proposal is to level languages a bit. To avoid penalizing languages just because they use a smaller character set. \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 1:56
  • \$\begingroup\$ As I said... it won't change much. I reckon the only language that could possibly be moved ahead of something like Pyth by this is Vitsy, but again, Pyth will also benefit, and it already wins many, many challenges anyway, so I can't see there being any great benefit from this particular sort of handicap. \$\endgroup\$
    – quintopia
    Jan 23, 2016 at 2:08
  • \$\begingroup\$ I see. Does Pyth only use ASCII characters? \$\endgroup\$
    – Luis Mendo
    Jan 23, 2016 at 2:14
  • 2
    \$\begingroup\$ Yes. padpadpadpad \$\endgroup\$
    – quintopia
    Jan 23, 2016 at 2:34
1
\$\begingroup\$

In most cases bytes and chars are the same. Chars were fine until golfers start packing multiple bytes inside of multibyte unicode chars. We just want to prevent this way, so are using bytes instead of chars. But we don't want to force some calculation for possible packing.

\$\endgroup\$

You must log in to answer this question.

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