Small changes, big git commit message

In the imaginary world in which I have completed the Literature Review by now, it goes like this:

0. Here is a brilliant summary of sections 1+ below
1. Here are the fundamentals of graphics (raster and vector, rendering)
2. Here are the ways documents are structured (programming language or varient, DOM, DOM dynamically modified by programming language)
3. Here are ways document standards specify precision
4. Here is IEEE-754 which is what these standards use
5. Here are limitations of IEEE-754 floating point numbers on compatible hardware
6. Here are ways GPU based techniques that are gaining popularity might not be IEEE-754
7. Sod all that, let's just use an arbitrary precision library
8. Here is a brilliant summary of sections 7- above

All this will fit within the page limit whilst still being relevant and containing references
I'm sure must exist but I haven't bothered/had time to locate yet.

That git commit message is probably more useful than anything I've actually written in the report today :S

---

On the third day (if it was indeed still the third day), the author could not think of an exciting encounter for the skeleton, so it rested

diff --git a/chapters/Background.tex b/chapters/Background.tex
index 700a8b9..4bedb57 100644 (file)
--- a/chapters/Background.tex
+++ b/chapters/Background.tex
@@ -145,6 +145,7 @@ We don't really care about other things (ie: Colour gradients etc) in this repor
        \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 CSS style sheets represent more complicated styling on objects in the DOM
 \end{itemize}
 
 \subsection{Blurring the Line --- Javascript}
@@ -167,35 +168,39 @@ We don't really care about other things (ie: Colour gradients etc) in this repor
        \end{itemize}
 \end{itemize}
 
+\subsection{Why do we still use static PDFs}
 
+Despite their limitations, we still use static, boring old PDFs. Particularly in scientific communication.
+\begin{itemize}
+       \item They are portable; you can write an amazing document in Mathematica/Matlab but it 
+       \item Scientific journals would need to adapt to other formats and this is not worth the effort
+       \item No network connection is required to view a PDF (although DRM might change this?)
+       \item All rescources are stored in a single file; a website is stored accross many seperate files (call this a ``distributed'' document format?)
+       \item You can create PDFs easily using desktop processing WYSIWYG editors; WYSIWYG editors for web based documents are worthless due to the more complex content
+       \item Until Javascript becomes part of the PDF standard, including Javascript in PDF documents will not become widespread
+       \item Once you complicate a PDF by adding Javascript, it becomes more complicated to create; it is simply easier to use a series of static figures than to embed a shader in your document. Even for people that know WebGL.
+\end{itemize}
 
 
-\section{Precision Limitations of Modern Documents}
+\section{Precision in Modern Document Formats}
 
 \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}.
 
-\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}
 
 
-\subsection{Limitations Imposed By Graphics APIs and/or GPUs}
-
-It's not really the standard's fault (although they could specify double); they specify IEEE because underlying hardware must use IEEE.
-
 \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}
+       \item Implementations of PostScript and PDF must by definition restrict themselves to IEEE binary32 ``single precision''\footnote{The original IEEE-754 defined single, double and extended precisions; in the revision these were renamed to binary32, binary64 and binary128 to explicitly state the base and number of bits}
+ 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}
+       \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}
 \end{itemize}
 
-\subsection{Limitations Imposed By CPU}
-
-Even if we don't use the GPU, CPU's are restricted in their representation of floating point numbers by the IEEE standard.
-
-\rephrase{AND THUS WE FINALLY GET TO THE POINT}
+The use of IEEE binary32 floats in the PostScript and PDF standards is not surprising if we consider that these documents are oriented towards representing static pages. They don't actually need higher precision to do this; 32 bits is more than sufficient for A4 paper.
 
 \section{Representation of Numbers}
 
@@ -225,6 +230,28 @@ The most a result can be rounded in conversion to a floating point number is the
 
 \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{Limitations Imposed By CPU}
+
+CPU's are restricted in their representation of floating point numbers by the IEEE standard.
+
+
+
+\subsection{Limitations Imposed By Graphics APIs and/or GPUs}
+
+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 
+
+\begin{itemize}
+       \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. 
+\end{itemize}
+
+
+
+\rephrase{AND THUS WE FINALLY GET TO THE POINT}
+
+
 \subsection{Examples of Precision Related Errors in Floating Point Arithmetic}
 
 \subsection{Relate This to the Sorts of Maths Done By Document Formats}

diff --git a/chapters/Introduction.tex b/chapters/Introduction.tex
index 31f8cda..6383224 100644 (file)
--- a/chapters/Introduction.tex
+++ b/chapters/Introduction.tex
@@ -7,7 +7,7 @@ Early electronic document formats such as PostScript were motivated by a need to
 
 The emergence of the internet, web browsers, XML/HTML, JavaScript and related technologies has seen a revolution in the ways in which information can be presented digitally, and the PDF standard itself has begun to move beyond static text and figures\cite{hayes2012pixels, barnes2013embedding}. However, the popular document formats are still designed with the intention of showing information at either a single, fixed level of detail, or a small range of levels.
 
-As most digital display devices are smaller than physical paper medium, all useful viewers are able to ``zoom'' to a subset of the document. Vector graphics formats including PostScript and PDF support rasterisation at different zoom levels\cite{plrm, pdfref17}, but the use of fixed precision floating point numbers causes problems due to imprecision either far from the origin, or at a high level of detail\cite{goldberg91whatevery, goldberg1992thedesign}.
+As most digital display devices are smaller than physical paper medium, all useful viewers are able to ``zoom'' to a subset of the document. Vector graphics formats including PostScript and PDF support rasterisation at different zoom levels\cite{plrm, pdfref17}, but the use of fixed precision floating point numbers causes problems due to imprecision either far from the origin, or at a high level of detail\cite{goldberg1991whatevery, goldberg1992thedesign}.
 
 We are now seeing a widespread use of mobile computing devices with touch screens, where the display size is typically much smaller than paper pages and traditional computer monitors; it seems that there is much to be gained by breaking free of the restricted precision of traditional document formats. 
 
@@ -34,7 +34,7 @@ At this stage we have identified two possible areas for individual research:
        We plan to investigate the representation of real values to a high or arbitary degree of precision. Such representations would allow for a document to be implemented
        using a single global coordinate system. However, we would expect a decrease in performance with increased complexity of the data structure used to represent a real value. \rephrase{Both software and hardware techniques will be explored.} We will also consider the limitations imposed by performing calculations on the GPU or CPU.
 
-       Starting points for research in this area are Priest's 1991 paper, ``Algorithms for Arbitrary Precision Floating Point Arithmetic''\cite{priest1991algorithms}, and Goldberg's 1992 paper ``The design of floating point data types''\cite{goldberg1992thedesign}. \rephrase{A more recent and comprehensive text book, ``Handbook of Floating Point Arithmetic''\cite{hfpa}, published in 2010, has also been identified as highly relevant.}
+       Starting points for research in this area are Priest's 1991 paper, ``Algorithms for Arbitrary Precision Floating Point Arithmetic''\cite{priest1991algorithms}, and Goldberg's 1992 paper ``The design of floating point data types''\cite{goldberg1992thedesign}. \rephrase{A more recent and comprehensive text book, ``Handbook of Floating Point Arithmetic''\cite{HFP}, published in 2010, has also been identified as highly relevant.}
 
        \item {\bf Local coordinate systems} --- David Gow \cite{proposalGow}
        

diff --git a/thesis.pdf b/thesis.pdf
index 1bb98b1..e5afcca 100644 (file)
Binary files a/thesis.pdf and b/thesis.pdf differ