X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=LitReviewDavid.tex;h=a8947e81f22fde0379904455a9611aeeefc4a6b3;hp=532017b56a2d794b46fe894154fb0af057cd7cf8;hb=2ec4f0eb657af1dc4314b1ec99216d7c20595229;hpb=3195edda12155345b3d0376f97a34e0a3a0ba8ad;ds=sidebyside

diff --git a/LitReviewDavid.tex b/LitReviewDavid.tex
index 532017b..a8947e8 100644
--- a/LitReviewDavid.tex
+++ b/LitReviewDavid.tex
@@ -3,6 +3,7 @@
 \usepackage{hyperref}
 \usepackage{graphicx}
 \usepackage{amsmath}
+\usepackage{amssymb}
 
 %opening
 \title{Literature Review}
@@ -42,7 +43,7 @@ a turing complete document language with instructions which emit shapes to be di
 immediately, as in PostScript, or stored in another file, such as with \TeX or \LaTeX, which emit a \texttt{DVI} file. Most other
 forms of document use a \emph{Document Object Model}, being a list or tree of objects to be rendered. \texttt{DVI}, \texttt{PDF},
 \texttt{HTML}\footnote{Some of these formats --- most notably \texttt{HTML} --- implement a scripting lanugage such as JavaScript,
-which permit the DOM to be modified while the document is being viewed.} and SVG. Of these, only \texttt{HTML} and \TeX typically
+which permit the DOM to be modified while the document is being viewed.} and SVG\cite{svg2011-1.1}. Of these, only \texttt{HTML} and \TeX typically
 store documents in pre-layout stages, whereas even turing complete document formats such as PostScript typically encode documents
 which already have their elements placed.
 
@@ -59,7 +60,7 @@ and \emph{vector} graphics, defined by mathematical descriptions of objects. Bit
 and are match how cameras, printers and monitors work. However, bitmap devices do not handle zooming beyond their
 ``native'' resolution --- the resolution where one document pixel maps to one display pixel ---, exhibiting an artefact
 called pixelation where the pixel structure becomes evident. Attempts to use interpolation to hide this effect are
-never entirely successful, and sharp edges, such as those found in text and diagrams, are particularly effected.
+never entirely successful, and sharp edges, such as those found in text and diagrams, are particularly affected.
 
 \begin{figure}[h]
 	\centering \includegraphics[width=0.8\linewidth]{figures/vectorraster_example}
@@ -96,7 +97,7 @@ the Cairo\cite{worth2003xr} library, based around the PostScript/PDF rendering m
 renderer by nVidia\cite{kilgard2012gpu} as an OpenGL extension\cite{kilgard300programming}.
 
 
-\section{Floating-Point Precision}
+\section{Numeric formats}
 
 On modern computer architectures, there are two basic number formats supported:
 fixed-width integers and \emph{floating-point} numbers. Typically, computers
@@ -135,12 +136,27 @@ precision than numbers close to zero. This can present problems in documents whe
 on objects far from the origin.
 
 IEEE floating-point has some interesting features as well, including values for negative zero,
-positive and negative infinity and the ``Not a Number'' (NaN) value. Indeed, with these values,
+positive and negative infinity, the ``Not a Number'' (NaN) value and \emph{denormal} values, which
+trade precision for range when dealing with very small numbers. Indeed, with these values,
 IEEE 754 floating-point equality does not form an equivalence relation, which can cause issues
 when not considered carefully.\cite{goldberg1991whatevery}
 
-Arb. precision exists
+There also exist formats for storing numbers with arbitrary precising and/or range.
+Some programming languages support ``big integer''\cite{java_bigint} types which can
+represent any integer that can fit in the system's memory. Similarly, there are
+arbitrary-precision floating-point data types\cite{java_bigdecimal}\cite{boost_multiprecision}
+which can represent any number of the form
+\begin{equation}
+	\frac{n}{2^d} \; \; \; \; n,d \in \mathbb{Z} % This spacing is horrible, and I should be ashamed.
+\end{equation}
+These types are typically built from several native data types such as integers and floats,
+paired with custom routines implementing arithmetic primitives.\cite{priest1991algorithms}
+These, therefore, are likely slower than the native types they are built on.
+
 
+While traditionally, GPUs have supported some approximation of IEEE 754's 32-bit floats,
+modern graphics processors also support 16-bit\cite{nv_half_float} and 64-bit\cite{arb_gpu_shader_fp64}
+IEEE floats. 
 Higher precision numeric types can be implemented or used on the GPU, but are
 slow.
 \cite{emmart2010high}