index 700a8b9..87d18ce 100644 (file)
\chapter{Literature Review}\label{Background}

-This chapter will \rephrase{review the literature. It will also include some figures created by us from our test programs to aid with conceptual understanding of the literature.} A paper by paper summary of the literature is also available at: \\ \url{http://szmoore.net/ipdf/documents/LiteratureNotes.pdf}.
+The first half of this chapter will be devoted to documents themselves, including: the representation and displaying of graphics primitives\cite{computergraphics2}, and how collections of these primitives are represented in document formats, focusing on widely used standards\cite{plrm, pdfref17, svg2011-1.1}.

-\rephrase{TODO: If I want to link to the Paper by Paper summary it will need a bit of rewriting}.
+We will find that although there has been a great deal of research into the rendering, storing, editing, manipulation, and extension of document formats, modern standards are content to specify at best single precision IEEE-754 floating point arithmetic.

-\rephrase{TODO: Actually (re)write this entire chapter}.
+The research on arbitrary precision arithmetic applied to documents is very sparse; however arbitrary precision arithmetic itself is a very active field of research. Therefore, the second half of this chapter will be devoted to considering fixed precision floating point numbers as specified by the IEEE-754 standard, possible limitations in precision, and alternative number representations for increased or arbitrary precision arithmetic.

-\rephrase{TODO: Un dot point ify}
+In Chapter \ref{Progress}, we will discuss our findings so far with regards to arbitrary precision arithmetic applied to document formats, and expand upon the goals outlined in Chapture \ref{Proposal}.

-\rephrase{TODO: Citations}
+\section{Raster and Vector Images}\label{Raster and Vector Images}
+\input{chapters/Background_Raster-vs-Vector}

-\rephrase{TODO: Make less terrible}
+\section{Rasterising Vector Images}\label{Rasterising Vector Images}

+Throughout Section \ref{vector-vs-raster-graphics} we were careful to refer to modern'' display devices, which are raster based. It is of some historical significance that vector display devices were popular during the 70s and 80s, and papers oriented towards drawing on these devices can be found\cite{brassel1979analgorithm}. Whilst curves can be drawn at high resolution on vector displays, a major disadvantage was shading; by the early 90s the vast majority of computer displays were raster based\cite{computergraphics2}.

-\rephrase{TODO: Reconsider sections (do I really want to make this go down to} \verb/\subsubsection/?)
+Hearn and Baker's textbook Computer Graphics''\cite{computergraphics2} gives a comprehensive overview of graphics from physical display technologies through fundamental drawing algorithms to popular graphics APIs. This section will examine algorithms for drawing two dimensional geometric primitives on raster displays as discussed in Computer Graphics'' and the relevant literature. Informal tutorials are abundant on the internet\cite{elias2000graphics}. This section is by no means a comprehensive survey of the literature but intends to provide some idea of the computations which are required to render a document.

-\rephrase{TODO: :-(}
+\subsection{Straight Lines}\label{Straight Lines}
+\input{chapters/Background_Lines}

+\subsection{Spline Curves}\label{Spline Curves}

+Splines are continuous curves formed from piecewise polynomial segments. A polynomial of $n$th degree is defined by $n$ constants $\{a_0, a_1, ... a_n\}$ and:
+\begin{align}
+       y(x) &= \displaystyle\sum_{k=0}^n a_k x^k
+\end{align}

-\section{Vector Graphics vs Raster Graphics}

-\newlength\imageheight
-\newlength\imagewidth
-\settoheight\imageheight{\includegraphics{figures/fox-raster.png}}
-\settowidth\imagewidth{\includegraphics{figures/fox-raster.png}}
+A straight line is simply a polynomial of $0$th degree. Splines may be rasterised by sampling of $y(x)$ at a number of points $x_i$ and rendering straight lines between  $(x_i, y_i)$ and $(x_{i+1}, y_{i+1})$ as discussed in Section \ref{Straight Lines}. More direct algorithms for drawing splines based upon Brasenham and Wu's algorithms also exist\cite{citationneeded}.

-%Height: \the\imageheight
-%Width: \the\imagewidth
+There are many different ways to define a spline. One approach is to specify knots'' on the spline and solve for the cooefficients to generate a cubic spline ($n = 3$) passing through the points. Alternatively, special polynomials may be defined using control'' points which themselves are not part of the curve; these are convenient for graphical based editors. Bezier splines are the most straight forward way to define a curve in the standards considered in Section \ref{Document Representations}
+\subsubsection{Bezier Curves}
+\input{chapters/Background_Bezier}

-\rephrase{TODO: Distinguish between Raster Formats and the Rasterisation of an image (which may or may not be in a raster format)}
+\subsection{Font Rendering}

-
-\subsubsection{Raster Graphics}
-\begin{itemize}
-       \item Bitmap --- array of colour information for pixels
-       \item Exact pixels in a similar format to how they would appear on a (modern) display device.
-       \begin{itemize}
-               \item Also similar to how they would be stored by a camera or scanner
-               \item \rephrase{Is it misleading to say 2D array? Pixels are actually stored in a 1D array, but conceptually it's nicer to say 2D}
-               \item \rephrase{For that matter, should it described as 3D (3rd dimension = colour)?}
-       \end{itemize}
-       \item Lowest level representation of a document
-       \item Issues with scaling; values of extra pixels must be calculated
-       \item Not convenient to edit; ill suited to text
-\end{itemize}
-
-
-\subsubsection{Vector Graphics}
-\begin{itemize}
-       \item Stores relative position of primitives - scales better
-       \item In particular, \emph{edges} of lines can be zoomed without becomming jagged; sometimes (somewhat misleadingly) described as infinitely sharp''
-       \item Vector Graphics must be rasterised before being drawn on most display devices.
-       \item Still can't scale forever due to use of fixed size floats
-\end{itemize}
-
-\subsubsection{Resolution and Raster Graphics}
-\begin{itemize}
-       \item DPI = dots (pixels) per inch differs per display device - a rastered image looks different on different display devices
-       \item PostScript/PDF use 72 points per inch; this means a rasterised image will look the same in all pdf viewers regardless of the display.
-       \item Tex uses 72.27 points per inch (?)
-       \item The vector image was rastered at 96 points per inch
-       \item Hence, have to scale by 72.27/96 = 0.7528125 to get the vector and rastered version to look exactly the same in the pdf
-\end{itemize}
+Donald Knuth's 1986 textbook Metafont'' blargh

-\begin{figure}[H]
-       \centering
-
-       \includegraphics[scale=0.7528125]{figures/fox-vector.pdf}
-       \includegraphics[scale=0.7528125]{figures/fox-raster.png}
-       \includegraphics[scale=0.7528125, viewport=210 85 280 150,clip, width=0.45\textwidth]{figures/fox-vector.pdf}
-       \includegraphics[scale=0.7528125, viewport=0 85 70 150,clip, width=0.45\textwidth]{figures/fox-raster.png}
-       \caption{Scaling of vector and Raster Graphics}\label{vector-vs-raster}
-\end{figure}

+Algorithms for shading on vector displays involved drawing equally spaced lines in the region with endpoints defined by the boundaries of the region\cite{brassel1979analgorithm}. Apart from being unrealistic, these techniques required a computationally expensive sorting of vertices\cite{lane1983analgorithm}.

+On raster displays, shading is typically based upon Lane's algorithm of 1983\cite{lane1983analgorithm}. Lane's algorithm relies on the ability to subtract'' fill from a region. This algorithm is now implemented in the GPU \rephrase{stencil buffer-y and... stuff} \cite{kilgard2012gpu}

-Figure \ref{vector-vs-raster} shows a vector image (left) which has been rasterised (right). At the original scale the two foxes should appear to be mirror images\footnote{If I've worked out the scaling to account for dpi differences between inkscape and latex/pdf correctly}. When the scale is increased, the edges of the vector image remain sharp, whilst the raster image begins to appear jagged. PDF viewers will typically use antialiasing to smooth the edges of a scaled bitmap, causing the image to appear blurred.\footnote{In the Atril Document Viewer 1.6.0 this image will only be antialiased at zoom levels $\leq 125\%$}.
+\subsection{Compositing and the Painter's Model}\label{Compositing and the Painter's Model}

-Various ways to end this section:
-\begin{enumerate}
-       \item \rephrase{It should be obvious that documents containing text must use the vector graphics format, and so the remainder of this chapter will concentrate on the latter}.
-       \item \rephrase{As can be seen in Figure \ref{fox}, if we were to decide to pursue infinite precision'' in raster graphics we would be shooting ourselves in both feet and then the face before we even started. The rest of this chapter will concentrate on vector graphics.}
-       \item \rephrase{You can't have infinite precision in raster graphics by definition, therefore we no longer care about them in this report.}
-       \item \rephrase{This report being in a vector format is a clue that we only care about vector formats}.
-\end{enumerate}
+So far we have discussed techniques for rendering vector graphics primitives in isolation, with no regard to the overall structure of a document which may contain many thousands of primitives. A straight forward approach would be to render all elements sequentially to the display, with the most recently drawn pixels overwriting lower elements. Such an approach is particularly inconvenient for anti-aliased images where colours must appear to smoothly blur between the edge of a primitive and any drawn underneath it.

-\section{Primitives in Vector Graphics Formats (and how they are Rendered)}
+Colour raster displays are based on an additive red-green-blue $(r,g,b)$ colour representation which matches the human eye's response to light\cite{computergraphics2}. In 1984, Porter and Duff introduced a fourth colour channel for rasterised images called the alpha'' channel, analogous to the transparency of a pixel\cite{porter1984compositing}. In compositing models, elements can be rendered seperately, with the four colour channels of successively drawn elements being combined according to one of several possible operations.

-\subsection{Bezier Curves}
-\rephrase{I did an ipython notebook on this in February, but I forgot all of it}
+In the painter's model'' as described by the SVG standard, Porter and Duff's over'' operation is used when rendering one primitive over another\cite{svg2011-1.1}.
+Given an existing pixel $P_1$ with colour values $(r_1, g_1, b_1, a_1)$ and a pixel $P_2$ with colours $(r_2, g_2, b_2, a_2)$ to be painted over $P_1$, the resultant pixel $P_T$ has colours given by:
+\begin{align}
+       a_T &= 1 - (1-a_1)(1-a_2) \\
+       r_T &= (1 - a_2)r_1 + r_2 \quad \text{(similar for $g_T$ and $b_T$)}
+\end{align}
+It should be apparent that alpha values of $1$ correspond to an opaque pixel; that is, when $a_2 = 1$ the resultant pixel $P_T$ is the same as $P_2$.
+When the final pixel is actually drawn on an rgb display, the $(r, g, b)$ components are $(r_T/a_T, g_T/a_T, b_T/a_T)$.

-\subsection{Text}
-Text is just Bezier Curves
+The PostScript and PDF standards, as well as the OpenGL API also use a painter's model for compositing. However, PostScript does not include an alpha channel, so $P_T = P_2$ always\cite{plrm}. Figure \ref{SVG} illustrates the painter's model for partially transparent shapes as they would appear in both the SVG and PDF models.

-\subsection{Shapes}
-Shapes are just bezier curves joined together.
+\subsection{Rasterisation on the CPU and GPU}

-\subsection{Other Things}
-We don't really care about other things (ie: Colour gradients etc) in this report.
+Traditionally, vector graphics have been rasterized by the CPU before being sent to the GPU for drawing\cite{kilgard2012gpu}. Lots of people would like to change this \cite{worth2003xr, loop2007rendering, rice2008openvg, kilgard2012gpu, green2007improved}.

-\section{Document Representations}
+\rephrase{2. Here are the ways documents are structured ... we got here eventually}

-\rephrase{The file format can be either human readable\footnote{For some definition of human and some definition of readable} or binary\footnote{So, our viewer is basically a DOM style but stored in a binary format}. Can also be compressed or not. Here we are interested in how the document is interpreted or traversed in order to produce graphics output.}
+\section{Document Representations}\label{Document Representations}

+The representation of information, particularly for scientific purposes, has changed dramatically over the last few decades. For example, Brassel's 1979 paper referenced earlier has been produced on a mechanical type writer. Although the paper discusses an algorithm for shading on computer displays, the figures illustrating this algorithm have not been generated by a computer, but drawn by Brassel's assistant\cite{brassel1979analgorithm}. In contrast, modern papers such as Barnes et. al's recent paper on embedding 3d images in PDF documents\cite{barnes2013embeddding} can themselves be an interactive proof of concept.

+In this section we will consider various approaches and motivations to specifying the structure and appearance of a document, including: early interpreted formats (PostScript, \TeX, DVI), the Document Object Model popular in standards for web based documents (HTML, SVG), and Adobe's ubiquitous Portable Document Format (PDF). Some of these formats were discussed in a recent paper Pixels Or Perish'' by Hayes\cite{hayes2012pixelsor} who argues for greater interactivity in the PDF standard.

-\subsection{Interpreted Model}
+\subsection{Interpreted Document Formats}
+\input{chapters/Background_Interpreted}

-\rephrase{Did I just invent that terminology or did I read it in a paper? Is there actually existing terminology for this that sounds similar enough to Document Object Model'' for me to compare them side by side?}

\begin{itemize}
\item This model treats a document as the source code program which produces graphics
\item Arose from the desire to produce printed documents using computers (which were still limited to text only displays).
\item Typed by hand or (later) generated by a GUI program
\item PostScript --- largely supersceded by PDF on the desktop but still used by printers\footnote{Desktop pdf viewers can still cope with PS, but I wonder if a smartphone pdf viewer would implement it?}
-       \item \TeX --- Predates PostScript! {\LaTeX } is being used to create this very document and until now I didn't even have it here!
+       \item \TeX --- Predates PostScript, similar idea
\begin{itemize}
-               \item I don't really want to go down the path of investigating the billion steps involved in getting \LaTeX into an actually viewable format
-               \item There are interpreters (usually WYSIWYG editors) for \LaTeX though
\item Maybe if \LaTeX were more popular there would be desktop viewers that converted \LaTeX directly into graphics
\end{itemize}
\item Potential for dynamic content, interactivity; dynamic PostScript, enhanced Postscript

-       \item Scientific Computing --- Mathematica, Matlab, IPython Notebook --- The document and the code that produces it are stored together
\item Problems with security --- Turing complete, can be exploited easily
\end{itemize}

-\subsection{Crippled Interpreted Model}
+\pagebreak
+\subsection{Document Object Model}\label{Document Object Model}
+\input{chapters/Background_DOM}

-\rephrase{I'm pretty sure I made that one up}
+\subsection{The Portable Document Format}

-\begin{itemize}
-       \item PDF is PostScript but without the Turing Completeness
-       \item Solves security issues, more efficient
-\end{itemize}

-\subsection{Document Object Model}
+\subsection{Scientific Computation Packages}
+
+The document and the code that produces it are one and the same.

\begin{itemize}
-       \item DOM = Tree of nodes; node may have attributes, children, data
-       \item XML (SGML) is the standard language used to represent documents in the DOM
-       \item XML is plain text
-       \item SVG is a standard for a vector graphics language conforming to XML (ie: a DOM format)
+       \item Numerical computation packages such as Mathematica and Maple use arbitrary precision floats
+       \begin{itemize}
+               \item Mathematica is not open source which is an issue when publishing scientific research (because people who do not fork out money for Mathematica cannot verify results)
+               \item What about Maple? \cite{HFP} and \cite{fousse2007mpfr} both mention it being buggy.
+               \item Octave and Matlab use fixed precision doubles
+       \end{itemize}
+       \item IPython is pretty cool guys
\end{itemize}

-\subsection{Blurring the Line --- Javascript}
+\section{Precision in Modern Document Formats}

+We briefly summarise the requirements of the standards discussed so far in regards to the precision of mathematical operations:
\begin{itemize}
-       \item The document is expressed in DOM format using XML/HTML/SVG
-       \item A Javascript program is run which can modify the DOM
-       \item At a high level this may be simply changing attributes of elements dynamically
-       \item For low level control there is canvas2D and even WebGL which gives direct access to OpenGL functions
-       \item Javascript can be used to make a HTML/SVG interactive
-       \begin{itemize}
-               \item Overlooking the fact that the SVG standard already allows for interactive elements...
-       \end{itemize}
-       \item Javascript is now becoming used even in desktop environments and programs (Windows 8, GNOME 3, Cinnamon, Game Maker Studio) ({\bf shudder})
-       \item There are also a range of papers about including Javascript in PDF Pixels or Perish'' being the only one we have actually read\cite{hayes2012pixels}
-       \begin{itemize}
-               \item I have no idea how this works; PDF is based on PostScript... it seems very circular to be using a programming language to modify a document that is modelled on being a (non turing complete) program
-               \item This is yet more proof that people will converge towards solutions that work'' rather than those that are optimal or elegant
-               \item I guess it's too much effort to make HTML look like PDF (or vice versa) so we could phase one out
-       \end{itemize}
+       \item {\bf PostScript} predates the IEEE-754 standard and originally specified a floating point representation with ? bits of exponent and ? bits of mantissa. Version ? of the PostScript standard changed to specify IEEE-754 binary32 single precision'' floats.
+       \item {\bf PDF} has also specified IEEE-754 binary32 since version ?. Importantly, the standard states that this is a \emph{maximum} precision; documents created with higher precision would not be viewable in Adobe Reader.
+       \item {\bf SVG} specifies a minimum of IEEE-754 binary32 but recommends more bits be used internally
+       \item {\bf Javascript} uses binary32 floats for all operations, and does not distinguish between integers and floats.
+       \item {\bf Python} uses binary64 floats
+       \item {\bf Matlab} uses binary64 floats
+       \item {\bf Mathematica} uses some kind of terrifying symbolic / arbitrary float combination
+       \item {\bf Maple} is similar but by many accounts horribly broken
+
\end{itemize}

+\rephrase{4. Here is IEEE-754 which is what these standards use}

+\section{Real Number Representations}

-\section{Precision Limitations of Modern Documents}
+We have found that PostScript, PDF, and SVG document standards all restrict themselves to IEEE floating point number representations of coordinates. This is unsurprising as the IEEE standard has been successfully adopted almost universally by hardware manufactures and programming language standards since the early 1990s. In the traditional view of a document as a static, finite sheet of paper, there is little motivation for enhanced precision.

-\rephrase{All this is very interesting and provides important context, but it is not actually directly related to the problem of infinite precision which we are going to try and solve}.
+In this section we will begin by investigating floating point numbers as defined in the IEEE standard and their limitations. We will then consider alternative number representations including fixed point numbers, arbitrary precision floats, rational numbers, p-adic numbers and symbolic representations. \rephrase{Oh god I am still writing about IEEE floats let alone all those other things}

-\subsection{Limitations Imposed By Standards}
-\begin{itemize}
-       \item Implementations of PostScript and PDF must by definition restrict themselves to IEEE binary32 single precision'' floating point number representations in order to conform to the standards\cite{plrm, pdfref17}.
-       \item Implementations of SVG are by definition required to use IEEE binary32 as a {\bf minimum}. High Quality'' SVG viewers are required to use at least IEEE binary64.\cite{svg2011-1.1}
-\end{itemize}
+\rephrase{Reorder to start with Integers, General Floats, then go to IEEE, then other things}

+\subsection{IEEE Floating Points}

-\subsection{Limitations Imposed By Graphics APIs and/or GPUs}
+Although the concept of a floating point representation has been attributed to various early computer scientists including Charles Babbage\cite{citationneeded}, it is widely accepted that William Kahan and his colleagues working on the IEEE-754 standard in the 1980s are the fathers of modern floating point computation''\cite{citationneeded}. The original IEEE-754 standard specified the encoding, number of bits, rounding methods, and maximum acceptable errors for the basic floating point operations for base $B = 2$ floats. It also specifies exceptions'' --- mechanisms by which a program can detect an error such as division by zero\footnote{Kahan has argued that exceptions in IEEE-754 are conceptually different to Exceptions as defined in several programming languages including C++ and Java. An IEEE exception is intended to prevent an error by its detection, whilst an exception in those languages is used to indicate an error has already occurred\cite{}}. We will restrict ourselves to considering $B = 2$, since it was found that this base in general gives the smallest rounding errors\cite{HFP}, although it is worth noting that different choices of base had been used historically\cite{goldman1991whatevery}, and the IEEE-854 and later the revised IEEE-754 standard specify a decimal representation $B = 10$ intended for use in financial applications.

-It's not really the standard's fault (although they could specify double); they specify IEEE because underlying hardware must use IEEE.
+\subsection{Floating Point Definition}

-\begin{itemize}
-       \item Internal representations are GPU dependent\cite{hillesland2004paranoia}
-       \item OpenGL standards specify: binary16, binary32, binary64
-       \item OpenVG aims to become a standard API for SVG viewers but it uses binary32 and may be {\bf worse} internally\cite{rice2008openvg}
-\end{itemize}
+A floating point number $x$ is commonly represented by a tuple of integers $(s, e, m)$ in base $B$ as\cite{HFP, ieee2008-754}:

-\subsection{Limitations Imposed By CPU}
+\begin{align*}
+       x &= (-1)^{s} \times m \times B^{e}
+\end{align*}

-Even if we don't use the GPU, CPU's are restricted in their representation of floating point numbers by the IEEE standard.
+Where $s$ is the sign and may be zero or one, $m$ is commonly called the mantissa'' and $e$ is the exponent.
+The name floating point'' refers to the equivelance of the $\times B^e$ operation to a shifting of a decimal point along the mantissa. This contrasts with a fixed point'' representation where $x$ is the sum of two fixed size numbers representing the integer and fractional part.

-\rephrase{AND THUS WE FINALLY GET TO THE POINT}
+In the IEEE-754 standard, for a base of $B = 2$, numbers are encoded in continuous memory by a fixed number of bits, with $s$ occupying 1 bit, followed by $e$ and $m$ occupying a number of bits specified by the precision; 5 and 10 for a binary16 or half precision'' float, 8 and 23 for a binary32 or single precision'' and 15 and 52 for a binary64 or double precision'' float\cite{HFP, ieee2008-754}.

-\section{Representation of Numbers}

-Although this project has been motivated by a desire for more flexible document formats, the fundamental source of limited precision in vector document formats is the restriction to IEEE floating point numbers for representation of coordinates.
+\subsection{Precision and Rounding}

-Whilst David Gow will be focusing on structures \rephrase{and the use of multiple coordinate systems} to represent a document so as to avoid or reduce these limitations\cite{proposalGow}, the focus of our own research will be \rephrase{increased precision in the representation of real numbers so as to get away with using a single global coordinate system}.
+Real values which cannot be represented exactly in a floating point representation must be rounded. The results of a floating point operation will in general be such values and thus there is a rounding error possible in any floating point operation. Goldberg's assertively titled 1991 paper What Every Computer Scientist Needs to Know about Floating Point Arithmetic'' provides a comprehensive overview of issues in floating point arithmetic and relates these to the 1984 version of the IEEE-754 standard\cite{goldberg1991whatevery}. More recently, after the release of the revised IEEE-754 standard in 2008, a textbook Handbook Of Floating Point Arithmetic'' has been published which provides a thourough review of literature relating to floating point arithmetic in both software and hardware\cite{HFP}.

-\subsection{The IEEE Standard}

-\subsection{Floating Point Number Representations}
+Figure \ref{minifloat.pdf} shows the positive real numbers which can be represented exactly by an 8 bit base $B = 2$ floating point number; and illustrates that a set of fixed precision floating point numbers forms a discrete approximation of the reals. There are only $2^7 = 256$ numbers in this set, which means it is easier to see some of the properties of floats that would be unclear using one of the IEEE-754 encodings. The first set of points corresponds to using 2 and 5 bits to encode $e$ and $m$ whilst the second set of points corresponds to a 3 and 4 bit encoding. This allows us to see the trade off between the precision and range of real values represented.

-\begin{align*}
-       x &= (-1)^{s} \times m \times B^{e}
-\end{align*}
+\begin{figure}[H]
+       \centering
+       \includegraphics[width=0.8\textwidth]{figures/minifloat.pdf} \\
+       \includegraphics[width=0.8\textwidth]{figures/minifloat_diff.pdf}
+       \caption{The mapping of 8 bit floats to reals}
+\end{figure}
+
+\subsection{Floating Point Operations}

-$B = 2$, although IEEE also defines decimal representations for $B = 10$ --- these are useful in financial software\cite{ieee2008-754}.
+Floating point operations can in principle be performed using integer operations, but specialised Floating Point Units (FPUs) are an almost universal component of modern processors\cite{citationneeded}. The improvement of FPUs remains highly active in several areas including: efficiency\cite{seidel2001onthe}; accuracy of operations\cite{dieter2007lowcost}; and even the adaptation of algorithms originally used in software for reducing the overal error of a sequence of operations\cite{kadric2013accurate}. In this section we will consider the algorithms for floating point operations without focusing on the hardware implementation of these algorithms.

-\rephrase{Aside: Are decimal representations for a document format eg: CAD also useful because you can then use metric coordinate systems?}

-\subsubsection{Precision}
+\subsection{Some sort of Example(s) or Floating Point Mayhem}

-The floats map an infinite set of real numbers onto a discrete set of representations.
+\rephrase{Eg: $f(x) = |x|$ calculated from sqrt and squaring}

-\rephrase{Figure: 8 bit minifloats'' (all 255 of them) clearly showing the precision vs range'' issue}
+\rephrase{Eg: Massive rounding errors from calculatepi}

-The most a result can be rounded in conversion to a floating point number is the units in last place; $m_{N} \times B^{e}$.
+\rephrase{Eg: Actual graphics things :S}

-\rephrase{Even though that paper that claims double is the best you will ever need because the error can be as much as the size of a bacterium relative to the distance to the moon}\cite{} \rephrase{there are many cases where increased number of bits will not save you}.\cite{HFP}

-\subsection{Examples of Precision Related Errors in Floating Point Arithmetic}
+\subsection{Limitations Imposed By Graphics APIs and/or GPUs}

-\subsection{Relate This to the Sorts of Maths Done By Document Formats}
+Traditionally algorithms for drawing vector graphics are performed on the CPU; the image is rasterised and then sent to the GPU for rendering\cite{}. Recently there has been a great deal of literature relating to implementation of algorithms such as bezier curve rendering\cite{} or shading\cite{} on the GPU. As it seems the trend is to move towards GPU

-\subsection{Techniques for Arbitrary Precision Arithmetic}
+\rephrase{6. Here are ways GPU might not be IEEE-754 --- This goes *somewhere* in here but not sure yet}

\begin{itemize}
-       \item Fast2SUM for summation (and multiplication).
-       \item Guard digits.
-       \item Other techniques
-       \item Hardware techniques that improve speed (which may be beneficial because you can get away with higher precision in hardware)
-       \item Anything you can do in hardware you can do in software but it will be slower and have more segmentation faults
+       \item Internal representations are GPU dependent and may not match IEEE\cite{hillesland2004paranoia}
+       \item OpenGL standards specify: binary16, binary32, binary64
+       \item OpenVG aims to become a standard API for SVG viewers but the API only uses binary32 and hardware implementations may use less than this internally\cite{rice2008openvg}
+       \item It seems that IEEE has not been entirely successful; although all modern CPUs and GPUs are able to read and write IEEE floating point types, many do not conform to the IEEE standard in how they represent floating point numbers internally.
+       \item \rephrase{Blog post alert} \url{https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/}
\end{itemize}

-\subsection{Alternate Number Representations}

-\rephrase{They exist\cite{HFP}}.

+\rephrase{7. Sod all that, let's just use an arbitrary precision library (AND THUS WE FINALLY GET TO THE POINT)}
+
+\subsection{Arbitrary Precision Floating Point Numbers}
+
+An arbitrary precision floating point number simply uses extra bits to store extra precision. Do it all using MFPR\cite{fousse2007mpfr}, she'll be right.
+
+\rephrase{8. Here is a brilliant summary of sections 7- above}
+
+Dear reader, thankyou for your persistance in reading this mangled excuse for a Literature Review.
+Hopefully we have brought together the radically different areas of interest together in some sort of coherant fashion.
+In the next chapter we will talk about how we have succeeded in rendering a rectangle. It will be fun. I am looking forward to it.
+
+\rephrase{Oh dear this is not going well} UCC git Repository :: git.ucc.asn.au