## Cyclic Quine

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 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 $\Psi$ and $\Phi$, they output source codes $\Phi$ and $\Psi$.

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 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

j=0;Q,q="j=1;Q,q={}{}{}.replace(str(j),str(int(not(int(j)))),1),chr(34);print Q.format(q,Q,q)".replace(str(j),str(int(not(int(j)))),1),chr(34);print Q.format(q,Q,q)
j=1;Q,q="j=1;Q,q={}{}{}.replace(str(j),str(int(not(int(j)))),1),chr(34);print Q.format(q,Q,q)".replace(str(j),str(int(not(int(j)))),1),chr(34);print Q.format(q,Q,q)

## Mandelbrot Set III

I wrote my first ever Mandelbrot Set renderer back in 2015 and used Python to slowly create fractal images. Over a year later, I revisited the project with a Java version which — due to its code being actually compiled — ran much faster, yet had the same clunky interface; a rectangle the user had to draw and a key they had to press to the view change to the selected region.
In this post, over half a year later, I present my newest Mandelbrot Set fractal renderer (download the .jar), written in Java, which both runs fast and allows a much more intuitive and immersive walk through the complex plane by utilizing mouse dragging and scrolling.
The still time demanding task of rendering fractals — even in compiled languages — is split up into a low quality preview rendering, a normal quality display rendering and a high quality 4K (UHD-1 at 3840×2160 pixels to keep a 16:9 image ratio) rendering, all running in seperate threads.

The color schemes where also updated, apart from the usual black-and-white look there are multiple rainbow color schemes which rely on the HSB color space, zebra color schemes which use the iterations taken modulo some constant to define the color and a prime color scheme which tests if the number of iterations taken is prime.

Apart from the mouse and keyboard control, there is also a menu bar (implemented using Java’s JMenuBar) which allows for more conventional user input through a proper GUI.

#### Controls

• Left mouse dragging: pan view
• Left mouse double click: set cursor’s complex number to image center
• Mouse scrolling: zoom view
• Mouse scrolling +CTLR: pan view
• ‘p’: render high definition fractal
• ‘r’: reset view to default
• ‘w’, ‘s’: zoom frame
• Arrow keys: pan view
• Arrow keys +CTRL: zoom view
• Fractal: extra info about current fractal rendering
• Color Scheme: change color scheme and maximum iteration depth
• HD: controls for high definition rendering

A bit more on how the three threads are implemented.
Whenever the user changes the current view, the main program thread renders a low quality preview and immediately draws it to the screen. In the background, the normal quality thread (its pixel dimensions match the frame’s pixel dimensions) is told to start working. Once this medium quality rendering is finished, it is preferred to the low quality rendering and gets drawn on the screen.
If the user likes a particular frame, they can initiate a high quality rendering (4K UHD-1, 3840×2160 pixels) either by pressing ‘q’ or selecting HD->Render current frame. This high quality rendering obviously takes some time and a lot of processing power, so this thread is throttled by default to allow the user to further explore the fractal. Throttling can be disabled through the menu option HD->Fast rendering. There is also the option to tell the program to exit upon having finished the last queued high definition rendering (HD->Quit when done).
The high definition renderings are saved as .png files and named with their four defining constants. Zim and Zre define the image’s complex center, Zom defines the complex length above the image’s center. Clr defines the number of maximum iterations.

Just to illustrate how resource intensive fractal rendering really is.
A 4K fractal at 3840×2160 pixels with a iteration depth of 256 would in the worst case scenario (no complex numbers actually escape) require $3840 \cdot 2160 \cdot 256 \cdot 4 = 8493465600$ double multiplications. If you had a super-optimized CPU which could do one double multiplication a clock tick (which current CPUs definitely cannot) and ran at 4.00 GHz, it would still take that massively overpowered machine $\frac{8493465600}{4 \cdot 10^9} = 2.123$ seconds. Larger images and higher maximum iterations would only increase the generated overhead.

Unrelated to algorithmically generating fractal renderings, I recently found a weed which seemed to be related to the Mandelbrot Set and makes nature’s intertwined relationship with fractals blatently obvious. I call it the Mandel Weed.

// Java Code; Jonathan Frech; 22nd, 23rd, 24th, 25th, 26th, 27th of July 2017

## Asciify

Most images nowadays are represented using pixels. They are square, often relatively small and numerous, come in $(2^8)^3$ different colors and thereby do a good job being the fundamental building block of images. But one can imagine more coarse-grained and differently shaped pixels.
An interesting fact is, that in most monotype fonts two characters placed right next to each other (for example ‘’) occupy roughly a square area. So simple ASCII characters can indeed be used to approximately describe any ordinary image.
Asciify does exactly this; it takes in an image and some optional parameters and maps the pixels’ intensity onto a character set. Both the large and small default character sets are taken from a post by Paul Bourke.

In conjunction with asciify.py, I wrote index.py, which asciifies a bunch of images and results in their html form; it also creates an index. All images asciified for this post can be viewed through this index.

Converting an image to its asciified form works best when there is a lot of contrast in the image. Because of this, some pre-processing of the image may be required for best results (all images shown where only cropped or rotated). The built-in color functionality also only knows of $8$ colors, so bright and different colors look the best, as they interestingly differentiate from one another. The asciified image’s size also plays a role, the larger it is, the better the characters blend into one and appear to be one image.

Asciify is operated on a command prompt; python asciify.py img.png. To parse arguments, the built-in python module argparse is used. The images are opened and read using the Python Imaging Library module PIL, which needs to be installed for this program to work.
Optional arguments include --size N, where the maximum size can be specified, --invert and --smallcharset, which can sometimes increase the asciified image’s visual appeal and --html, which will output an html file to be viewed in a browser. To see the program’s full potential, simply run python asciify.py --help.
Source code for both asciify.py and index.py can be downloaded, the first is also listed below.

The two examples above use the color mode, though certain images also work in default black and white mode, such as this spider I photographed.

Then again, the colored text also has its charm, especially when the source image has bright colors and a lot of contrast.

# Python 2.7 Code
# Jonathan Frech 3rd, 4th of March 2017
#      rewritten 12th of April 2017
#         edited 13th of April, 13th, 14th, 15th of July 2017