What is our consensus for fractional byte functions?

In a discussion about SBCSs and other code pages, fractional byte counts were briefly brought up. I brought up our consensus that fractional byte programs are disallowed, and it was pointed out that the consensus does not disallow functions in languages with fractional byte code pages from having a fractional score.

Multiple languages with fractional byte counts have been developed recently, with the ones I'm aware of being Risky, HBL, and Nibbles. DLosc and I, who wrote two of those three, were both surprised by the fact that fractional byte functions currently seem to be allowed.

So...

For languages with fractional byte code pages, such as half-byte code pages or huffman coding, should functions be allowed to be submitted without padding to a whole number of bytes?

Our current consensus seems to only apply to full programs, as it dicusses storing the program on the user's filesystem. However, since a function is only a part of a program, requiring padding to an integer byte count might not make as much sense. This question's mostly looking for a consensus for functions, but it would also be a good place to dicuss our consensus on full programs if anyone thinks that needs changing.

It might also be worth considering languages which don't even have a whole number of bits, such as ones which use trits. Currently we'd require writing an implementation of the language that represents the program with bytes, but if fractional byte counts are allowed, that might bring up the question of whether a 1 trit function could be log_2(3) bits.

What should our consensus be for fractional byte programs and functions?

Fractional byte counts are always allowed

It seems like one very simple solution to this problem is to allow fractional byte counts, for functions and full programs.

WW's answer implies that some sort of custom designed file system would need to be written, after which point this would be the case anyway. This weird sort of file-system-simulator-that-dies-for-our-sins just adds unnecessary complexity.

Scoring functions with fractional byte counts makes sense, I think that's something that almost all of us currently agree on. So, allowing this for full programs seems like a reasonable extension to the rule.

Although this slightly contradicts the rule of "you must be able to represent your program as a file which you provide to a compiler/interpreter", it does so in a way that preserves simplicity and allows a broader number of languages to compete, which I think is a good compromise.

• FWIW, at this point I endorse this. We've talked a lot about different methods and I think this is the policy that puts fun first. Our "objective" policy had a lot of hidden quirks and subjective edges anyway.
– Wheat Wizard Mod
Jan 18 at 2:04
• What if the byte count was log(9), pi-3? imaginary numbers? Jan 18 at 20:52
• @Fmbalbuena This is a good thing to bring up, since log_2(x) bytes actually does come up quite often when using things like trits or algebraic encoding. So, I'd say that yes, irrational byte counts are allowed. However, imaginary byte counts don't seem like something that our current scoring can reasonable handle, so those probably shouldn't be allowed. Jan 18 at 20:59
• Two reasons I support this. 1) It is super annoying if you write a 9.5 byte program and have to round up causing you to tie instead of beat a competitor. 2) 8 bit file size chunks is completely arbitrary, it just happens to be widely used, why worship this tradition? Jan 19 at 0:39
• @DarrenSmith Under current rules, it's actually even more complicated than that. If the language doesn't have a built-in way to pad it to a full number of bytes, you'd have to write your own patch for the interpreter such that it can read a 9 byte file containing that code. So yeah, allowing fractional byte counts for the win lol Jan 19 at 0:41

The answer's score is still the source code's size

Fractional byte scores are not disallowed, they just have to be from answers that actually have fractional byte scores "on disc".

Functions

Since functions are pieces of source code and not complete programs their score is the size they contribute to the program when added.

This means it's totally possible for a function to only take up 36½ bytes of a program. If a programming language uses half byte characters then you could write a 36½ byte function and still use that extra ½ byte for other stuff.

It doesn't matter that the function can't be put in its own file without padding, because you don't do that with functions. That's not how you use functions. I could putt a million copies of my function in the file and only ever have to pad by half a byte. I think that makes it pretty clear that the half byte of padding is not a part of the function.

Complete Programs

As for complete programs. If the file is $$\N\$$ bytes on disc then that is your score. If you want to make a virtual file system that allows you to make files of non-integer byte sizes, and these files can be packed together without padding, so they truly take up a non-integer number of bytes, then you can do that. The size of the file is simply the amount of space it increases the size of the file system by. I think pretty clearly then your file is not taking up an integer number of bytes, so it's score is not an integer number of bytes.

Summary

The way to determine the size of a program is to look and see how many bytes it takes to actually store it in an existing computer system.

For me this is simply a clarification of Dennis' original answer. And I think this way of doing things is fair, straightforward and consistent with established consensus.

• My computer uses NTFS. I doubt you really want me to change most of my complete program scores to 1024 bytes (the size of a NTFS base record). Jan 6 at 19:19

Allowed byte count is $$\\log_{256}k\$$

If a chosen length has $$\k\$$ states, then it has $$\\log_{256}k\$$ bytes.

Allowing arbitrary byte count lead to some weird languages(lenguage but the length ^-1).

Trying to abuse it save at most half of length.

• In other words, (at least to me) this proposal means to only allow the byte-count-equivalents assuming discrete storage media. If a unit of a certain (possibly hypothetical) storage can store $k$ distinct values, then a program that takes $n$ units of that storage has the equivalent length of $n \log_{256} k$ bytes, and non-integral value of $k$ or $n$ is not allowed. Jan 20 at 4:35
• Honestly I don't yet see how a program in some language could achieve any different kind of number of bytes. If anyone can come up with a concrete example, please share the idea and we can discuss whether it is fun or abusive. Jan 20 at 4:39
• @Bubbler Not that equal. Your model make every unary solution 0 byte using an unary model, while I allow 3/5 and 12345/12347 and similar stuff
– l4m2
Jan 20 at 4:40
• When it comes to unary, your first statement isn't quite correct either. There is only one unary code of a given length, and $\log_{256} 1 = 0$. I didn't mean to handle unary here; otherwise we need to take the cumulative number of states into account, which would become too complex for a site-wide ruling. Also, what do you mean by 3/5? Is it the byte count or $k$ or $n$? If you allow non-integral numbers for $k$ and $n$ then how is it different from the existing proposal? Jan 20 at 5:02
• @Bubbler By 3/5 I mean $log_{256}5$ bytes and choose the 3rd possible code
– l4m2
Jan 20 at 5:20

Full programs, full bytes

This suggestion would likely work alongside others' answers, but if part of the consensus it would clear up some possible future confusion.

All full programs must be a full number of 8-bit bytes. There are essentially no modern systems which use anything other than 8-bit bytes, so keeping this as a default is reasonable (since hardware which can/is intended to store fractions of 8-bit-bytes on disk is rare).

This prevents any issues that could come up if someone were to, for example, write an entire operating system around their esolang which supported 6-bit bytes. This would prevent them from claiming that they can store a 36 bit program on their machine, and that it should be allowed to be scored as 4.5 bytes.