Generic C / Python Polyglot

2017-11-04, post № 184

C, programming, Python, #recreational

A polyglot — coming from the Greek words πολύς (many) and γλώττα (tongue) — is a piece of source code which can run in multiple languages, often performing language-dependent tasks.
Even though such a source code’s feature may not seem particularily useful or possible with certain language combinations, trying to bend not one but multiple language’s syntactic rules and overall behavior is still interesting.

An example of a rather simple polyglot would be a Python 2 / Python 3 polyglot — if one counts those as two separate languages. Because of their enormous similarities, one can pick out differences and use those to determine which language runs the source code.

if 1/2>0:print("Python 3")
else:print("Python 2")

Utilizing Python’s version difference regarding integer division and real division is one of the most common ways to tell them apart, as it can also be used to only control a specific part of a program instead of having to write two nearly identical programs (increases the program’s style and cuts on bytes — an important consideration if one golfs a polyglot).

However, polyglots combining languages that are not as similar as Python 2 and Python 3 require more effort. The following is a general Python 2 / C polyglot, meaning that nearly all C and Python 2 programs can be mixed using this template (there are a few rules both languages need to abide which will come apparent later).

#define _\
#define _"""
print"Python 2"

In the above code, main(){printf("C");} can be nearly any C code and print"Python 2" can be nearly any Python 2 code.
Language determination is exclusively done via syntax. A C compiler [1] sees a #define statement and a line continuation \, another two #define statements with a block comment in between and actual compilable C source code (view first emphasis).Python, on the other hand, treats all octothorps, #, as comments, ignoring the line continuation, and triple-quoted strings, """...""", as strings rather than statements and thus only sees the Python code (view second emphasis).

My first ever polyglot used this exact syntactical language differentiation and solved a task titled Life and Death of Trees (link to my answer).

Halloween MMXVII

2017-10-31, post № 183

art, poetry, #dark, #iambic pentameter, #poem, #Shakespearean sonnet, #sonnet

Gentle whispers wake my worldly being,
for long have I been laying here asleep.
My eye I open, though without seeing;
a world possessed by darkness — far and deep.
I want to try and move but must I not.
An every thought consumed by this abyss.
I try unraveling this psychic knot,
though does this fight seem to be meaningless.
Alas, before my mind is swallowed whole,
a square of light appears in front of me.
A cat inside the light; it wants my soul,
strips me of my heart so I will not be.
Without its core, my outer shell lies here,
the inner power used to fuel all fear.

— Jonathan Frech, 30th of October 2017

BMP Implementation in C

2017-10-21, post № 182

C, programming, #bitmap, #file, #file format

C is one cool and important language. CPython and Unix are based on it, the Mars Curiosity rover is run by it and even the GCC C compiler itself is written in C. However, as C is some years old by now, it lacks a lot of higher-level features most modern languages possess, being more down to the silicon, as the cool kids say. Concepts like pointer manipulation, bit fiddling and its string implementation — just to name a few — are at times cumbersome, insecure and error-prone; nevertheless is there a certain appeal to writing in C.

Being only one abstraction level away from Assembly — which itself is only one abstraction level above raw byte code — and having access to file manipulation down to the individual bit, I set out to write a Microsoft Bitmap (.bmp) implementation in pure C. As Microsoft’s standard for this image file format is quite feature-rich, I decided to focus on the bare minimum — a bitmap with 𝟤𝟦-bit color depth (three colors, one byte per), one color plane, no compression, no palette and 𝟥𝟢𝟢 DPI.
My Bitmap implementation supports both reading and writing .bmp files, as well as generating some test images — including a Mandelbrot set fractal renderer, of course. Implementation source code can be downloaded (bmp.c) or seen below.

A Mandelbrot set fractal rendering.

Implementing a file format requires knowing its specification. Although it is not the best article I have ever seen, this Wikipedia article gave me some insights. The missing pieces were reverse engineered using Adobe Photoshop CC and the HxD hex editor.
The following is a snippet of the implementation’s savebmp function (full source code listed below). It illustrates the Bitmap file’s byte layout only showing the file header, omitting a lengthy data part concatenated to the header. S, K, W, H and B are all byte arrays of length four (little-endian format) which contain the file’s total size, the bitmap data offset (which is constant, since the header is always exactly 𝟧𝟦 bytes large), the image’s dimensions (horizontal and vertical) and the bitmap data’s section’s size, respectively.

/*  bitmap file header  */
0x42, 0x4D,             // BM
S[0], S[1], S[2], S[3], // file size
0x00, 0x00, 0x00, 0x00, // unused
K[0], K[1], K[2], K[3], // bitmap data offset
/*      DIB header      */
0x28, 0x00, 0x00, 0x00, // DIB size
W[0], W[1], W[2], W[3], // pixel width
H[0], H[1], H[2], H[3], // pixel height
0x01, 0x00,             // one color plane
0x18, 0x00,             // 24 bit color depth
0x00, 0x00, 0x00, 0x00, // no compression
B[0], B[1], B[2], B[3], // bitmap data size
0x23, 0x2E, 0x00, 0x00, // 300 DPI (horizontal)
0x23, 0x2E, 0x00, 0x00, // 300 DPI (vertical)
0x00, 0x00, 0x00, 0x00, // no palette
0x00, 0x00, 0x00, 0x00  // color importance
/*  data bytes follow   */

Key bytes to note are the first two identifying the file type (the ASCII-encoded letters BM) and the DPI bytes, 0x23, 0x2E, which indicate 0x00002E23 = 11811 pixels per meter in both the horizontal and vertical direction. Converting from pixels per meter to dots per inch results in 11811 / (1 meter / 1 inch) = 11811 * 127 / 5000 = 300 DPI (roughly).
Most values are represented using four bytes in little-endian format. Translating an 𝟥𝟤-bit integer into four little-endian formatted bytes can be achieved as follows.

/* unsigned 32-bit integer */
unsigned int n = 0b10100100010000100000100000010000;
/*                 < m sig><sm sig><sl sig>< l sig> */

/* byte (unsigned char) array of size four */
unsigned char N[4] = {
    (n & 0xff000000) >>  0, // most significant byte
    (n & 0x00ff0000) >>  8, // second most significant byte
    (n & 0x0000ff00) >> 16, // second least significant byte
    (n & 0x000000ff) >> 24  // least significant byte

Other than rendering a fractal, I also implemented three nested loops which output an image containing every possible color exactly once ((2**8)**3 = 16777216 pixels in total).

All sixteen million colors in one image.

An image’s data type is implemented as a struct image which contains three variables — width and height, two integers specifying the image’s dimensions, and *px, a pointer to an one-dimensional integer array of size width*height which holds the entire image data.
Defined functions are listed ahead.

Images shown in this post were converted to .png files as WordPress does not allow .bmp file uploads; the raw pixel data should, however, be identical. [1]

Source code: bmp-implementation-in-c_bmp.c


2017-10-07, post № 181

BASIC, PIL, programming, Python, TI-84 Plus, #bitmap, #image, #TI, #TI-BASIC

Texas Instrument’s TI-84 Plus is a graphing calculator with a variety of features. It has built-in support for both fractions and complex numbers, can differentiate and integrate given functions and supports programming capabilities. The latter allows to directly manipulate the calculator’s monochrome display’s 𝟧𝟫𝟪𝟧 pixels (the screen has dimensions 𝟫𝟧 ⨉ 𝟨𝟥). TImg is a Python program (source code is listed below and can also be downloaded) which takes in an image and outputs TI-BASIC source code which, when run on the graphing calculator, will produce the given image — in potentially lower quality.

TI-84 Plus’ screen dimensions (bitmap).

PIL — the Python Imaging Library — is used to read in the image and further for processing. The supplied image may be rotated and resized to better fit the TI-84’s screen and any color or even grayscale information is reduced to an actual bitmap — every pixel only has two distinct values.
Direct pixel manipulation on the TI-84 is done via the Graph screen. To get remove any pixels the system draws on its own, the first three commands are ClrDraw, GridOff and AxesOff which should result in a completely blank screen — assuming that no functions are currently being drawn. All subsequent commands are in charge of drawing the previously computed bitmap. To turn certain pixels on, Pxl-On(Y,X is used where 𝑌 and 𝑋 are the pixel’s coordinates.

A fractal (bitmap).

Since the TI-84 Plus only has 𝟤𝟦 kilobytes of available RAM, the source code for a program which would turn on every single pixel individually does not fit. Luckily, though, a program which only individually turns on half of the screen’s pixels fits. To ensure that TImg’s output fits on the hardware it is designed to be used with, an image’s bitmap is inverted when the required code would otherwise exceed 𝟥𝟧𝟢𝟢 lines — a value slightly above the required code to draw half of the pixels.

A J-Blog screenshot (input image).
Source code: timg.py


2017-09-23, post № 180

PIL, programming, Python, #color model, #hsl, #hsv, #image filter, #images, #nature, #photography, #rainbow

To digitally represent colors, one most often uses the RGB color system. By combining three fundamental light colors in certain ways, one can define a variety of different wavelengths of light. The human eye has three distinct photoreceptors for the aforementioned three colors, nearly all screens use pixels consisting of three parts in those colors and most image formats store the image data in the RGB color system.

Honey bee (original)

However, there are other color systems than RGB with other strengths. Cycling through the colors of the rainbow, for example, is a lot easier using the HSL (or HSV) color model, as it is simply controlled by the hue.

Fruit (original)

Rainbowify uses the HSL color model to rainbowify a given image. To do so, the image is first converted into a grayscale image (averaging all three color channels). A pixel’s brightness is then interpreted as its hue with its saturation and lightness set to the maximum. As a final touch, the hue gets offset by a pixel-position dependent amount to create the overall appearance of a rainbow.
Source code is listed below and can also be downloaded.

Sunflower (original)
Thistle (original)
Source code: rainbowify.py
Extra assets: rainbowify-120.jpg, rainbowify-120_rainbowified.jpg, rainbowify-121.jpg, rainbowify-121_rainbowified.jpg, rainbowify-122.jpg, rainbowify-122_rainbowified.jpg, rainbowify-125.jpg, rainbowify-125_rainbowified.jpg, rainbowify-126.jpg, rainbowify-126_rainbowified.jpg, rainbowify-127.jpg, rainbowify-127_rainbowified.jpg, rainbowify-128.jpg, rainbowify-128_rainbowified.jpg, rainbowify-129.jpg, rainbowify-129_rainbowified.jpg, rainbowify-130.jpg, rainbowify-130_rainbowified.jpg, rainbowify-131.jpg, rainbowify-131_rainbowified.jpg, rainbowify-132.jpg, rainbowify-132_rainbowified.jpg, rainbowify-133.jpg, rainbowify-133_rainbowified.jpg, rainbowify-134.jpg, rainbowify-134_rainbowified.jpg, rainbowify-135.jpg, rainbowify-135_rainbowified.jpg, rainbowify-136.jpg, rainbowify-136_rainbowified.jpg, rainbowify-138.jpg, rainbowify-138_rainbowified.jpg, rainbowify-139.jpg, rainbowify-139_rainbowified.jpg, rainbowify-140.jpg, rainbowify-140_rainbowified.jpg, rainbowify-141.jpg, rainbowify-141_rainbowified.jpg, rainbowify-142.jpg, rainbowify-142_rainbowified.jpg, rainbowify-143.jpg, rainbowify-143_rainbowified.jpg, rainbowify-144.jpg, rainbowify-144_rainbowified.jpg, rainbowify-145.jpg, rainbowify-145_rainbowified.jpg, rainbowify-146.jpg, rainbowify-146_rainbowified.jpg, rainbowify-147.jpg, rainbowify-147_rainbowified.jpg, rainbowify-148.jpg, rainbowify-148_rainbowified.jpg, rainbowify-149.jpg, rainbowify-149_rainbowified.jpg, rainbowify-150.jpg, rainbowify-150_rainbowified.jpg, rainbowify-151.jpg, rainbowify-151_rainbowified.jpg, rainbowify-152.jpg, rainbowify-152_rainbowified.jpg, rainbowify-153.jpg, rainbowify-153_rainbowified.jpg, rainbowify-155.jpg, rainbowify-155_rainbowified.jpg, rainbowify-156.jpg, rainbowify-156_rainbowified.jpg, rainbowify-157.jpg, rainbowify-157_rainbowified.jpg, rainbowify-158.jpg, rainbowify-158_rainbowified.jpg, rainbowify-159.jpg, rainbowify-159_rainbowified.jpg

Arithmetic Golfing

2017-09-09, post № 179

code golf, mathematics, programming, Python, #byte count, #code golfing, #golfing, #short code

A recent PCG golfing question When do I get my sandwich? asked to find a mapping between seven input strings (sandwich names) and the seven days of the week (indexed by number).

The first answer was made by a user named i cri everytim and utilized a string of characters which uniquely appear at the same position in all seven input strings, enklact, to perform the mapping in Python 2 requiring 𝟤𝟫 bytes. After their answer, a lot of answers appeared using the same magic string in different languages to reduce the number of bytes needed. Yet nobody reduced the byte count in Python.

Trying to solve the problem on my own, my first attempt was using only the input strings’ last decimal digit to perform the mapping, though this approach did not save on bytes (read my PCG answer for more on this 𝟥𝟢 byte solution).

After a few more hours of working on this problem, however, I achieved to bring down the byte count by one entire byte.

I did so by using a simple brute-force algorithm to check for Python expressions which can be used to perform the sought after mapping. To do so, I use Python’s apostrophes (`...`) to turn the found expression into a string — str(...) is three whole bytes longer — and index that string with the input strings’ lengths. It sure is not very readable, but only takes 𝟤𝟪 bytes — and that is all that matters.

lambda S:`6793**164`[len(S)]

After finding the 𝟤𝟪 byte function which uses a 𝟫 byte expression (6793**164), I attempted to find an even shorter expression. And even though I did not yet find one, I did write a more general brute-force Python program (source code shown below; can also be downloaded) than the one I linked to in my PCG answer.

Brute-forcing takes exponentially more time the more digits you have to check, so my brute-forcer still requires the user to decide for themselves which expressions should be tried.
There are three parameters that define the search; a regex pattern that should be contained in the expression’s string, an offset that pattern should ideally have and a target length. If an expression is found that takes as many bytes as or less bytes than the target length, an exclamation point is printed
Though this program did not prove useful in this case, there may come another challenge where an arithmetic expression golfer could come in handy.

My program may not have found shorter expressions, but definitely some impressive ones (the +... at the end refers to an additional offset from the string index which — unsurprisingly — take additional bytes):

I also considered using division to generate long strings of digits which may match; the only problem is that Python floating-point numbers only have a certain precision which does not produce long enough strings. Again, using exponentiation (**) and bitshifting (<<) I could not come up with a working expression that takes less bytes.

Source code: arithmetic-golfing_brute.py

brainfuck X

2017-08-26, post № 178

brainfuck, programming, Python, #ANSI, #argparse, #braindraw, #color, #esoteric, #interpreter, #PPM, #tape, #Turing machine

While browsing StackExchange PCG [1] questions and answers, I came across a challenge regarding drawing the swiss flag. In particular, I was interested in benzene’s answer, in which they showcased a brainfuck dialect capable of creating two-dimensional 𝟤𝟦-bit color images. In this post I present this dialect with slight changes of my own, as well as an interpreter I wrote in Python 2.7 (source code is listed below and can also be downloaded).


Urban Müller’s original brainfuck (my vanilla brainfuck post can be found here) works similar to a Turing machine, in that the memory consists of a theoretically infinitely large tape with individual cells which can be modified. What allows brainfuck X (or braindraw, as benzene called their dialect) to create color images is, that instead of a one-dimensional tape, a three-dimensional tape is used. This tape extends infinitely in two spacial dimensions and has three color planes. Each cell’s value is limited to a byte (an integer value from 𝟢 to 𝟤𝟧𝟧) which results in a 𝟤𝟦-bit color depth.

Adding to brainfuck’s eight commands (+-<>[].,), there are two characters to move up and down the tape (^v) and one character to move forwards in the color dimension (*). Starting on the red color plane, continuing with the green and ending in the blue. After the blue color plane, the color planes cycle and the red color plane is selected. benzene’s original language design which I altered slightly had three characters (rgb) to directly select a color plane. Whilst this version is supported by my interpreter )the flag --colorletters is necessary for that functionality(, I find my color star more brainfucky — directly calling color planes by their name seems nearly readable.
brainfuck’s vanilla eight characters still work in the same way, brainfuck X can thereby execute any vanilla brainfuck program [2]. Also, there still is a plaintext output — the tape’s image is a program’s secondary output.

Having executed the final brainfuck instruction, the interpreter prints out the tape to the terminal — using ANSI escape codes. Because of this, the color depth is truncated in the terminal view, as there are only 𝟤𝟣𝟨 colors supported. [3]
For the full 𝟤𝟦-bit color depth output, I use the highly inefficient Portable Pixmap Format (.ppm) as an output image file format. To open .ppm files, I recommend using the GNU Image Manipulation Program; specifying the output file name is done via the --output flag.

The Swiss flag image above was generated by benzene’s braindraw code (see their StackExchange answer linked to above); the resulting .ppm file was then scaled and converted using GIMP.
Interpreter command: python brainfuckx.py swiss.bfx -l -o swiss.ppm


  • Being written in pure Python, the interpreter is completely controlled via the command line. The basic usage is python brainfuck-x.py <source code file>; by using certain flags the functionality can be altered.
  • --input <input string>, -i <input string> specifies brainfuck’s input and is given as a byte stream (string).
  • --simplify, -s outputs the source code’s simplified version; the source code with all unnecessary characters removed.
  • --colorstar selects the color star color plane change model which is the default.
  • --colorletters, -l selects the color letter color plane change model.
  • --silent stops the interpreter from outputting warnings, infos and the final tape.
  • --maxcycles <cycles>, -m <cycles> defines the maximum number of cycles the brainfuck program can run; the default is one million.
  • --watch, -w allows the user to watch the program’s execution.
  • --watchdelay <delay> defines the time in seconds the interpreter sleeps between each watch frame.
  • --watchskip <N> tells the interpreter to only show every 𝑁th cycle of the execution.
  • --output <output file name>, -o <output file name> saves the final tape as a .ppm image file.
Source code: brainfuck-x.py

Cyclic Quine

2017-08-12, post № 177

Programming, Python, Quine, #self-referential

A classic quine is a program which outputs its own source code.
At first, such a program’s existence seems weird if not impossible, as it has to be so self-referential that it knows about itself everything, including how to know about itself. However, writing quines is possible, if not [1] trivial.

A cyclic quine therefore is a program which outputs source code which differs from its own source code, yet outputs the original source code when run (the cycle length could be greater than one). So when running source codes 𝛹 and 𝛷, they output source codes 𝛷 and 𝛹.

Therefore, when one saves the first program as q0.py and the second as q1.py, one can create both source codes from one another (the following bash commands [2] will not change the files’ contents).

$ python q0.py > q1.py
$ python q1.py > q0.py
$ python q0.py | python > q0.py
$ python q0.py | python | python | python | python > q1.py
Source code: cyclic-quine_q0.py
Source code: cyclic-quine_q1.py
Jonathan Frech's blog; built 2024/07/06 12:42:51 CEST