1
\$\begingroup\$

So I’ve been thinking about creating a golflang somewhat inspired by Jelly, but I’ve decided for it to be encoded in a 9-bit codepage, so that there are 512 possible characters to use. I can come up with a few different ways to score this, but I want to know what the recommended scoring method would be.

  1. Just count each character as 1 byte. This doesn’t seem fair, though, since there’s more information per character than in languages with an 8-bit codepage, so I wouldn’t recommend this.

  2. Count each character as 1.125 bytes. This would probably be the closest thing there is to a direct equivalence. The final result can either be left as a fractional value or rounded up, since a file in this encoding would have to be padded with up to seven bits at the end to make it an integer number of bytes.

  3. Count each character as 2 bytes, as in UTF-16. This would be the way my files would normally be stored before being compressed into the 1.125 bytes per character format.

What do you think?

\$\endgroup\$
8
  • 6
    \$\begingroup\$ You can define any encoding you like, but at the end of the day your interpreter must be able to read a file with the physical size you are claiming as your score. \$\endgroup\$
    – Martin Ender Mod
    Commented Sep 29, 2016 at 6:58
  • 4
    \$\begingroup\$ I think this is basically answered in this question and this question. \$\endgroup\$
    – Martin Ender Mod
    Commented Sep 29, 2016 at 7:05
  • \$\begingroup\$ Just so you know, (on a non-meta note) utf-16 is incredibly wasteful. I would recommend utf-8 instead since 1) It's the de-facto encoding of almost everything and 2) the lowest 128 code points are represented in a single byte instead of two. That will save a ton of bytes. \$\endgroup\$
    – DJMcMayhem
    Commented Sep 29, 2016 at 13:23
  • \$\begingroup\$ @MartinEnder I've been reading the comments made about this on the chat, and I think 1.125 bytes per character, rounded up to a whole number of bytes, would be the way to go. My interpreter can either read the source code encoded in UTF-8, or in a sort of base256, where 9 bytes stand for 8 characters, and the last block is padded with enough zero bits to make it a whole number of bytes, for example, 3 characters xxxxxxxxx yyyyyyyyy zzzzzzzzz are encoded into 4 bytes xxxxxxxx xyyyyyyy yyzzzzzz zzz00000. \$\endgroup\$
    – Ashtâr B.
    Commented Sep 29, 2016 at 21:30
  • \$\begingroup\$ @AshtârB. If your interpreter can actually do the latter, then yes you're allowed to count it as 1.125 bytes per character and round up. \$\endgroup\$
    – Martin Ender Mod
    Commented Sep 29, 2016 at 21:31
  • \$\begingroup\$ Now to finish that interpreter... There are still over a hundred unimplemented commands, and a few bugs while applying binary functions to implicit arguments... \$\endgroup\$
    – Ashtâr B.
    Commented Sep 29, 2016 at 21:34
  • \$\begingroup\$ @MartinEnder Yes, it can actually encode my 9-bit codepage into 8-bit bytes. I essentially modified Python 3's base64 encoder/decoder to handle 9-bit blocks instead of 6-bit blocks. \$\endgroup\$
    – Ashtâr B.
    Commented Sep 29, 2016 at 21:42
  • \$\begingroup\$ Welcome to PPCG Meta. Please search for questions that may already have your answer using the search box on the top-right of almost every page, or through the list that appears after you type the title of the question and click outside of that text box. For ease, you may prepend or append is:question or views:0 along with the search terms to only search for questions. If a similar question has been closed ([closed], [on hold] or [duplicate] marking), your question may also be closed as a dupe or because of the close reason of the other question. \$\endgroup\$
    – Erik the Outgolfer
    Commented Sep 30, 2016 at 11:51

0

Reset to default

Browse other questions tagged .