13
\$\begingroup\$

The blurb on the code-golf tag specifies "the fewest bytes of source code" (as it should, in my opinion).

  • If a question overrides byte-count as the criterion, using character-count instead, is it still code-golf? (Should the code-golf tag still be used?)

For a given character-count, source code using multibyte characters would seem potentially more expressive than source code confined to single-byte characters -- simply due to the enlarged symbol set available for the language definition.

  • Doesn't the use of character-count as the criterion give a distinct advantage to languages like APL, Sclipting, etc., whose source code requires multibyte characters? Wouldn't byte-count be more comparable across all languages?

Examples where this matters: APL, Sclipting

\$\endgroup\$
7
  • 4
    \$\begingroup\$ Just as a comment I believe that the characters in APL were originally coded in the same size storage as ordinary character. The size of the Unicode representation is a bit of a red herring. \$\endgroup\$
    – dmckee --- ex-moderator kitten
    Feb 2, 2014 at 16:45
  • 4
    \$\begingroup\$ @dmckee - That may well be correct re APL. I notice that the preferred font for the APL Wiki has about 695 APL characters, but presumably that's to cover all the variations that have occurred in numerous APL versions -- perhaps any one version having at most 256 characters. (The same is evidently not the case for Sclipting, however, because that page mentions around 372 different single-character instructions.) \$\endgroup\$
    – r.e.s.
    Feb 2, 2014 at 19:35
  • \$\begingroup\$ Whoever downvoted the question, please explain why asking about these issues for the sake of community discussion deserves that. \$\endgroup\$
    – r.e.s.
    Feb 7, 2014 at 12:30
  • 1
    \$\begingroup\$ I'm not the one who downvoted but just to remind you: Voting is different on meta. It just means someone disagreed, not necessarily that there is something wrong about you asking that. \$\endgroup\$
    – plannapus
    Feb 7, 2014 at 13:00
  • \$\begingroup\$ @plannapus - As I read that link, a downvote reflects "disagreement" only for posts tagged feature-request (which this one isn't) -- I'm only asking questions, seeking discussion, not proposing any changes. In this case, without an explanation for a downvote, how is one to know what it means? \$\endgroup\$
    – r.e.s.
    Feb 7, 2014 at 13:21
  • \$\begingroup\$ The link says that indeed (it's relatively new that distinction so i didn't saw it before to be honest) but as a general case a vote on meta means a disagreement since it's a place of discussion (or at least that the way that most people sees it). More importantly: why would you care? There is no scoring on meta so a downvote doesn't really affect anything else than the current discussion. \$\endgroup\$
    – plannapus
    Feb 7, 2014 at 13:25
  • \$\begingroup\$ That being said, it would have been indeed more polite to explain the downvote. \$\endgroup\$
    – plannapus
    Feb 7, 2014 at 13:27

4 Answers 4

Reset to default
16
\$\begingroup\$

If a question overrides byte-count as the criterion, using character-count instead, is it still code-golf? (Should the code-golf tag still be used?)

Without actually checking, I believe that there are quite a few legacy questions which do this. I think it's reasonable to permit it in general (although in questions it makes no sense to allow anything other than bytes).

For a given character-count, source code using multibyte characters would seem potentially more expressive than source code confined to single-byte characters -- simply due to the enlarged symbol set available for the language definition.

That's the case with e.g. Whitespace or BF vs languages with more usable characters. It has been discussed elsewhere on meta in the context of those languages. The conclusion has been that they have a disadvantage and that's just tough for them.

Proposal

The tag wiki as edited by Timwi says that a question "must include"

7. Whether the number of characters or bytes in the source count.

This is a horrible change. To bring all the legacy questions up to date with this requirement would bring chaos to the site and completely bury recent substantive changes.

I propose rolling back to revision 2 of the tag wiki and then changing it to say that

  • If the question should be scored on characters rather than bytes then it should say so
  • Otherwise, unless the question specifies a character encoding to be used for scoring, answers which use characters outside Unicode code points 0 to 255 should state the encoding used (and should include any penalty for flags / BOM required to get the interpreter/compiler to recognise that that encoding is used).

The latter point may affect APL, but shouldn't affect the many answers in various languages which use ISO-8859-1 encoding for zipped data.

Update As this was the most upvoted answer, no-one objected to the proposal, and there have been a few days of inactivity around the question, I've made the change.

\$\endgroup\$
10
  • \$\begingroup\$ That proposal sounds fine by me. \$\endgroup\$
    – Timwi
    Feb 7, 2014 at 14:31
  • 1
    \$\begingroup\$ Perhaps it's also worth to encourage question setters to specify characters instead of bytes? It seems to me it leaves more space to be creative (eg Sclipting), rather than arbitrarily compressing another language (eg chinese-golfscript). I'm actually surprised there isn't yet a variant that uses arithmetic encoding with a pre-calibrated frequency table to produce a most compact (and boring) output. \$\endgroup\$
    – RomanSt
    Feb 7, 2014 at 15:55
  • \$\begingroup\$ @romkyns, I think it's more interesting to be creative in the use of an existing language (albeit an esoteric one) than in the creation of a new one. \$\endgroup\$
    – Peter Taylor
    Feb 7, 2014 at 16:18
  • \$\begingroup\$ @PeterTaylor: Well GolfScript represents the creation of a new one. Should it be discounted? I don’t think so. But regardless of that, this discussion is not about what languages should or should not be used (or even encouraged). \$\endgroup\$
    – Timwi
    Feb 7, 2014 at 16:21
  • \$\begingroup\$ @Timwi, not as such. It was designed with golfing in mind (although not as golfed as it could have been!), but under the assumption of an 8-bit character set (and all of the built-ins use printable ASCII only). I therefore don't think it's relevant in the scope of my comment to romkyns. \$\endgroup\$
    – Peter Taylor
    Feb 7, 2014 at 16:25
  • \$\begingroup\$ @PeterTaylor: Then I’m confused, because your comment to romkyns does not say anything about ASCII at all; instead it seems to emphasise “existing language” and “creation of a new one”. \$\endgroup\$
    – Timwi
    Feb 7, 2014 at 16:31
  • \$\begingroup\$ @Timwi, romkyns' comment is quite clearly about languages which exploit multi-byte character encodings. Scope is transitive. \$\endgroup\$
    – Peter Taylor
    Feb 7, 2014 at 16:34
  • \$\begingroup\$ @PeterTaylor: No, romyns’ comment was about languages that are creative. He specifically stated that he finds Sclipting more creative than “chinese-golfscript” (by which I assume he means ChineseScript), even though both use Unicode. He also mentions arithmetic encoding, which would be boring even without using Unicode. \$\endgroup\$
    – Timwi
    Feb 7, 2014 at 16:45
  • \$\begingroup\$ @PeterTaylor - Is it possible for the general reader to view "revision 2 of the tag wiki", which you propose to modify? \$\endgroup\$
    – r.e.s.
    Feb 8, 2014 at 2:31
  • \$\begingroup\$ @r.e.s. codegolf.stackexchange.com/revisions/1339/2 \$\endgroup\$
    – plannapus
    Feb 8, 2014 at 8:53
6
\$\begingroup\$

I don’t mind whether the criterion is bytes or characters for individual challenges. I believe that the challenge author should be free to decide this. The answerer should also be free to mention both the byte or character count, and upvoters should (and are) free to upvote whatever they want.

What I would object to is if the community were to attempt to impose criteria or restrictions that make no sense. For example, the info page used to state that Unicode characters should be encoded as UTF-8. I edited this (and my edit was apparently accepted by the reviewers) because, well, why shouldn’t I be allowed to use a language that understands UTF-16, or DOS codepage 437 or any other character encoding? Why is this choice more controversial than choosing to write in GolfScript or J?

Now, personally I try not to take it all too seriously. We are here to have fun and to play games, not to fight a war of ideology. If it were vitally important that I minimize the byte count in every entry I post here, I could easily write an interpreter that understands a variety of golfy languages encoded as gzip or arithmetic encoding. That would win the challenge on pure byte count, but it would be boring and it would take away from the fun that this site represents.

I left the site in 2011 out of frustration with GolfScript and J, but I came back because I have learnt to take it less seriously. I now upvote answers in any language, including GolfScript, whether they are short or simply clever or interesting, and my hope is that some people would find it in their heart to do the same and not take Sclipting too seriously.

By the way, the objection against Sclipting is ironic because even when counting characters instead of bytes, GolfScript beats Sclipting most of the time. I don’t know if that’s because Sclipting is somehow badly designed or I’m just not clever enough to write really short programs in it, but either way, it’s not important. To me, what’s important is that we all have fun, and I’m having fun writing programs in Sclipting (or even Funciton, which is grossly unsuitable for golfing :) ).

\$\endgroup\$
16
  • 2
    \$\begingroup\$ Interesting approach: Rather than discuss these issues to get community feedback, you simply edited the code-golf info page and got it approved by whatever small number of people did the approving, then came here and posted about it, elsewhere saying that it "has been accepted by the community". \$\endgroup\$
    – r.e.s.
    Feb 7, 2014 at 12:29
  • \$\begingroup\$ @r.e.s. FYI: you can see the approvers looking into the edit page here. \$\endgroup\$
    – Howard
    Feb 7, 2014 at 12:39
  • \$\begingroup\$ @Howard - The more concerning part of the edit is the revised treatment of UTF-8/UTF-16. If I'm not mistaken, any string encoded in UTF-16 also has a unique encoding in UTF-8, so the fact that an interpreter runs a program stored using UTF-16 has nothing to do with whether the program's byte-length may be measured using UTF-8. Before the edit, UTF-8 was to be the standard -- now I guess there is no standard, and a user can pick whichever encoding gives the smallest byte-count. I don't necessarily favor one over the other-- but I would like to see the issue clarified much more than it has been. \$\endgroup\$
    – r.e.s.
    Feb 7, 2014 at 12:57
  • \$\begingroup\$ @r.e.s.: I’m not sure what exactly got you upset, but whatever it is, I apologize for it. I am here now to engage in the community discussion. I explicitly stated what the tag info page stated before my suggested edit. I’ll edit the answer to clarify that this is the case. \$\endgroup\$
    – Timwi
    Feb 7, 2014 at 14:14
  • \$\begingroup\$ Why do you think a user shouldn’t be allowed to pick whichever encoding gives the smallest code size, when the whole premise of code-golf is to minimise code size? \$\endgroup\$
    – Timwi
    Feb 7, 2014 at 14:25
  • \$\begingroup\$ @r.e.s. I think Timwi's point there is that while you can count bytes, in which case one has to specify an encoding, you could also just count the Unicode characters, saving the fairly arbitrary choice of Unicode-to-byte encoding. \$\endgroup\$
    – RomanSt
    Feb 7, 2014 at 14:46
  • \$\begingroup\$ That wasn’t my point, @romkyns, but it’s another good point nonetheless :) \$\endgroup\$
    – Timwi
    Feb 7, 2014 at 16:22
  • 1
    \$\begingroup\$ @Timwi - If a question is answered by various programs that use multibyte character encodings, and byte-count is the scoring criterion, then it would seem like apples & oranges if the byte-counts do not all refer to the same encoding. (We're talking about choosing some uniform standard strictly for the purpose of measuring byte-count -- nothing to do with which encoding an interpreter uses.) Maybe I'm being too idealistic by thinking there could be substantial agreement on such a uniform standard, but--until you edited it out--I thought there was a consensus to use UTF-8 as that standard. \$\endgroup\$
    – r.e.s.
    Feb 8, 2014 at 2:18
  • \$\begingroup\$ @r.e.s., looking at the history of the tag wiki, that consensus seems to be something inherited from StackOverflow when PCG was created. I don't think it's been discussed on Meta before this week. \$\endgroup\$
    – Peter Taylor
    Feb 8, 2014 at 9:32
  • \$\begingroup\$ @r.e.s.: As I said, I don’t understand why you think comparing a language that accepts UTF-16 with one that accepts UTF-8 is any more apples-and-oranges than comparing GolfScript with C#, or for that matter with machine code. All of these ultimately encode programs in a sequence of bytes (called a “file”). How the program is encoded is entirely up to the language; some require ASCII, some accept UTF-16, and some use bytecode instructions that don’t relate to characters at all. Why do you want to impose a character encoding standard but not a syntax standard? \$\endgroup\$
    – Timwi
    Feb 8, 2014 at 12:59
  • 1
    \$\begingroup\$ @Timwi - Unicode strings are abstractions, like integers are for most mathematicians. Integers are represented by various encodings (decimal, binary, etc.), and Unicode strings are represented by various encodings (UTF-8, UTF-16, etc.). A question like "Which has more digits, the 10th prime or the 10th Fibonacci number?" makes more sense if the same encoding (e.g. decimal) is used for each number. Similarly, "Which has more bytes, Unicode string A or Unicode string B?" makes more sense if they both use the same encoding (e.g. UTF-8). \$\endgroup\$
    – r.e.s.
    Feb 8, 2014 at 13:14
  • \$\begingroup\$ @r.e.s.: So should we also require that all integer literals must be in decimal and you can’t use hexadecimal? \$\endgroup\$
    – Timwi
    Feb 8, 2014 at 13:17
  • 1
    \$\begingroup\$ @Timwi - "So should we also require that all integer literals must be in decimal and you can’t use hexadecimal?" Where do you get such nonsense? \$\endgroup\$
    – r.e.s.
    Feb 8, 2014 at 13:19
  • \$\begingroup\$ Maybe I need to clarify this: In the analogy I gave between abstract integers and abstract Unicode strings, the phrase "makes more sense if they both use the same encoding" refers to the encoding used for byte-count comparison, and has nothing to do with whatever (possibly different) encodings might otherwise be used to specify the strings. \$\endgroup\$
    – r.e.s.
    Feb 8, 2014 at 13:46
  • 3
    \$\begingroup\$ It just seems to me by far the simplest metric to simply count the bytes in the input file that goes into the compiler/interpreter/runtime, no matter what that file contains. \$\endgroup\$
    – Timwi
    Feb 8, 2014 at 16:43
0
\$\begingroup\$

Counting score of APL code

I can read here some claims that seem wrong. Some precisions:

  • One unicode character is ONE unicode character, no matter if it is ascii or not; UTF-8 is one encoding for Unicode (not the single one). For instance, encoding a golfscript code in UTF-16 will make it have twice its UTF-8 size!
  • Counting bytes isn't really relevant as long as we are interested in coding; from the code point of view, we are speaking of a file which is written or read in textmode (either by a computer or a human), which means that unit is character. For instance, if you read one character of the file (from a program written in python, sed, awk, etc.), you will get one unicode character; you will probably not even able to read one byte with a rudimentary tool like sed or awk. You have to refer to a position in the code by counting characters in order to allow someone else to find the exact location in the file.

Since there is no objective reason of focusing on bytes, I don't even want to argue about historical encoding of APL or whatever.

\$\endgroup\$
-1
\$\begingroup\$

UTF-8 Everywhere

After reading the manifesto, I'm a fan. It's about general usage in programming, but I think it's even more true for code golf.

A standard is good, to save the need to specify the detail in every problem description (and worse - the trouble arising from forgetting to specify it).

For most programming languages, which are ASCII based, UTF-8 means byte count and character count is the same. And if your language supports Unicode, you can use it, but you get more and pay more.

I don't thin that it matters that for some languages, UTF-16 is native. The byte count is the size of the UTF-8 representation of the program text.

\$\endgroup\$

You must log in to answer this question.

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