On January 4th, 2022, it was decided we would allow scoring in fractional bytes. A decision I mostly agree with. Just to recap, the main reason this is beneficial for the site is:

  • It allows comparing answers in the same language even if they would otherwise "round up" to the same value.
  • It allows languages to compete that do not use a traditional binary storage system to compete.

This makes a lot of sense, for these languages. However, to convert to bytes, people came up with using \$\log_{256}(b)\$ to compare these to normal languages. This works great for languages like Nibbles where it comes out to a rational number, but is annoying for languages like Fig or Thonnu when it comes out be be irrational:

  • It still doesn't allow comparing languages that don't use a numerical system at all.
  • It requires complex MathJax in titles that is hard to parse, hard to write, and hard to compare when the result is a complex decimal.
  • It creates paradoxes like this where unary suddenly becomes worth 0 bytes. I'm well aware that answer wasn't actually scored according to the meta consensus and particularly the accepted answer on fractbytes mentions nothing about log byte scoring.

If our goal is to make languages easier to compare, this has failed miserably.

Potential Solution

Our goal is to compare answers in the same language as effectively as possible. Then why use bytes at all? It makes no sense to me to score a base-3 language in bytes which is a fundamentally different number system, even if you could convert them with complex logarithms.

We only compare answers in the same language anyways. If language designers want to compare languages they can compute the logarithm and compare them that way if they want to, but as I understand it they round up to the nearest byte anyways so the log bytes solution doesn't help them either.

Thus I suggest the following:

  • Answers do not need to be scored in bytes.
  • Instead, they are scored in whatever is most convenient, it be nibbles, trits, codels, etc.
  • If there is no existing unit that properly works, like a language that has 196 builtins and would like to encode them in a shorter way, you can use the word "symbol."
  • Fractional multiples of "symbol" are still ok
  • There could be a reasonalbe limit that there can be only a finite number of meaningful distinct programs for a specific number of symbols. For example, when scoring by number of logic gates there could be a infinite number of ways to place logic gates on the infinite playing field but they are not really distinct unless they connect in different ways.

This allows easy to read (and machine parse) titles, languages that don't use a numeric system at all to participate, while as far as I can tell harming nobody.

Let me know your thoughts.

  • \$\begingroup\$ Was this stimulated by my 0 byte answer to the hello world challenge? \$\endgroup\$ Commented Apr 13, 2023 at 16:22
  • 7
    \$\begingroup\$ Scoring Unary as 0 bits per character isn't a paradox, it just shows one of the many slight inaccuracies in our byte counting, that being that the length of a program also encodes some data. There's all sorts of ways this could be abused (a language that uses the base its symbols are encoded in to store extra data, or a language that assigns meanings to each bitstring rather than bytestring, etc.), but after the first time it's not interesting so it just stays as another boring loophole. \$\endgroup\$ Commented Apr 13, 2023 at 17:25
  • 3
    \$\begingroup\$ It always seemed to me that, in many cases, the "purpose" of using log-bytes in the first place was to artificially bring down the byte count of answers posted in that language. \$\endgroup\$
    – att
    Commented Apr 13, 2023 at 17:48
  • 6
    \$\begingroup\$ Yes, please! And I'd even be good with answers in weird languages scoring in commands or pixels or NAND's or bounding radius or whatever they want. I recommend though making sure that only a finite number of programs are possible for a fixed score, to avoid exploits like where Python bytes not counting whitespace lets you run any code with score <50. \$\endgroup\$
    – xnor
    Commented Apr 13, 2023 at 17:59
  • \$\begingroup\$ I don't think that our current system "creates" or even allows the zero byte answer. Nothing about the consensus says anything to that effect. @RydwolfPrograms' answer simply says that you don't need to write a virtual file system to score your answers. However it still needs to be possible to write a virtual file system. Rydwolf's answer doesn't say anything about logarithms or such, that's just a misinference of the rules based on how other languages work. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 13, 2023 at 19:00
  • \$\begingroup\$ @WheatWizard I'm not disagreeing with Rydwolf's answer. I'm all for fractbytes, just against the extreme form of logbytes \$\endgroup\$
    – mousetail
    Commented Apr 13, 2023 at 19:07
  • \$\begingroup\$ Side note: Nibbles doesn't use irrational bytes. Are you thinking of fig/thunno? \$\endgroup\$
    – emanresu A
    Commented Apr 13, 2023 at 19:16
  • 1
    \$\begingroup\$ @emanresuA nibbles is mentioned explicitly as a language where even using the log method the byte count still comes out to be a rational number \$\endgroup\$
    – mousetail
    Commented Apr 13, 2023 at 19:50
  • 5
    \$\begingroup\$ How does this all square with our consensus that we score in bytes not characters for normal text-based languages? I guess we should declare (not as a rule, but just an honour code, or heuristic for downvoting) that normal text-based languages should remain scored in bytes. \$\endgroup\$
    – pxeger
    Commented Apr 14, 2023 at 13:26
  • \$\begingroup\$ @pxeger there are already some weird cases like multiple characters counting as 1 byte in TI basic. \$\endgroup\$
    – mousetail
    Commented Apr 17, 2023 at 16:11

5 Answers 5


No change in rules is needed, simply a change in behavior

This might not be a complete answer, but I would like to provide what I think is a solution to the issues that doesn't actually require changing any rules.

First lets talk about weird and unpleasant formatting.

Rydwolf points out that there aren't currently any rules that require you to format your header in a particular way. In fact there is a consensus that there are no rules.

So currently people do have the freedom to write "8 trits", "19 Nibbles", or "2.99999999999 bytes". They just aren't. Changing the rules might encourage them to write differently. But seeing as this formatting is so widely disliked, I think making it clear that it is allowed to format in other, more pleasant ways, and giving some encouragement to do so will be enough to shift the way people format it.

Now lets talk about non-fractional byte things.

There's no rule that says you can't golf in codels either. Our rules do say that:

Answers that produce correct results, comply with the rules of the challenge, but aren't a serious contender for the winning criteria [1]

should be deleted.

However we've also been clear that:

A serious contender is a submission which makes a serious effort towards optimizing the submission's score within the chosen language(s) and other choices (such as algorithm choice or optional restrictions/bonuses taken).[2]

I think it is pretty straightforward to take away from this that yes you can golf with a different score than bytes in mind. "The program is going to optimize this metric" is a self-imposed restriction.

And as long as your scoring goal is conducive to shorter programs, and it seems all the interesting ones are, I don't see any rules actually being broken. Sure you might be able to get a shorter program by optimizing for bytes, but that would violate your restriction, so there's no requirement to do it.

Since, as previously stated, there's no requirement to put your byte count in the header you can put that score in the header. If someone asks for the byte count, I would suggest providing it to them, but that's just general courtesy.

The same applies here as the last one, just because something is allowed by the rules doesn't mean that everyone is taking advantage of it. But hopefully if we are clear that this is allowed, either through a rule change or just general communication people will change. Or maybe they won't, that's also fine, people can certainly continue to golf in bytes if that's what they prefer.

  • 4
    \$\begingroup\$ The problem is most challenges state explicitly or implicitly, that the winning answer is the shortest in bytes \$\endgroup\$
    – Seggan
    Commented Apr 13, 2023 at 19:50
  • 4
    \$\begingroup\$ For a long time, scoring Piet in codels was essentially banned, because Dennis's answer that said "Code golf contests are scored in bytes" had the highest score on the Piet-scoring meta question. The scores have since flipped, but I suspect that's due to the existence of ASCII-Piet, which translates codels into bytes. If a codel couldn't be encoded in a single byte, I think the answer would have continued to be "No, find a way to score it in bytes." (To be clear: I think Piet should be scored in codels, which is why I made ASCII-Piet.) \$\endgroup\$
    – DLosc
    Commented Apr 13, 2023 at 20:16
  • \$\begingroup\$ @Seggan I honestly don't really get what you are trying to say. What part of the answer is that responding to? \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 13, 2023 at 20:20
  • \$\begingroup\$ @WheatWizard the second \$\endgroup\$
    – Seggan
    Commented Apr 13, 2023 at 20:25
  • 5
    \$\begingroup\$ ASCII-Piet, Scratch Blocks, etc. all seem like bandaid solutions to something that shouldn't really be a problem if we scored things reasonably in the first place \$\endgroup\$
    – mousetail
    Commented Apr 13, 2023 at 20:26
  • \$\begingroup\$ @Seggan Could you be more specific? I don't see what you are trying to say. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 13, 2023 at 20:27
  • \$\begingroup\$ @mousetail I like ASCII-Piet, it find codels to be a little unintuitive, whereas ASCII-Piet is just characters. ASCII-Piet feels like "codels but better" to me. But to each their own, I don't even really like Piet much to begin with. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 13, 2023 at 20:31
  • \$\begingroup\$ @WheatWizard most challenges state: "shortest code in bytes wins," or a variation thereof. Even if they don't, bytes are implied. \$\endgroup\$
    – Seggan
    Commented Apr 14, 2023 at 1:14
  • 1
    \$\begingroup\$ @Seggan Yes, but what is that a response to? It seems like you are trying to imply something with that, since clearly I already know it's true, but I don't know what. To me that statement does not clearly relate to anything I've said. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 14, 2023 at 1:57

Score in bytes, for the sake of clarity

(I used to think differently, but I changed my mind.)

If the language is encoded in smaller units than bytes, say nibbles, those could always be converted to bytes, rounding up if necessary. In fact, that has to be done if the scource code is to be saved using a normal file system. So, why not use the size in bytes of that (hypothetical) file as the score?

Essentially, this puts the burden of converting to bytes on the language compiler/interpreter. The language can internally use smaller units, but those are then encoded into bytes, using any encoding chosen by the language designer.

Keeping bytes as the measure of code length has advantages. It is a convenient unit that everyone understands. Scoring in arbitrary units would be confusing to people who don't know that unit.

It could be argued that comparisons should only be done between answers in the same language. Strictly that's true. But one of the appeals of code golf is to be able to solve a moderately difficult task in few bytes in some obscure language. For newcomers, an answer title like (I'm making up the language names),

Soil, 8 bytes

sounds impressive (How can this be done in so few bytes? What strange language is this? I want to know what this whole thing is about!)

On the other hand. something like

Luft, 35 trits


Agua, 4 codels

doesn't mean anything for them, and is less motivating (Huh, no idea what this is. Moving on). Former moderator Alex A. perhaps explained it better.

  • 2
    \$\begingroup\$ Are you suggesting rolling back our consensus on fractional bytes or just suggesting that units should be converted to bytes? I find it a bit unclear in your answer. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 19, 2023 at 2:43
  • 1
    \$\begingroup\$ @WheatWizard I think I mixed up the two questions. My proposal would be to roll back the consensus of fractional bytes. But then, perhaps this should have been posted as an answer to the other question \$\endgroup\$
    – Luis Mendo
    Commented Apr 19, 2023 at 9:04
  • 1
    \$\begingroup\$ Huh, TIL that log-bytes scoring had been proposed before. That's an interesting discussion to read through now. \$\endgroup\$
    – DLosc
    Commented Apr 24, 2023 at 16:12

Yes please

I acknowledge they I am the original perpetrator of the log byte thing, having created Fig, but after the creation of Thunno, I became slightly disillusioned with it. After seeing the unary example, I was ticked off.

I agree with allowing scoring systems other than bytes, but that brings a problem. How are we to compare scores? How many qubits are in a byte? If we are to adopt this, such would warrant a separate meta discussion.

  • 4
    \$\begingroup\$ Yeah, I also accept some responsibility for having continued the tradition with Thunno. \$\endgroup\$
    – The Thonnu
    Commented Apr 13, 2023 at 15:54
  • \$\begingroup\$ A qbit is actually an infinite number of bits, since a qbit can have the value of any real number between 0 and 1, when a bit can only be 0 or 1, nothing in-between. \$\endgroup\$ Commented Apr 13, 2023 at 16:56
  • 3
    \$\begingroup\$ @Hippopotomonstrosesquipedalian Sort of, but you can't actually store and make use of infinite amounts of information in just one qubit. I believe the best you can do is 2 bits per qubit with superdense coding. Additionally, using quantum teleportation, you can send a quantum program to someone using 2 bits of data per qubit. Thus, 2 bits/qubit is a very natural way to score them. \$\endgroup\$ Commented Apr 13, 2023 at 17:19
  • \$\begingroup\$ @RydwolfPrograms while true, I was bringing it up as an example, it's not restricted to just qubits. \$\endgroup\$
    – Seggan
    Commented Apr 13, 2023 at 18:06
  • 2
    \$\begingroup\$ @RydwolfPrograms I think that consuming pre-shared entangled pairs should count against the data sent. Without that Holevo's bound limits you to one bit per qubit, assuming you have to actually reliably recover every bit, so I think that's the fair going rate. \$\endgroup\$
    – xnor
    Commented Apr 13, 2023 at 18:16

Different languages don't need to compete against each other

Most challenges state that the winner is the shortest code per language. It doesn't really make sense to compare a submission in Piet to a submission in Vyxal because they use different scoring systems. I think that as long as the scoring system for a given submission is consistent among all submissions in that language, I don't see why submissions would be scored using a system that inaccurately represents how large the program actually is.

I think some of us are forgetting that the point of code golf is to have the least amount of code possible to solve a problem, and are getting too caught up on how to define "the least amount of code." It doesn't matter! Submissions in languages where it doesn't make sense to score in bytes shouldn't worry about byte count because it's inaccurate to their size.

As long as all submissions of a given language use the same scoring system, they should be allowed to score in whatever units they want.

  • \$\begingroup\$ I think the issue is for this answer is "If we need everyone using the same language to use the same system, how do we ensure that happens?" What mechanisms are going to be in place to decide the "right" score for a language and what mechanisms are going to be in place to prevent people from golfing with the "wrong" score? \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 22, 2023 at 16:24
  • \$\begingroup\$ @WheatWizard A consensus would have to be made for how to score each language (bytes by default where it makes sense). I'm not sure how to enforce it but one way could be commenting and editing submissions whose score is inaccurate. \$\endgroup\$ Commented Apr 22, 2023 at 19:25
  • \$\begingroup\$ What's to prevent someone from just saying "I'm not golfing in Piet (codels) I'm golfing in a different language called Piet (bytes)"? And why do we even want to stop them? What's so wrong with someone pursuing a slightly different objective that we need to have all these special rules to prevent them? \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 22, 2023 at 20:28
  • 1
    \$\begingroup\$ @WheatWizard Somebody can write a submission in Piet (bytes), but it just won't compete against submissions in Piet (codels). I find it unlikely that this scenario would happen though, but I'm not experienced with this site's moderation. \$\endgroup\$ Commented Apr 22, 2023 at 20:37

Yes but with limits

I think answers still must be in units convertable to bytes. That means trits, 96-its, etc. would be allowed, but not, e.g., codels. While answers might use different units, they still need to measure something representable using bytes. A 96-it is still \$\frac{log_2{96}}{8}\$ bytes, and a trit is still \$\frac{log_2{3}}{8}\$ bytes, we just save the clutter of putting that in the header.

I don't think we need a meta consensus for this tho; it's just a different way of writing the same information. We've never had a rule saying you can't do that.


You must log in to answer this question.

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