This was prompted by the recent meta post about byte compression in scores, as well as other bits of confusion and uncertainty I've seen on the site.

If you've been around on the main site in the last 4 months, you may have noticed answer headers like these:

enter image description here

enter image description here

enter image description here

And you may have wondered "hang on a second, I thought Vyxal 2 was scored using a Single Byte Character Set! How can it be scored in bits?"

Well, you're right. By default, Vyxal is indeed still scored as SBCS. However, as of the 29th of April 2023, it can also be scored using a compression technique called range coding.

This meta post serves as an explanation of Vyncode in the context of the site. It also gives usage guidelines.

What is Vyncode?

To quote the repository:

Vyncode, pronounced "vine code" for consistency with the rest of the organisation, is a compression system for Vyxal programs. It turns SBCS code into a string of bits, which may or may not result in a whole amount of bytes. Oftentimes, you'll see some fraction of a byte in the byte count.

In other words, it's a way to encode normal SBCS programs as a string of bits, which can then be scored as per site consensus.

Vyncode uses a range coder to generate compressed bitstrings. It's a tiny bit complicated to explain in a meta post (I barely understand how it works myself), but it's essentially Huffman coding but way better. As of version 2 of Vyncode, it's "trained" on roughly 1400 vyxal programs taken from CGCC answers, Codidact answers, and week.golf submissions.

When given a SBCS program, Vyncode will compress it, and return a bitstring. When given a bitstring, Vyncode will decompress it, and execute the resulting SBCS program. For example:

1 2 3 ++

Turns into:


Which is 53 bits/6.625 bytes, 1.375 bytes shorter.

How is Vyncode used?

Short answer: As a flag.

For technical reasons, Vyncode is implemented using command line flags (more on the implications of this later). These flags are the ! flag and the = flag.

The ! flag reads a bitstring as the program, converts to SBCS internally, and executes the resulting program. It exists mostly so that people can verify that a bitstring is actually being executed (kinda like how languages like Vyxal and Jelly have a flag that strictly reads a file as raw bytes).

The = flag reads a SBCS program, executes it normally, and then prints the compressed bitstring. This is what's most commonly used for Code Golf answers, as it means that people can golf using SBCS characters for convenience and let the interpreter worry about mucking around with bitstrings.

On the online interpreter (hosted at https://vyxal.pythonanywhere.com/ for version 2 [version 3 coming soon]), both the ! flag and the = flag will switch the byte count to bits. The = flag generates a real-time bit count (albeit a little slow, as is the nature of range coding).

How come the bit string isn't present in the answer when using the = flag?

Short answer: Convenience. A long string of bits doesn't help anyone.

Do you really want a long string of 0s and 1s in the answer text? It's automatically printed when you visit the try it online link and doesn't actually have any mnemonic meaning, so it doesn't help anyone wanting to understand the answer.

The SBCS is presented for convenience. The bitstring could have been used, or included somewhere in the auto-template, but that probably wouldn't have looked as good.

What's the superscript number in the answer header for?

Short answer: The version of vyncode.

That represents the version of Vyncode the answer used. At the time of writing, there are 2 versions of Vyncode, both with a different corpus used for training. It's present because a program compressed using v1 for example will give a different bitstring than the result of using v2 on the same program.

The version of Vyncode used can be changed on the online interpreter:

enter image description here

The idea is that because there's no way to specify a version, backward compatibility for scoring needs to be implemented separately.

What are the implications of Vyncode being a flag variant?

The implication of Vyncode being flag enabled is that it's technically a separate language, as per site consensus. It may be unofficially considered the same as base Vyxal, but it's officially considered different.

If vyncode is a flag variant then why isn't the flag present in the header like other flags are?

Because it's present in the word "bits". It should be somewhat obvious by the fact that there's a non-standard byte count that something "non-base-language" is going on. It's also much cleaner to not have the = or ! flag in the header.

Can I use a version of Vyncode newer than a question?

Obviously, the answer is "yes", because it's not like anyone is going to hunt you down and stop you from doing so. (At least as far as I know).

More seriously, that's a bit of a grey area. Someone may have already submitted an answer to that question, meaning the program would be in the training data. This leads to overfitting, which may or may not fall under the loophole of creating a language specifically for a challenge. I say may or may not because it'd need discussion and input from people more knowledgeable.

As a general rule of thumb, don't Vyncode existing answers. Doing so avoids any possibility of cheating from intentional overfitting. It is, of course, perfectly fine to Vyncode an answer that contains parts of existing answers.

Should I go around leaving comments that an answer could be better scored with Vyncode?


All questions of overfitting aside, do not use Vyncode as a golfing suggestion. Some people might not want to use it, or might not have had access to it at the time (i.e. all answers before April 2023). So don't create noise for them.

To quote myself:

Generally, if an answer doesn't use Vyncode, leaving a comment like "hi there hello use Vyncode to get this shorter" isn't helpful

And to quote myself again:

However, you can a) vyncode a golfing suggestion that would otherwise save sbcs bytes and b) suggest a shorter bit count if vyncode is already used (two programs can be functionally equivalent and have different bit counts).

Can I use it for other languages?

Yes! Under site rules, you're allowed to use any encoding you want for your code. While Vyncode is specifically optimised for Vyxal code, there's nothing stopping you from training the range coder on large amounts of golfed code in other languages.

Anyhow, that's all for now. Hopefully, that clears a few things up regarding Vyncode. Now would you like fries with that?



Browse other questions tagged .