3
\$\begingroup\$

Jelly is one of those languages that doesn't use ANSI text in its code. Why should we score Jelly by its character count when each character can take up to 4 bytes?

For example, take this answer (Authored by Dennis):

ḃ2-*µSN;+\>-Ạ
1Ç#Ṫḃ2ṭ2;1ị⁾][

From a character counter, one can see that this is exactly 28 characters (which is how Jelly is currently scored). However when I save this into a txt file (with no metadata in the file size), it could be up to 112 bytes (28*4). However, when saved onto an uncompressed disk, it is 60 bytes. This is still many times more than what is currently scored. I may reference my Excel scoring thread, with users agreeing that excel can be scored by file size in indeterminate cases. It seems that the same should be done with Jelly- as its' characters DO take up more than one byte.

IF as a community we somehow decide that this isn't the case, and we should judge jelly by its character count alone, Then I will have something to introduce to the community soon-ish.

\$\endgroup\$
5
  • 5
    \$\begingroup\$ On a related note, Jelly is not the only language where this discussion keeps coming up. Off the top of my head, other languages that cause this same argument many times are Seriously, Actually, 05AB1E, V, and APL. Like Martin said, there are all acceptable because they use a custom code page (mostly for convenience, not for a smaller byte-count) \$\endgroup\$
    – DJMcMayhem
    Commented Sep 28, 2016 at 20:57
  • \$\begingroup\$ @DJMcMayhem Read the top answer. It explicitly mentions Jelly and its code page. \$\endgroup\$
    – user45941
    Commented Sep 29, 2016 at 14:50
  • 1
    \$\begingroup\$ Jelly has its own code page, and it still scored in bytes, not characters. Voting to close. \$\endgroup\$
    – mbomb007
    Commented Sep 29, 2016 at 21:16
  • 3
    \$\begingroup\$ Also maybe a duplicate of What character encodings may a submission use? \$\endgroup\$
    – mbomb007
    Commented Sep 29, 2016 at 21:18
  • 5
    \$\begingroup\$ Why was this reopened? We have three perfectly good dupe targets: meta.codegolf.stackexchange.com/questions/5878/…, meta.codegolf.stackexchange.com/q/10145/45941, and meta.codegolf.stackexchange.com/questions/9428/… \$\endgroup\$
    – user45941
    Commented Oct 29, 2016 at 1:07

2 Answers 2

Reset to default
14
\$\begingroup\$

Jelly uses its own code page and the interpreter is capable of reading files encoded in this code page. Hence, it's actually possible to feed a working file of the claimed size to the interpreter and therefore the byte count is completely legitimate. Here is the relevant meta post which says that answers can use any encoding of their choice, as long as it existed before the challenge and is actually executable.

Note that this doesn't give Jelly any unfair advantage over a language that doesn't invent its own code page: one could equally well write a golfing language which uses all 256 characters of some standard code page like the extended ASCII standard ISO 8859-1. It's just that in that case a lot of the characters would be unprintables, which would be a lot more annoying to work with. The only advantage Jelly gains from defining its own code page is that all the characters are printable (and even typeable on an International US keyboard layout) and allow Dennis to choose nicer mnemonics for the individual commands.

\$\endgroup\$
10
  • 1
    \$\begingroup\$ What about other codes that use more that 256 characters? \$\endgroup\$
    – user56309
    Commented Sep 28, 2016 at 20:32
  • 1
    \$\begingroup\$ @tuskiomi That seems like a very hypothetical question. My point is that the score of an answer should be the smallest physical size of a source file you can feed to the interpreter. You can make up any encoding you want if you want to use more than 256 characters. If your interpreter can work out what the byte stream means, it's fine. \$\endgroup\$
    – Martin Ender Mod
    Commented Sep 28, 2016 at 20:33
  • \$\begingroup\$ So, even though the smallest physical size of the program is 60 bytes, it still counts as 28, because one could represent it in 28 bytes? \$\endgroup\$
    – user56309
    Commented Sep 28, 2016 at 20:36
  • 6
    \$\begingroup\$ @tuskiomi No, the smallest physical size of the program is 28 bytes. You can actually feed a 28-byte sized file to the Jelly interpreter and it will work, if that file is encoded with Jelly's code page. \$\endgroup\$
    – Martin Ender Mod
    Commented Sep 28, 2016 at 20:40
  • \$\begingroup\$ @MartinEnder wait, in this case shouldn't the submission be in Jellys code page? (or at least a HW dump or something of the jelly-encoded code included?) \$\endgroup\$
    – Downgoat
    Commented Sep 28, 2016 at 21:19
  • \$\begingroup\$ @Downgoat I'm not sure what you mean. Since we can't put arbitrary byte streams in answers (and because that would be rather unhelpful), we usually present solutions as a listing of its characters (unless there are unprintables in which case some people include a hex dump) and mention which encoding they use. Dennis usually links to the code page in the header of his answers. \$\endgroup\$
    – Martin Ender Mod
    Commented Sep 28, 2016 at 21:23
  • \$\begingroup\$ Another way to think of it is that the characters are representations of the byte values of the input file. A nice table provided by Adam here lists the code points of each character used for each byte value. You can choose to either input a UTF8 file to Jelly, in which that input file would require 60 bytes to store, or you could input a binary file. It doesn't come without cost though since Jelly does not understand any characters outside of its code page, they are essentially ignored. \$\endgroup\$
    – miles
    Commented Sep 28, 2016 at 21:24
  • \$\begingroup\$ @MartinEnder I understand that part but if the given submission counts the bytes of a certain byte stream, should it not be those bytes which are posted? (e.g. as a hex dump) \$\endgroup\$
    – Downgoat
    Commented Sep 28, 2016 at 21:25
  • 2
    \$\begingroup\$ @Downgoat I think that would add very little benefit for a lot of clutter. The answer presents the characters used (whose Unicode code points you can look up) as well as the code page which maps these code points to bytes. \$\endgroup\$
    – Martin Ender Mod
    Commented Sep 28, 2016 at 21:26
  • 4
    \$\begingroup\$ As ugly as Jelly can sometimes appear (sorry Dennis ;) , I'd still much rather see that than hex dumps everywhere. \$\endgroup\$
    – Geobits
    Commented Sep 29, 2016 at 1:09
10
\$\begingroup\$

As Martin already explained, Jelly uses a custom code page that is incompatible with ASCII and UTF-8. This isn't a made-up way of counting bytes, but the Jelly interpreter can take the source code (and input/output, if desired) using this code page. This is actually the default for the official interpreter, which requires the u flag to process UTF-8 encoded source code.

For the answer in question, the byte count with Jelly's code page is in fact 28 bytes, and the 28 byte file is functionally equivalent to the UTF-8 encoded 44 byte file.

$ cat nest-utf8.jelly; echo
ḃ2-*µSN;+\>-Ạ
1Ç#Ṫḃ2ṭ2;1ị⁾][
$ wc -c nest-utf8.jelly
44 nest-utf8.jelly
$ xxd -g 1 nest-cpj.jelly
0000000: e7 32 2d 2a 09 53 4e 3b 2b 5c 3e 2d ab 7f 31 0e  .2-*.SN;+\>-..1.
0000010: 23 ce e7 32 e0 32 3b 31 d8 8e 5d 5b              #..2.2;1..][
$ wc -c nest-cpj.jelly
28 nest-cpj.jelly
$ jelly fun nest-utf8.jelly 8
[[[[]]]]
$ jelly fn nest-cpj.jelly 8
[[[[]]]]

If Jelly was only able to process UTF-8 encoded files, I would have to score (and would have) the answer as 44 bytes. However, since there is a 28 byte file that solves the task at hand, I am able to claim a score of 28 bytes.

\$\endgroup\$
0