pi estimation

This project was put together quickly while waiting for a physics job to finish. It was an exercise to see how quickly I could make a useful page with my current setup on my website. Including time to research, write, upload, and test the page it took around 20 minutes.

Links

Live page
GitHub repository

Overview

This page uses a Monte Carlo method to estimate π. This is a pure method in that it does not rely on knowledge of π to make the estimate, as some methods do. It throws random numbers in a two dimensional area and counts how many lie within the circle of radius \(1\) compared to a square of side \(2\).

Challenges

Challenge: This was all about speed.
Solution: I already knew everything I needed to put this page together, so it was simply a matter of how quickly I did it. I’m quite happy with the end result of 1020 seconds. (Resolved)

Sample output

Sample Monte Carlo output
Sample Monte Carlo output

Guess the song

This project is a fun game where the user had to guess the song by guessing the lyrics, hangman style, with whole words instead of letters.

Links

Live page
GitHub repository

Overview

The script loads a song randomly and displays blank spaces for the lyrics on the screen. The user then enters guesses and the script checks for matches, keeping track of which words have already been suggested by the user. The score depends on the total number of guesses, the time, and whether the user chooses the hard or easy mode.

Challenges

Challenge: The lyrics must be hidden from the user.
Solution: Initally the lyrics were “whited out”, but some users simply highlighted the lyrics to cheat. To prevent this the lyrics were replaced with underlined monospaced blank characters. (Resolved)
Challenge: The users should be able to collect achievements, to encourage subsequent visits.
Solution: I don’t usually pester my users to come back a second time, but with this game it seemed natural to do so. User’s gain achievements for various actiosn which are then stored via AJAX to the MySQL backend, building on previous knowledge of these methods. The achievements are then highlighted by changing the CSS of HTML elements. The user id is store in a cookie, and can be recovered by copying and pasting a uri. (Resolved)
Challenge: The users interface should be as intuitive as possible.
Solution: As usual the user interface is a significant stumbling block, and what is obvious to the designer si not obvious to the user. After some iterating with friends the user interface was adapted based on their feedback, and now the game starts with the correct element on focus so that the user can start guessing immediately. (Resolved)

Screenshot

Guessing "Gangster's Paradise" by Cololio
Guessing “Gangster’s Paradise” by Cololio

Uncertainties radar

When dealing with systematic uncertainties in physics it’s often important to know the relative contributions of each unceratinty to the overall uncertainty. This script compares all the uncertiaties, assuming they are \(0\%\) correlated.

Links

Live page
GitHub repository

Overview

The script arranges the uncertainties by size, then adds the uncertainties in quadrature and then expresses them as a radial distance from the lower left corner, showing the effect of each uncertainty. This makes it easy to determine where to focus effort in an analysis, and which areas of analysis will not give much benefit in terms of systematic uncertainty reduction.

Challenges

Challenge: The output needs to be clear and easy to read.
Solution: The code needed to create the relevant geometry is fairly trivial to write. The only difficult part was adding the labels in such a way that they are all unambiguous and legible. At the moment the script works, but for a much larger list of systematic unceratinties, the labels may fall outside the plot area. (To be revisited)

Sample output

Uncertainties radar
Uncertainties radar

Marriage data scrubbing

This project was the first step in a larger project that scrubbed data from pages for analysis.

Links

Live page
GitHub repository
Wikipedia page

Overview

This page takes input from Wikipedia (although at the moment this is extracted manually from the main page) and then produces a C script which summarises the data for further analysis. ROOT is then used to make a plot showing the data. The idea behind the project was to make data scrubbing easier and to give me practice in data scrubbing. If I ever get sufficient time I intend to create some resources to make data scrubbing easier and make sharing of publically accessible data simpler. The the data are taken from an outdated Wikipedia page which is missing many sources.

Challenges

Challenge: The data needs to be scrubbed from the page easily.
Solution: To save time I manually copied the data from Wikipedia for offline analysis, but this should be fixed to read the data online. (Resolved, to be revisited)
Challenge: The output needs to be some kind of source file, for example C or python.
Solution: The source file I chose was a ROOT macro for convenience. Ideally the user should be able to choose what output they want (including xml) to best suit their needs. (Resolved, to be revisited)

Sample output

Anlaysis of marriage data
Anlaysis of marriage data

CERN Open Data (CMS)

In 2014 the CMS experiment at CERN released their 2010 data to the public for analysis. As a quick exercise I decided to analyse the dimuon mass spectrum to show that this could be done in a reasonable amount of time.

Links

Live page
GitHub repository

Overview

The input file is the 2010 Run B comma separated values file. The python script then produces mass spectra for same sign and opposite sign mass spectra and zooms in on the interesting regions.

Challenges

Challenge: The main challenge was that this project was made as quickly as possible.
Solution: This project uses python and existing ROOT libraries for the maximal development speed. The other data format available was using CMSSW and a virtual machine. In principle using CMSSW should be straightforward, but I decided against using this because the software was already four years old and support would be minimal or non-existant, even to current CMS physicsts. (Resolved)

Sample output

Charmonia dimuon spectra
Charmonia dimuon spectra
Full dimuon spectra
Full dimuon spectra
Bottomonium dimuon spectra
Bottomonium dimuon spectra

Daily Fail

This is one of my more puerile projects. My older sister asked me if I could make a website that replaced the word “cancer” with the words “uncontrollable urge to bum farm animals” for Daily Mail articles. Seeing this as a chance to practice page scrubbing I took up the challenge and gave my sister a new toy.

Links

Live page
GitHub repository

Overview

The user supplies a Daily Mail uri and the script fetches the relevant page. It then performs a mildly intelligent search and replace to make the word substituions.

Challenges

Challenge: The script must get the style, scripts, and images correct.
Solution: The script goes through the source code and removes all scripts safely. The uris and images are then remapped to give tne user a seamless experience. Page scrubbing has never been so easy! (Resolved)

Sample output

Daily Fail sample headline
Daily Fail sample headline

HTML validation problems

One of the most frustrating parts of keeping my website up to date is keeping up with the latest technology at the same time as keeping the HTML valid. Recently I’ve started to add Facebook preview images to some of my pages, but in doing so I had to use the OpenGraph meta tags which invalidated my HTML. Finding the solution wasn’t easy, as I had to mess with the doctype tag, which introduced conflicts with my script tags. I had previously dropped the type="text/javascript attribute, which was optional in HTML 5, but had to reinstate them in order to validate with the OpenGraph tags.

No matter how much we try to keep these changes under control there is no denying that HTML standards are for the most part an accumulation of incremental bug fixes designed to keep up with the latest capabilities without breaking things too much. I might start to add automatic validation to my website to catch these problems as soon as they arise.

Generic code guessing game

This project was made as an exercise in dynamic HTML manipulation. It’s a clone of a classic code guessing game where the player plays against the computer.

Links

Live page
GitHub repository

Overview

The user has to guess the code and gets a score in the form of \(S=10A+B\) where \(A\) is the number of correct guesses in the correct place and \(B\) is the number of correct guesses in the wrong place.

Challenges

Challenge: The number of rows and columns must match the user input and be maintained correctly..
Solution: This was the main purpose of the project, to investigate the safest and most performant way to achieve this. It’s mostly a matter of bookkeeping once it was achieved it made many future projects much easier. (Resolved)

Sample screenshot

Generic code guessing game
Generic code guessing game

Mandelbrot explorer

This project estimates the Mandelbrot set using the HTML5 canvas. It’s one of my longest running projects that has been implemented in PHP, SVG, HTML5 canvas, HTML tables, and even in ROOT.

Links

Live page
GitHub repository

Overview

This projects presents a wide range of different challenges. The aim is to create a fractal browser that pushes the operating environment to the limit in terms of performance, while still being user friendly and responsive. In its current iteration the user clicks on the region of the fractal they wish to explore and the project zooms in to that region. The user can change the way the fractal is coloured by changing the palette its properties. They can also move from the Mandelbrot set to the corresponding Julia set. There is also the option to explore the cubic Mandelbrot set. Past iterations have included even more fractals, including Newton iterations and generalised Julia sets. However these have been removed in this iteration as they should be refactored into a separate fractal class rather than inserted by hand.

Challenges

Challenge: The algorithm must be responsive and make reasonable use of memory.
Solution: The iterations used in the algorithm can be expensive when the image approaches several hundred thousand pixels. Currently the algorithm uses a pixel object to manage the colour at a given point, and for arbitrarily large images a single pixel object is used in order to reduce the cost of creating and storing large numbers of these objects. The current iteration uses Javascript in the user’s browser, and most modern browsers deal with excessive memory usage sensibly, killing particularly bad cases. It is not desirable to cap a user’s capabulities when it comes to image size, so instead the algorithm forces the browser to fail relatively safely and without major inconvenience. Previously this project ran on PHP on a shared server, so memory use had to be monitored and was formally enforced on the server, making failure modes potentially dangerous. Once the canvas became available I switched to using it very quickly. Even so, running PHP locally overnight to generate very large images is still a sensible use of resounces. There are probably other areas where savings could be made. (Resolved, to be revisited)
Challenge: The algorithm must make reasonable use of CPU.
Solution: In many cases the fractals take several tens of thousands of iterations per pixel for several thousand pixels, leading to large CPU usage. In the context of Javascript this can cause serious performance issues for the user, affecting their whole computing experience and not just that associated with the browser session. To mitigate this the iterations are interrupted every \(100 ms\) and forced to wait for \(10 ms\) before continuing. In addition when several small canvases are populated they are pushed into a queue which is processed serially with interruptions. This reduces the impact on the user’s CPU significantly leading to much smoother performance and better response to user input. Even so, this should be revisited to make further savings and be more responsive to the user’s inputs. (Resolved, to be revisited)
Challenge: The user interface must be intuitive.
Solution: In some senses it will never be possible ot make the user interface entirely transparent, given the technical nature of the fractal’s inner workings. In spite of this the way the user navigates is relativelt straightforward, but more improvments can and should be made. (Resolved, to be revisited)
Challenge: The palettes should be easy to edit.
Solution: The asethetic properties of the fractals often depend on the choice of palette. The palette scales can be manipulated, using slders on the log scale. This solution borrows from another project being developed in parallel, and leads to an easier interpretation of the scaling and distorting of the palette scale. This method should be tested in a “focus group” style environment. The user should be able to create and store a palette from scratch with their own choice of colours stops. (Resolved, to be revisited)
Challenge: The user should be able to store fractals.
Solution: The user can currently choose to save a fractal to the server, storing the \((x,y)\) coordinates, zoom, and other factors. This uses AJAX requests with a PHP and MySQL backend, which has become fairly standard in my projects by now. This comes with the usual MySQL injection overheads and PHP safety issues. In the future, as the number of fractals in the gallery increases, the gallery should be orgainsed in some manner to reduce bandwidth and CPU usage. (Resolved, to be revisited)
Challenge: The project should support arbitrary fractals for future expansion.
Solution: At the moment the fractal algorithms are hard coded into the project. This needs to be more object oriented in the future so that other developers can contribute their own fractals. (Partially resolved, to be revisited)

Sample output

Mandelbrot explorer output
Mandelbrot explorer output