# Mandelbrot: SETL & Lisp

SETL is a general-purpose programming language developed by Jack Schwartz back in the late 1960s. The language is multiparadigm – both Procedural (containing subroutines and control structures like if statements) and Set Theoretical. The latter is not often mentioned when talking about language paradigms – and is not to be confused with Logical Programming. The concept is outlined in the 1974 paper An Introduction to the Set Theoretical Language SETL. Importantly though data in SETL is of three main types: Atoms, Sets, and Sequences (also referred to as tuples or ordered sets).

A good overview of SETL can be found in the GNU SETL Om.

Pixels inside the Mandelbrot Set are marked in black, the code used to generate them (mandelbrot.setl) can be found here.

Generation of the Mandelbrot Set
On the Wikipedia page for the Mandelbrot Set you will find its formal definition, which looks like so: $M = \left\{c\in \mathbb C : \exists s\in \mathbb R, \forall n\in \mathbb N, |P_c^n(0)| \le s \right\}.$

The most fantastic thing about SETL is how powerful its Set Builder Notation is. Almost exactly as you would in the formal case (removing ‘there exists some real s’ for the practical application):

M := {c : c in image | forall num in {0..iterations} | cabs(pofc(c, num)) &lt;= 2};


For some reason SETL doesn’t support complex numbers, but they are easily handled by writing the necessary procedures we need like cabs, ctimes, and cplus dealing with tuples in the form [x, y]. The variable ‘image’ is a sequence of these tuples. Another procedure is written, pofc, which is a more practical version of $P_c^n(0)$.

Interaction with the Lisp graphical display
The goal of the SETL program is to produce a set of points that lie inside the Mandelbrot set. To actually display the image I used Common Lisp and displayed a widget with the image using CommonQt. In a very rudimentary way I had mandelbrot.setl take arguments about the image then print the set of pixel co-ordinates. All lisp had to do was swap and ‘{}’ or ‘[]’ for ‘()’ and read it as lisp code then update the image.

(setf in-set (read-from-string (parse-line (uiop:run-program "setl mandelbrot.setl -- -250 -250 250 8" :output :string))))
(draw-mandel instance in-set)


An after-thought was to make a Mandelbrot searcher where you could zoom and move using the mouse but the SETL code is such an inefficient way of doing it that it’s not worth it. As an attempt to mimic the formal definition it was highly successful and fun. Though much quicker SETL code could be written for generating the Mandelbrot Set.

Source file for mandelbrot.setl and the Lisp/CommonQt front end can be found here.

# MuSh: Multi-Shebang Scripting

MuSh is a super simple meta-scripting language for parsing multiple shebang statements that invoke different interpretors. Why would you want to do this? I have no idea. Although there is no real reason to do this you might want to just for the fun of it.

How it works
MuSh is python based and has a linear approach, it splits up the script into smaller single-language scripts then runs them one after the other. Variables are transported between scripts using a register file (msb_register.json) and hook-in functions which add code to the scripts for interacting with the register. There are two important syntaxes (syntaces?) for separating languages, the first is:

#!! <interpretor> <passed-variables …>

A little Guess my Number game that uses Shell, Python and Common Lisp. This example can be found at ‘examples/guess_my_num.msb‘ and uses the Vim syntax file found in the repo at editor_support/mush.vim.

Subscripting
The second separation syntax is for embedded use, it has open and close functionality:

#![ <interpretor> <passed-variables …>
#!] <passed-variables …>

MuSh uses the hook-in function inline_replace which replaces the embedded code with a call to a subscript (of that code). In the example below you can see how a python program might use subscripting to use Lisp. The left is the original, the right is after inline_replace has been called:

 def fact_lisp(n): #![ clisp n (defun fact (n) (if (< n 2) 1 (* n (fact(- n 1))))) (setf out (fact n)) #!] out return out  def fact_lisp(n): # Get 'n' from register ... from subprocess import call call("./subscript_0", shell=True) # Get 'out' from register ... return out 

The above code is from ‘examples/fact_speed_IO.msb from the repo. The meta-script starts with a python program that defines three factorial functions using subscripts to Python, Common Lisp, and Shell (sh). These three are called inside a python forloop 1000 times – calculating 10! each loop. Python timing methods are used giving:

 Subscripts Python Common Lisp Shell Time (seconds) 25.4605309963 18.8304021358 21.1056499481

It also defines a pure python factorial function, which it also loops for. Next the meta-script moves to a Lisp program which has a Lisp forloop and factorial function, timing here is done with (get-internal-real-time) and (internal-time-units-per-second). Finally the meta-script moves to Shell and runs a while loop for its factorial function. These script results seem peculiar to me, Lisp shows to be slower than Python and Shell is almost as bad as subscripting:

 Scripts Python Common Lisp Shell Time (seconds) 0.002014 0.009645 14

I find it strange that when using a python loop/timing – python was the slowest, but when using native loops/timing – python was the fastest. This could be because my implementation is incorrect somewhere or python just has great looping but bad recursive arithmetic. Maybe it’s a reflection of how python interacts with the register. I’m more confused by why shell is so slow.

# The RGB Universe

One image bounded to three respective spaces: Colour, Chromaticity, and Hue.

The Colour-Space: RGB
Everyone is familiar with this, it is the additive model for colours that uses the primaries: red, green & blue. A 3D Model where each unique colour sits at position (x: r, y: g, z: b).

The Chromaticity-Space: RCGCBC
Some people will be familiar with this, it is RGB without luminance, the brightness is removed in a way that doesn’t effect the hue or saturation. It is referred to as rg-Chromaticity because it’s construction from RGB means only two elements are needed to represent all the chromaticity values:

 Conversion to Conversion from (kind of*) $R_C= \frac{R}{R+G+B}$ $G_C= \frac{G}{R+G+B}$ $B_C= \frac{B}{R+G+B}$ $R = \frac{R_C G}{G_C}$ $G = G$ $B = \frac{(1 - R_C - G_C) G}{G_C}$

It will always be that $R_C + G_C + B_C = 1$ so by discarding the blue component we can have unique chromaticities as (x: r’, y: g’). This means that rg-Chromaticity is a 2D-Model and when converting to it from RGB we lose the luminance. So it is impossible to convert back. *An in-between for this is the colour-space rgG where the G component preserves luminance in the image.

The Hue-Space: RHGHBH
No one uses this, I just thought it would be fun to apply the same as above and extract the saturation from RCGCBC. Like RCGCBC it is a 2D Model, this seems strange because it is only representing one attribute –hue– but it is because the elements themselves have a ternary relationship (how much red, how much green, how much blue) and so to extrapolate one you must know the other two.

 Conversion to 3-tuple Hue Normalise to 2D $M = \text{Max}(R,G,B)$ $m = \text{Min}(R,G,B)$ $\delta = 255/(M-m)$ $R_h = (R-m) \delta$ $G_h = (G-m) \delta$ $B_h = (B-m) \delta$ $R_H = \frac{R_h}{R_h + G_h + B_h}$ $G_H = \frac{G_h}{R_h + G_h + B_h}$ $B_H = \frac{B_h}{R_h + G_h + B_h}$

Measuring Hue Distance
The HSL colour-space records hue as a single element, H, making measuring distance as easy as $\Delta H = \sqrt{{H_a}^2 - {H_b}^2}$ where as in rg-Hue we have two elements so $\Delta H = \sqrt{({R''_a}^2 - {R''_b}^2) + ({G''_a}^2 - {G''_b}^2)}$ where $R'' = R_H$ and $G'' = G_H$ for readability. What’s interesting here is it works almost the same. Though it should be noted that on a line only two distances are equidistant to zero at one time where as in rg-Hue, on a 2D plane, there are many equidistant points around circles.

Below are images of a RGB testcard where each pixel’s hue has been measured against a colour palette (60° Rainbow) and coloured with the closest match. The rg-Hue measure has a notable consistency to it and shows more red on the right hand side than HSL, but also between the yellow and red there is a tiny slither of purple. I believe this is from the equal distance hues and the nature of looking through a list for the lowest value when there are multiple lowest values:

 Hue Distance (HSL) Hue Distance (RHGHBH)

# Accuracy of Generated Fractals

Note: I refer to the Mandelbrot set in general as the M-set for short.

When I was writing the post on Rough Mandelbrot Sets I tried out some variations on the rough set. One variation was to measure the generated M-set against a previously calculated master M-set of high precision (100000 iterations of $z = z^2 + C$). In the image below the master M-set is in white and the generated M-sets are in green (increasing in accuracy):

Here instead of approximating with tiles I measured the accuracy of the generated sets against the master set by pixel count. Where $P = \{ \text{set of all pixels} \}$ the ratio of $P_{master} / P_{generated}$ produced something that threw me, the generated sets made sudden but periodic jumps in accuracy:

Looking at the data I saw the jumps were, very roughly, at multiples of 256. The size of the image being generated was 256 by 256 pixels so I changed it to N by N for N = {120, 360, 680} and the increment was still every ~256. So I’m not really sure why, it might be obvious, if you know tell me in the comments!

I am reminded of the images generated from Fractal Binary and other Complex Bases where large geometric entities can be represented on a plane by iteration through a number system. I’d really like to know what the Mandelbrot Number System is…

Below is a table of the jumps and their iteration index:

 Iterations Accuracy measure 255 256 0.241929 0.397073 510 511 0.395135 0.510806 765 766 0.510157 0.579283 1020 1021 0.578861 0.644919 1275 1276 0.644919 0.679819 1530 1531 0.679696 0.718911

# Editing Ultraviolet Photography

For people who do multispectral photography (infrared, visible, ultraviolet, etc) sometimes it can be tricky to achieve what you want in a traditional photo editor. That is why I am developing software to cater specifically for multispectral image processing. The software is called WavelengthPro. Below is a quick video, four images and explanations for the results.

The Resulting Images:
These four images are made from only this visible light image and this ultraviolet image. They were both taken with the same camera, Nikon D70 (hot mirror removed), using an IR-UV cut filter and the Baader-U filter. No extra editing was done.

 Dual Process Luminance Map

One often met problem in ultraviolet photography is getting the right white-balance on your camera – if you can’t achieve it you end up with rather purple pictures. In WavelengthPro there is a tool called Dual Processing where you create the green channel out of the red and blue channels which rids your image of the purpley hue.

The Luminance Map is actually a lightness map, made in HSL colour-space, it is the hue and saturation of the visible light image with the lightness of the UV image. As you can see the specular effect on the leaves completely contrasts the mat flowers. There is a good example of useful application for this method in the post Luminance Mapping: UV and Thermal.

 5to3 Map (RGBUrUb) 3to3 Map (GBU)

There are only 3 channels (ignoring alpha) for an image to be encoded into but in WavelengthPro that is attempted to be extended by mapping N channels to the 3 (RGB) output channels. A classic ultraviolet editing method is to make a GBU image, like the image on the right. The image on the left has five channels equally distributed across the three RGB channels. An array of different maps can be seen in an older post called Testing Infrared Software. If you want to download and try out the software (it’s still in alpha stage – don’t expect everything to work) then the link below will have the latest release version.

WavelengthPro Flickr Group

# Rough Mandelbrot Sets

I’ve been reading up on Zdzisław Pawlak’s Rough Set Theory recently and wanted to play with them. They are used to address vagueness in data so fractals seem like a good subject.

Super Quick Intro to Rough Sets:
A rough set is a tuple (ordered pair) of sets $R(S) = \langle R_*, R^* \rangle$ which is used to model some target set S. The set $R_*$ has every element definitely in set $S$ and set $R^*$ has every element that is possibly in set $S$ . It’s roughness can be measured by the accuracy function $\alpha(S) = \frac{|R_*|}{|R^*|}$. So when $|R_*| = |R^*|$ then the set is known as crisp (not vague) with an accuracy of 1.

A more formal example can be found on the wiki page but we’ll move on to the Mandelbrot example because it is visually intuitive:

The tiles are 36×36 pixels, the Mandelbrot set is marked in yellow. The green and white tiles are possibly in the Mandelbrot set, but the white tiles are also definitely in it.

Here the target set $S$ contains all the pixels inside the Mandelbrot set, but we are going to construct this set in terms of tiles. Let $T_1, T_2, T_3,\dots , T_n$ be the tile sets that contain the pixels. $R^*$ is the set of all tiles $T_x$ where the set $T_x$ contains at least one pixel that is inside the Mandelbrot set, $R_*$ is the set of all tiles $T_x$ that contain only Mandelbrot pixels. So in the above example there are 28 tiles possibly in the set including the 7 tiles definitely in the set. Giving $R(S)$ an accuracy of 0.25.

Tile width: 90, 72, 60, 45, 40, 36, 30, 24, 20, 18, 15, 12, 10, 9, 8, 6, 5, 4. There seems to be a lack of symmetry but it’s probably from computational precision loss.

Obviously the smaller the tiles the better the approximation of the set. Here the largest tiles (90×90 pixels) are so big that there are no tiles definitely inside the target set and 10 tiles possibly in the set, making the accuracy 0. On the other hand, the 4×4 tiles give us $|R_*| = 1211$ and $|R^*| = 1506$ making a much nicer:

$\alpha(S)$ = $0.8 \overline{04116865869853917662682602921646746347941567065073}$

For much more useful applications of Rough Sets see this extensive paper by Pawlak covering the short history of Rough Sets, comparing them to Fuzzy Sets and showing uses in data analysis and Artificial Intelligence.

# Digital Orthochromatic Photography

I’m playing with ways of emulating early orthochromatic film, if anyone knows any technical aspects to this that might help – feel free to suggest ideas. So far I’m just winging it.

Light Response of Film
In terms of light covered it goes: Blue-sensitive, orthochromatic, isochromatic, panchromatic (all visible wavelengths) then super-panchromatic.

On the right is a photo of British explorers taken with orthocromatic film. Note the red on the flag is much darker than the blue area because the film isn’t receptive of red light. Looking at the spectral sensitivity (here) and (here) it’s clear the violet/blue area is the predominant band with it extending to green/yellow as well.

Test Ideas
I took an image from Google, something with the British flag, and made different Channel Maps for it. The greyscaled versions are the output images.

I used the QSE tool on WavelengthPro to make a 400nm image (the violet/blue peak) and a 580nm (the green/yellow peak) and made a 2to3 map of the peaks, the colour response worked well but the data-loss from interpolation was too much. Using the original [R,G,B] channes means I won’t lose any detail, so I tried using mainly those and came up with two maps that were pretty good – GBB and GBBV. Below are those maps and the RGB map for comparison.

 This is the RGB (panchromatic) version, the red cross on the flag is lighter than the blue parts and the sky is dark. This is a GBBtoRGB version, the cross appears darker. It’s not really true to the actual spectral response of the film. This is a GBBVtoRGB version, the V is the interpolated deep violet image. Getting there…