I noticed that Piet is not mentioned in the How to count bytes FAQ. How should we determine the length of a piet program?
\$\begingroup\$
\$\endgroup\$
0
Add a comment
|
3 Answers
\$\begingroup\$
\$\endgroup\$
Here's an encoding for Piet programs
I've published an encoding (with a translator program) that represents a Piet program as a series of ASCII characters. It encodes each codel as one character, and therefore:
We can now count Piet programs by codels
There are 20 different colors of codels, so each color can be encoded in five bits. I've used the sixth bit of each character as a flag to indicate end-of-line, meaning that the size of the image doesn't need to be encoded separately. So any Piet program with N codels can be encoded as an N-byte text file. Since we count code by the number of bytes in the file, this means Piet can officially be counted by codels.
... Although some programs can be encoded in fewer bytes
Since end-of-line is specified for each line separately, it is possible to have uneven lines. The translator right-pads shorter lines to the length of the longest line using black codels. Therefore, black codels at the ends of lines can be omitted in the encoding. For example, this program has 18 codels, and it can be ASCII-encoded in 18 bytes:
lldd @lldddTllddtF
However, since the two black codels are at the end of a line, they can also be omitted, resulting in a 16-byte ASCII version:
lldDlldddTllddtF
It is up to the golfer whether they want to take advantage of this feature. It's always possible to score your program in codels, since there is always an ASCII representation with the claimed bytecount. If you want to take advantage of the black codel omission, I would suggest reporting both the number of codels and the number of bytes (and perhaps linking to the encoding as well).
\$\begingroup\$
\$\endgroup\$
2
Number of codels in the image
All codels in the image will be counted. This includes codels that are never visited, and black and white codels.
-
\$\begingroup\$ Devil's advocate: Hexagony requires its programs to be certain lengths and automatically pads anything that's too short with nops, and we generally don't consider those as part of the program when determining length. Codels that are never visited and only present to ensure that the image is rectangular seem analogous, the only difference being that in Hexagony the interpreter will automatically pad the code whereas in Piet the programmer is required to do it herself. \$\endgroup\$ Commented Feb 19, 2017 at 21:59
-
1\$\begingroup\$ @JackBrounstein I had suggesting counting all "functional" codels, but it was very quickly shot down and has been deleted. I think the real way to solve this problem is to make a Piet interpreter for golfing with this functionality, a golf-friendly image format with one byte per codel (or less than one byte per codel), a more golf-friendly way to terminate programs, etc. \$\endgroup\$ Commented Feb 21, 2017 at 15:25
\$\begingroup\$
\$\endgroup\$
12
Number of bytes in the image file
We should stop making up new scoring schemes for programming languages, which only serves to make things more difficult. Code golf contests are scored in bytes, so that's what matters. Everything else is artifical and prone to not take all details into account.
For example, scoring Piet submissions just by the number of codels doesn't take the shape into account; it considers 4x1, 2x2, and 1x4 images with the same codels the same program, which obviously isn't true.
-
4\$\begingroup\$ I worry that this will cause people to do things outside of just programming to reduce the filesize. Choosing a smaller codel size is fine, but changing image formats to reduce the size does not seem to be in the spirit of code golf (in my opinion). This also begs the question of what image formats are valid, or what even is an image? Can I create my own image format just for code golf? \$\endgroup\$ Commented Dec 20, 2016 at 20:19
-
6\$\begingroup\$ If there's a Piet interpreter that understands your image format, sure. It just has to predate the challenge. \$\endgroup\$– Dennis ModCommented Dec 20, 2016 at 20:23
-
5\$\begingroup\$ @MikeBufardeci I'm not entirely sure that "changing image formats to reduce the size does not seem to be in the spirit of code golf". If you're golfing in a programming language whose sources are image based, it makes sense to try to compress the input image. If you prefer only having to worry about codels, there is nothing stopping people from inventing a Piet dialect that reads ASCII input, with text characters in place of colours. (At that point it'll be obvious, that you at least need to count something to define the exact shape of the rectangle.) \$\endgroup\$– Martin Ender ModCommented Dec 20, 2016 at 21:50
-
5\$\begingroup\$ @MartinEnder I just think that code golf should score you based on the code you're writing and not other things, like your ability to define a new image format. Clearly I am the only person who feels this way. \$\endgroup\$ Commented Dec 21, 2016 at 14:33
-
7\$\begingroup\$ @MikeBufardeci Golfing in "regular" languages isn't that different. Using a different character encoding or a laxer compiler can have a tremendous impact on the score. \$\endgroup\$– Dennis ModCommented Dec 21, 2016 at 14:36
-
\$\begingroup\$ Fair enough. I guess I will stick to golfing languages then. shrug \$\endgroup\$ Commented Dec 21, 2016 at 15:09
-
6\$\begingroup\$ I think this is a really bad idea. I'm sure it's hard enough to write code in this language normally, and forcing people to consider how well it's going to be compressed would make it a lot less fun (which IS the entire point of code golf, really). Also, your example of 4x1 and 2x2 images being considered the same also applies to normal text-based code, especially for 2D languages like befunge. \$\endgroup\$– 12Me21Commented Oct 11, 2017 at 23:38
-
\$\begingroup\$ @12Me21 Also, your example of 4x1 and 2x2 images being considered the same also applies to normal text-based code, especially for 2D languages like befunge. That's not true. The positions of the newlines (which contribute to the byte count) determine the layout of the code. \$\endgroup\$– Dennis ModCommented Oct 11, 2017 at 23:43
-
1\$\begingroup\$ Perhaps
Area + Height - 1would be a better scoring system then. Piet programs could be treated as if they were written as lines of text separated by line break characters (like befunge), and could even be easily converted to and from this format. \$\endgroup\$– 12Me21Commented Oct 12, 2017 at 0:05 -
1\$\begingroup\$ @12Me21 Sure, that would work. But do we really need to count all the "linebreaks" in rectangular program if one would suffice to determine the shape? Or do we not require the program to be rectangular? Sure, it's possible to (more or less arbitrarily) pick a scoring method that works for a given language. We can either do that for every single language in existence, or simply count the bytes of actual files we use. \$\endgroup\$– Dennis ModCommented Oct 12, 2017 at 0:15
-
1\$\begingroup\$ I think it's worth the trouble. How many times would this need to be done? Is it really acceptable to have to worry about code compressability? Imagine if you needed to to this for other languages, such as writing
x=x|1instead ofx|=1because it compresses better. It might be fun to do for a specific challenge that requires it, but having to think about this every time would just be an unnecessary complexity for the programmer. I understand why you'd want to measure the size of the actual program file, but at least compression should not be allowed. \$\endgroup\$– 12Me21Commented Oct 12, 2017 at 0:28 -
4\$\begingroup\$ This was a disheartening answer to find. It basically kills Piet as a golfing language, or at least moves the golfing aspect to fiddling with an image encoder instead of actually clever coding, or some monstrous hybrid thereof. It might actually actively work against golfing as the activity of the programmer, since very large values can just be stored as big blobs, being confident that the PNG (or whathaveyou) encoder will compress it well anyway. \$\endgroup\$ Commented Nov 15, 2019 at 5:16