-3
\$\begingroup\$

I am asking this because Vyxal, and mainly Vyxal has a compression algorithm to shave bytes off. I think of this as a bit unfair, so I would like to propose the following:

  • If a programming language has a compression algorithm, then include the compressed score and the normal score.
  • Furthermore, rank both scores. For example, if you had ɖ+ṁ with 3 bytes in Vyxal, and compressed as 3.25 bytes, then you would rank Vyxal as 3 bytes and Vyxal (compressed) as 3.25 bytes.
\$\endgroup\$
2
  • 1
    \$\begingroup\$ All's fair in golf and war, I'd say. If you don't like Vyncode beating you, why not write your own compression scheme and outdo it? \$\endgroup\$
    – Ginger
    Sep 22 at 22:40
  • 1
    \$\begingroup\$ Also, Vyncode doesn't always shave off bytes, I've had some 6/7 byters that are the same length \$\endgroup\$ Sep 27 at 13:49

3 Answers 3

7
\$\begingroup\$

Why should separate languages be scored as the same language?

The current code golf command line flag policy is that using flags in a submission makes the submission in a unique language. So why should a flagless variant of a language include the flagless score?

"What do flags have to do with this?" you ask.

Well technically speaking, Vyncode is a command line flag. It's literally implemented as the = flag. This was done for user convenience, and the byte count header doesn't include the flag explicitly because it's implied by the fact the answer is scored in bits.

So by site meta consensus, Vyncode is a flag variant, meaning it doesn't count as Vyxal at all. So why should both bit count and sbcs count have to be included?

\$\endgroup\$
5
\$\begingroup\$

There's also other problems

People might not want to use the encoding at all

There's been many cases of people saying that they don't want to use the encodings because they don't feel comfortable doing so. Should they be forced to use it just because it exists?

How retroactive would the change be? Would it need to be edited in to all answers using a compression algorithm?

There would be a lot of answers on the site using some sort of encoding. Vyncode is far from the first compression algorithm as algorithms like Packed Stax exist, and have done so for many years. Should all of those answers be edited, flooding the home page?

What counts as a compression algorithm?

Where do you draw the line between having a compression algorithm and being inherently compressed? What about one of the many fracbyte languages? Do they use compression algorithms? Or what if there's no way to run a non-compressed program, but you can only generate programs using an external compressor?

Overall, this would be inconvenient and a hassle for everyone, just for the sake of feeling "fair"

\$\endgroup\$
-1
\$\begingroup\$

Why not simply boycott what you dislike?

As for me, compressed scores are no fun. Code golfing was always about the size of source code, and nobody writes compressed code. You could do that with any programming language (achieving a far better compression ratio for most), but nobody ever did it, because it adds some randomness to the challenge: A better golfed version in terms of shorter source code can be overtaken by lazy code, which happens to compress better.

On the other hand, it's difficult to forbid that. Where is an exact border between compression and some other golfing language tricks? Those rely to a certain degree on commands that can to some extend be seen as a couple of instructions "compressed" into a single byte. I still like it because you can do clever golfing tricks with them.

For myself, I decided not to upvote answers like that. For answers to my own questions with cleverly golfed source, but compression flag, I plan to comment that I will upvote the uncompressed version (unless the author can explain some brilliant ideas how this was designed for better compressability – unlikely to happen).

I invite you to join this way to handle it. Don't cheer a doped athlete.

\$\endgroup\$
9
  • \$\begingroup\$ "unless the author can explain some brilliant ideas how this was designed for better compressability – unlikely to happen". I've spent upwards of 20 minutes trying different combinations of built-ins to see which combination gives the optimal bit count. So it's more than likely that there's an explanation of better compressibility - it's already a thing. \$\endgroup\$
    – lyxal
    Oct 3 at 11:08
  • 1
    \$\begingroup\$ Also, is that to say that all effort put into making an answer work and be as short as possible should just be completely unrewarded just because it uses compression to sweeten the byte count? That seems harsh to discredit hard work because a few bytes were saved. \$\endgroup\$
    – lyxal
    Oct 3 at 11:10
  • 1
    \$\begingroup\$ @lyxal You see the difference between »trying different combinations« and »some brilliant ideas«? And the second comment is already answered: I upvote the uncompressed answer to reward the short source code. If someone prefers to stay unrewarded by posting not uncompressed answer, it's not my problem. \$\endgroup\$
    – Philippos
    Oct 3 at 11:55
  • 1
    \$\begingroup\$ No, I don't see the difference. In fact, trying different combinations is often times the same as trying different ideas. Just basing your rewarding method based on whether a compression system is used means that your essentially penalising other people's decisions to do what they want with golfing. It'd be different if answers all competed against each other, but they don't (as per site consensus). In essence, the bit count is only to look good and to have fun figuring out how to shave 1 or 2 bits off when the margin of doing so is already extremely hard. \$\endgroup\$
    – lyxal
    Oct 3 at 12:31
  • \$\begingroup\$ @lyxal We are not talking about any other language. Per site consensus, the vyxal score will not compete against the vyncode score. They need to have different answers. Like many others, I enjoy clever vyxal answers and usually upvote them, but we are free to upvote just what we understand. I neither understand non-obvious unexplained code nor the brilliance of preferring commands with better compressability, so I don't vote on them. Others may do so, if they like it, but why force anybody? This site is designed to let everybody enjoy it the way they prefer. \$\endgroup\$
    – Philippos
    Oct 3 at 12:50
  • 1
    \$\begingroup\$ I think what I'm really trying to say is that refusing to vote based purely on using a compression scheme doesn't seem like the best idea. Because that means you might scroll past an answer that took a lot of effort and uses encoding, and then see an answer that looks like it took a lot of effort when it's just a lazy answer itself. \$\endgroup\$
    – lyxal
    Oct 3 at 12:51
  • \$\begingroup\$ Also, what I'm talking about applies to any language with an optional compression system (e.g. Packed stax) \$\endgroup\$
    – lyxal
    Oct 3 at 12:53
  • 1
    \$\begingroup\$ @lyxal I'm not to judge why the author choose not to give an uncompressed answer. Let authors decide which answer to post or both, and let others decide what to upvote. As I told the OP not force others on how to enjoy the site, I'm telling you the same. You seem not the have any point to convince me. \$\endgroup\$
    – Philippos
    Oct 3 at 12:57
  • \$\begingroup\$ @Philippos If you want, you can discuss this with us in chat. \$\endgroup\$
    – Ginger
    Oct 3 at 13:44

You must log in to answer this question.

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