15
\$\begingroup\$

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?

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I will never upvote an answer with the fractional bytes gimmick. Then again, I lean heavily on the non-flexible and rigorously defined I/O side, versus the "make up your own I/O" side. \$\endgroup\$
    – qwr
    Commented Feb 4 at 4:49

4 Answers 4

Reset to default
14
\$\begingroup\$

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.

Wheat Wizard'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.

\$\endgroup\$
5
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Jan 18, 2022 at 2:04
  • 1
    \$\begingroup\$ What if the byte count was log(9), pi-3? imaginary numbers? \$\endgroup\$
    – Fmbalbuena
    Commented Jan 18, 2022 at 20:52
  • 2
    \$\begingroup\$ @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. \$\endgroup\$
    – rydwolf
    Commented Jan 18, 2022 at 20:59
  • 2
    \$\begingroup\$ 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? \$\endgroup\$
    – Darren Smith
    Commented Jan 19, 2022 at 0:39
  • 1
    \$\begingroup\$ @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 \$\endgroup\$
    – rydwolf
    Commented Jan 19, 2022 at 0:41
7
\$\begingroup\$

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.

\$\endgroup\$
1
  • 13
    \$\begingroup\$ 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). \$\endgroup\$
    – Nitrodon
    Commented Jan 6, 2022 at 19:19
2
\$\begingroup\$

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.

Advantages:

  • This is consistent with our requirement that you must be able to actually represent your code as a file to input to an interpreter
  • This reduces confusion about what exactly "being able to represent your code as a file" means
  • This keeps the scoring unambiguous for non-bit-based languages; you must represent the trits/algebraically encoded data/whatever else as a sequence of bytes, it can't just be scored as an irrational number of bits

Disadvantages:

  • This creates a (possibly somewhat artificial in certain languages) divide between the way full programs and functions are scored, adding confusion
\$\endgroup\$
-2
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ 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. \$\endgroup\$
    – Bubbler
    Commented Jan 20, 2022 at 4:35
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – Bubbler
    Commented Jan 20, 2022 at 4:39
  • \$\begingroup\$ @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 \$\endgroup\$
    – l4m2
    Commented Jan 20, 2022 at 4:40
  • 1
    \$\begingroup\$ 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? \$\endgroup\$
    – Bubbler
    Commented Jan 20, 2022 at 5:02
  • \$\begingroup\$ @Bubbler By 3/5 I mean \$log_{256}5\$ bytes and choose the 3rd possible code \$\endgroup\$
    – l4m2
    Commented Jan 20, 2022 at 5:20

You must log in to answer this question.

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