Automatic commit of irc logs
[ipdf/documents.git] / LitReviewDavid.tex
index 532017b..a8947e8 100644 (file)
@@ -3,6 +3,7 @@
 \usepackage{hyperref}
 \usepackage{graphicx}
 \usepackage{amsmath}
 \usepackage{hyperref}
 \usepackage{graphicx}
 \usepackage{amsmath}
+\usepackage{amssymb}
 
 %opening
 \title{Literature Review}
 
 %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,
 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.
 
 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
 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}
 
 \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}.
 
 
 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
 
 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,
 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}
 
 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}
 Higher precision numeric types can be implemented or used on the GPU, but are
 slow.
 \cite{emmart2010high}

UCC git Repository :: git.ucc.asn.au