Allow answers to be scored in things other than bytes to stop the log byte madness

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

or

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.

Answer 4

Different languages don't need to compete against each other

Most code-golf 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.

Answer 5

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.