14
\$\begingroup\$

So far, submissions consisting of multiple files have simply been counted by summing up the scores of the individual files. Also file names aren't counted as long as they are arbitrary. (We do count file names if the code depends on them to work correctly, i.e. if actual code is outsourced to the file name.)

I've been making (ab?)use of that in Retina by determining the mode of operation implicitly from the number of files supplied. I don't see this particular case as much of a loophole abuse (but rather as elegant golfing language design), but there definitely is room for abuse:

  • One could write a Unary derivative that doesn't take a string of 0s, but instead whose program consists of N empty files, where the number of files is interpreted as the unary code. This would essentially give you score 0 for arbitrary programs.
  • One could use two different files with arbitrary contents and encode a program in binary from the sequence they are given to the interpreter (the first being 1, the second 0, or vice versa).
  • One could identify the most common character in a language, and split the code into files around that character (i.e. the interpreter joins the files together with that character).
  • etc...

Before I'm further accused (winky face) of abusing loopholes, let's settle this and decide how we deal with multi-file programs when counting code golf.

\$\endgroup\$
2
  • \$\begingroup\$ Also file names aren't counted as long as they are arbitrary. (We do count file names if the code depends on them to work correctly.) - This is this all over again. \$\endgroup\$
    – Optimizer
    Commented Mar 24, 2015 at 20:05
  • 1
    \$\begingroup\$ This question has an accepted answer, but that answer contains two alternatives, making it unclear what the decided policy is. Is it possible to disambiguate this? (I have an upcoming challenge where this will likely be relevant.) \$\endgroup\$
    – N. Virgo
    Commented Jan 8, 2018 at 1:52

3 Answers 3

Reset to default
22
\$\begingroup\$

This proposal is trying to close all of these loopholes with two policy changes.

  1. Add 1 byte or character for each file after the first. This means that you can still split up your code into multiple files and even make the distribution into files significant for your program, but it's going to cost a little, which especially means that the Unary-derivative would be no more useful than Unary itself.
  2. If files are reused, because multiple files in the program would be identical, you have to count the contents of that file as many times as you use it.

Example

If your invocation was 

./mylang file1 file2 file1

your score would be the size of file2, plus twice the size of file1, plus 2 (one for each file after the first).

I have considered another ruling for the second case: one can argue that it makes the file name significant. So instead of counting the file contents twice, you count them only once, but then you include the file name in the count for each time its used. In this case, in the above example, you'd probably name file1 just a instead, so the invocation becomes

./mylang a file2 a

Now the score is the size of a (once), plus the size of file2, plus 2 (for each file after the first), plus 2 (for using the significant file name a twice).

Let me know in the comments what you think about these two alternatives.

\$\endgroup\$
8
  • \$\begingroup\$ You should add 2 bytes per additional file as per the same logic additional compile/run time flags cost 3 bytes and not 2 [the space is counted] \$\endgroup\$
    – Optimizer
    Commented Mar 24, 2015 at 19:42
  • 3
    \$\begingroup\$ @Optimizer If you want you can think of the additional byte/character as only the space. You get the file name for free since we don't count file names in general. Also, I'm not sure I personally agree with the logic behind counting flags as 3 bytes anyway. However, the real reasoning is that splitting it into files doesn't really give you more than one byte of information: you could also put all files into one and delimit them with null-bytes or something. But that would just be a pain for everyone writing or testing the code, so why punish people for splitting up the files instead? \$\endgroup\$
    – Martin Ender
    Commented Mar 24, 2015 at 19:53
  • \$\begingroup\$ We don't count file name in general considering that there is only one file and we have to run it. Since we are in multiple files land, we have to consider the names now. One could argue that I can put a part of my code in the file name and the language understands that \$\endgroup\$
    – Optimizer
    Commented Mar 24, 2015 at 20:00
  • \$\begingroup\$ @Optimizer If you put part of your code in the file name, it's significant and it counts. That's not even in question. This rule is merely about using multiple files with arbitrary names. \$\endgroup\$
    – Martin Ender
    Commented Mar 24, 2015 at 20:01
  • \$\begingroup\$ This is a similar argument to what should be counted as comment in the code. \$\endgroup\$
    – Optimizer
    Commented Mar 24, 2015 at 20:03
  • 8
    \$\begingroup\$ I like one byte per extra file because I think of it like having a "newfile" character in your code. \$\endgroup\$
    – Sp3000
    Commented Mar 25, 2015 at 1:33
  • \$\begingroup\$ @Sp3000 That would be ASCII character 28 "FILE SEPARATOR". \$\endgroup\$
    – 12Me21
    Commented Jun 4, 2018 at 18:50
  • \$\begingroup\$ This method does not lower-bound the information content of an answer. I could create a language with 257-character code page and replace every instance of the extra character with a file separator, paying no penalty for this. While the 0.07% gain is pretty small, it does make a difference. \$\endgroup\$
    – lirtosiast
    Commented Jan 21, 2019 at 21:28
-1
\$\begingroup\$
  • For each extra file, add as many bytes to the score as when you required to type in those additional files. Ideally you would want to save some bytes here and use single byte file names.

So suppose your code is split across file a, h and k.txt and the code needs to be run like

myLang a h k.txt

and also that the sum of code inside all these three files is 100 bytes, then your total score is 100 + 1 + 1 + 1 + 5 = 108 bytes. That is 1 for the space after a, 1 for file name h, 1 for space after h and 5 for filename k.txt

  • If you reuse a file, you have to count the contents of that file as many times as you use it along with the above rule
\$\endgroup\$
4
  • \$\begingroup\$ +1 from me. This is more or less on the same lines on the consensus around counting bytes for additional run time/compile time flags. \$\endgroup\$
    – Optimizer
    Commented Mar 24, 2015 at 19:58
  • \$\begingroup\$ Just so this comment is in the right place, I'll repeat myself here: I think this is pointless and just annoying. This essentially makes each additional file count two bytes. So if my language can deal with separate files, I'd just instead rewrite it to take a single file and delimit the parts of the file with an unused unprintable character. This only makes it a pain for me to write and for everyone else to test, because I've got to provide hexdumps of the code all the time then. This proposal does not close any additional loopholes or effectively change what scores can be achieved, so -1. \$\endgroup\$
    – Martin Ender
    Commented Mar 24, 2015 at 20:07
  • \$\begingroup\$ @MartinBüttner On the same grounds then, each additional runtime/compile flag should not take 3 bytes as those flags can be included in the file separated with a non printable character. I think you are just being biased here because the language in question is your own. \$\endgroup\$
    – Optimizer
    Commented Mar 25, 2015 at 4:35
  • \$\begingroup\$ "On the same grounds then, each additional runtime/compile flag should not take 3 bytes as those flags can be included in the file separated with a non printable character." Yes, I fully agree with that. Just because our existing policies aren't optimal doesn't mean we can't do it right with new ones. \$\endgroup\$
    – Martin Ender
    Commented Mar 25, 2015 at 9:46
-3
\$\begingroup\$

This is code golf. Count the total bytes of code.

If you have code in the file name, guess what? It's code! It counts!

If you have 100 bytes of code spread across three files, you score... wait for it... 100 bytes!

If your compiler behaves differently based on the number of files provided, then congratulations. You get to make use of that language feature.

\$\endgroup\$

You must log in to answer this question.

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