## Lyapunov Fractal

Lyapunov fractals are mathematical objects living in the plane, graphing regions of stability or chaos regarding a certain logistical map following an ever-changing population growth, alternating between two values.
I implemented a Lyapunov fractal viewer in Java 1.8 which lets you freely move around the plane, set sequences and iteration depths to explore the fractal. Source code can be seen below or downloaded, as can the Java executable (Lyapunov.java, Lyapunov.jar).

Articles on the topic of Lyapunov fractals are a post by Earl Glynn from the year 2000 in which they talk about their Lyapunov fractal generator written in Pascal — a rewrite of a software written in 1992. Also worth reading is A. Dewdney’s article about Mario Markus’ work (Scientific American, September 1991).

My first encounter with this fractal was whilst browsing Wikipedia and stumbling across its Wikipedia entry. Since it was a fractal and looked fairly intricate and thus explorable, I set out to write my own renderer — I chose to implement it in Java, as it is a compiled language with a nice set of GUI libraries. Since Wikipedia listed an algorithm for generating Lyapunov fractal images, I thought an implementation would be fairly straight-forward. However, als always, the devil is in the detail and I quickly noticed that while the short Wikipedia entry looks convincing and well-written at first glance, lacks to answer deeper questions regarding the very topic it is about.

The following is a description of the fractal generation algorithm. It is a modified version of the algorithm detailed by Wikipedia which addresses certain ambiguities the original had (more on those later).

• Take as input a complex point $(a,b) \in \mathbb{R}^2$ and a sequence $S^*$ consisting of the letters $\text{A}$ and $\text{B}$; for example $S^* = \text{AAAAAABBBBBB}$.
• Construct a function $S \colon \mathbb{N}_0 \to \{\text{A},\text{B}\}, n \mapsto S^*_{(n \mod |S^*|)}$ which returns the zero indexed $n$-th sequence entry and wraps around to the sequence’s start once the sequence’s end is hit.
• Construct a function $r \colon \mathbb{N}_0 \to \{a,b\}, n \mapsto \begin{cases}a&\text{if } S(n) = \text{A}\\b&\text{if } S(n) = \text{B}\end{cases}$ which selects either $a$ or $b$.
• Let $x_0=0.5$ and define $x_n=r(n-1)\cdot x_{n-1}\cdot (1-x_{n-1})$.
• Calculate the Lyapunov exponent $\lambda$ as follows.
$\lambda = \lim\limits_{N \to \infty} \frac{1}{N} \cdot \sum\limits_{n=1}^{N} \log_2{|r(n)\cdot(1-2\cdot x_n)|}$
Since calculating the limit as $N$ goes to infinity is rather difficult in practice, one can simply use a sufficiently large $N$ and pretend to have reached infinity.
• Output a color value according to $\lambda$. I chose green for $\lambda < 0$ and blue for $\lambda \geq 0$, using arbitrarily defined value ranges to map $\lambda$ to an actual color.

The following is a Java snippet which implements the algorithm described above.

// choose a or b according to Seq and n
static double r(String Seq, int n, double a, double b) {
if (Seq.charAt(n%Seq.length()) == 'A') return a; else return b;
}

// calculate a pixel color (0x00rrggbb) for given parameters
static int LyapunovPixel(double a, double b, String Seq, int N) {
// array of all x_n; x_0, the starting value, initialize all x_n values
double[] X = new double[N+1]; X[0] = .5;
for (int n = 1; n <= N; n++) X[n] = r(Seq,n-1,a,b)*X[n-1]*(1-X[n-1]);

// calculate the Lyapunov exponent (to a certain precision dictated by N)
double lmb = 0;
for (int n = 1; n <= N; n++)
lmb += Math.log(Math.abs(r(Seq,n,a,b)*(1-2*X[n])))/Math.log(2);
lmb /= N;

// infinity was hit, use a black pixel
if (Double.isInfinite(lmb)) return 0x000000;

// color pixel according to Lyapunov exponent
double MIN = -1, MAX = 2;
if (lmb < 0) return ((int)(lmb/MIN*255))<<8;
else         return ((int)(lmb/MAX*255))<<0;
}

Coming back to Wikipedia’s algorithm, there were a few things I found irritating at best when attempting my implementation and thus addressed in the algorithm description seen above. A closer look at potentially misleading or ambiguos statements follows, together with my reasoning to resolve them.

It is not clear whether the sequence is zero or one indexed, though it has to be zero indexed as $x_0=0.5, x_{n+1}=r_n\cdot\dots$ evaluates to $x_1=r_0\cdot\dots$, implying the definition of $r_0$ and thus $S_0$.

It is not clear which logarithm is meant; the natural logarithm, a generic $\log_b$ or the dyadic logarithm — the latter is actually used. To find the actual logarithm base, I dug deeper and used Wikipedia’s external links to find a post by Earl Glynn, answering this question.

It is not clear what is meant by the second half of the sentence beneath the Lyapunov exponent. It reads “… dropping the first summand as $r_0(1-2x_0) = r_n\cdot 0 = 0$ for $x_0 = 0.5$.” As the sum starts with $n=1$ and one would not dare to calculate $\log_2{|r(0)\cdot(1-2\cdot x_0)|} = \log_2{0}$ for $x_0 = 0.5$, this sentence’s existence bewilders me.

It is not clear how exactly the colors are derived, only that they have something to do with the Lyapunov exponent. I simply chose arbitrary values that looked convincing for mapping $\lambda$ to a pixel color.

One of the most frustrating bugs I came across was an unexplainable axis flip. My code generated the fractal just fine except for the fact that every image was flipped along the diagonal crossing the origin with a $45^\circ$ angle to the horizontal. It was as though the coordinates $(a,b)$ were swapped somewhere in my code and I simply could not figure out where.

Finally, after hours of looking at the same code over and over again, a closer look at Earl Glynn’s post brought an end to my misery. Just below the three welcoming fractal renderings, a screenshot of their software is shown — complete with a blue and red line indicating the coordinate system’s orientation. $a$ and $b$ are — contrary to all coordinate systems involving parameters named after the first two letters in the latin alphabet — indeed flipped. Wikipedia’s images must have simply ran with this decision, without noting it.
Because of this flip, when one wants to render images specified in the reversed sequence format, they simply have to swap all letters (for example $\text{BBBABA}$ becomes $\text{AAABAB}$).

As Glynn themself says, “I would have reversed the ‘a’ and ‘b’ labels to be consistent with normal ‘x’ and ‘y’ axes conventions, but conform here with the same convention as used by Markus.” (Referring to Mario Markus, co-author of Lyapunov Exponents of the Logistic Map with Periodic Forcing.)

After having eliminated all vagueness regarding the fractal generation, writing the outer Java viewer hull was a fairly easy task. As a template I took my Mandelbrot Set III viewer (the reason why most variable names reference complex numbers) complete with multithreading, allowing a pixely fractal exploration until one stops their exploration, letting the thread catch up and display a higher resolution image. The same is done for rendering 4K images and saving them to files in the background — 4K renderings are saved as .png files and named according to their parameters. A list of program controls follows.

• Mouse dragging lets one pan the complex plane.
• Mouse scrolling lets one zoom the complex plane.
• Pressing N evokes a dialogue box where one can specify an iteration depth $N$.
• Pressing S evokes a dialogue box where one can enter a sequence $S^*$.
• Pressing R resets all fractal parameters to the default.
• Pressing P initiates a 4K fractal rendering. The 4K fractal rendering thread can be killed by exiting the program prematurely, thus losing (!) the rendering.

// Java 1.8 code; written by Jonathan Frech, 2017

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

## JSweeper

Adding to my collection of clones of popular, well-known games, I created back in November of 2016 a Java-implementation of the all-time Windows classic game, Minesweeper.

Minesweeper was pre-installed on every installation of Windows up to and including Windows 7 and has been ported to a variety of different systems. Because of this, nearly everyone has at least once in their life played Minesweeper or at least heard of it.
In Minesweeper you are presented with a square grid of covered tiles containing either numbers or mines. Your task is it to uncover all tiles which are not mines in the least amount of time. When you uncover a mine, it explodes and the game is lost. To aid in figuring out which tiles are mines and which are not, every tile that is not a mine tells you how many mines are in the neighbouring eight tiles. Tiles which have no neighbouring mines are drawn gray and uncover neighbouring non-mine tiles once uncovered.
More on Minesweeper can be found in this Wikipedia article — I am linking to the German version, as the current English version has major flaws and lacks crucial information. If you are so inclined, feel free to fix the English Minesweeper Wikipedia article.

In my clone, there are three pre-defined difficulty levels, directly ported from the original Minesweeper game, and an option to freely adjust the board’s width and height as well as the number of bombs which will be placed. Gameplay is nearly identical to the original, as my clone also uses a square grid and the tile’s numbers correspond to the number of bombs in the eight tiles surrounding that tile.
The game has a purposefully chosen pixel-look using a self-made font to go along with the pixel-style.

#### Controls

• Arrow keys and enter to navigate the main menu
• Arrow keys or mouse movement to select tiles
• Space, enter or left-click to expose a tile
• ‘f’ or right-click to flag a tile
• ‘r’ to restart game when game is either won or lost
• F11 toggles fullscreen

To play the game, you can either download the .jar file or compile the source code for yourself. The source code is listed below and can be downloaded as a .java file.

// Java 1.6 / 1.8 code
// Jonathan Frech  5th of November, 2016
//         edited  7th of November, 2016
//         edited 11th of November, 2016
//         edited 13th of November, 2016
//         edited 14th of November, 2016
//         edited 15th of November, 2016
//         edited 17th of November, 2016
//         edited 19th of November, 2016
//         edited 19th of May     , 2017
//         edited 22nd of May     , 2017
//          * fixed max mine cap when
//            using custom settings