+++ /dev/null
-\chapter{Approach}
-
-Repeat the plans as outlined in the project proposals\cite{proposalMoore,proposalGow}\footnote{Sam Moore's proposal has not been assessed but was submitted jointly with David Gow's to CSSE}.
-
-Explain changes from the original proposal.
-\begin{itemize}
- \item No mention of hardware considerations in proposal, but Sam Moore's topic ``how can we increase the precision of real number representations'' was in the original scope, and can't be answered without considering hardware.
-\end{itemize}
-
--- /dev/null
+\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.}
+
+\rephrase{TODO: Decide exactly what figures to make, then go make them; so far I have some ideas for a few about Floating Point operations, but none about the other stuff}.
+
+\rephrase{TODO: Actually (re)write this entire chapter}.
+\rephrase{????: Do I really want to make this go down to} \verb/\subsubsection/
+
+A paper by paper summary of the literature is also available at: \\ \url{http://szmoore.net/ipdf/documents/LiteratureNotes.pdf}.
+
+
+\rephrase{TODO: Actually make that readable or just remove the link}.
+
+\section{Document Formats}
+
+\subsection{History}
+
+Since mankind climbed down from the trees... \rephrase{plagiarism alert!}
+
+\subsection{Vector Graphics vs Raster Graphics}
+
+Raster Graphics: Stores the exact pixels as they would appear on a device. Causes obvious issues with scaling.
+Vector Graphics: Stores relative position of primitives - scales better. BUT still can't scale forever.
+
+\rephrase{Figures: Raster and Vector graphics at different scales}
+
+\subsection{Document Format Categories}
+
+Main reference: Pixels or Perish\cite{hayes2012pixels}
+
+\begin{enumerate}
+ \item DOM - eg: HTML/XMLish - defined in terms of elements that can contain other elements
+ \item Programming Language - eg: PostScript - programmer (or program) produces a program that is interpreted
+ \item Combination - eg: Javascript with HTML/XML - Program is interpreted that modifies the DOM.
+ \begin{itemize}
+ \item The lines are becomming increasingly blurred between 1. and 2.
+ \item In the case of Javascript/HTML, a special DOM element \verb/<canvas>/ allows even lower level manipulation of graphics.
+ \end{itemize}
+\end{enumerate}
+
+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}
+
+\subsection{Modern Graphics Formats}
+
+PostScript: Not actually widely used now, but PDF is basically the same thing.
+PDF: A way for adobe to make money
+SVG: Based on the DOM model, vector format
+BMP,PNG,GIF: Are these even worth mentioning?
+
+HTML: With the evolution of JavaScript and CSS, this has actually become a competitive document format; it can display much more complex dynamic content than eg: PDF.
+
+Web based documents still suffer from precision issues (JavaScript is notorious for its representation of everything, even integers, as floats, so you get rounding errors even with integer maths), and it also has other limitations (requires reasonably skilled programmer to create Javascript and/or a disgusting GUI tool that auto generates 10000 lines to display a button (I have seen one of these)). \rephrase{Hate on javascript a bit less maybe.}
+
+\subsection{Precision Limitations}
+
+\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 such as PDF and PostScript is the use of floating point numbers to represent the coordinates of vertex positions. In particular, 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}.
+
+Whilst David Gow will be focusing on how to structure a document format so as to avoid or reduce these limitations\cite{proposalGow}, the focus of our own research will be \rephrase{NUMBERS}.
+
+\subsection{Floating Point Number Representations}
+
+\begin{align*}
+ x &= (-1)^{s} \times m \times B^{e}
+\end{align*}
+
+$B = 2$, although IEEE also defines decimal representations for $B = 10$ --- these are useful in financial software\cite{ieee2008-754}.
+
+\rephrase{Aside: Are decimal representations for a document format eg: CAD also useful because you can then use metric coordinate systems?}
+
+\subsubsection{Precision}
+
+The floats map an infinite set of real numbers onto a discrete set of representations.
+
+\rephrase{Figure: 8 bit ``minifloats'' (all 255 of them) clearly showing the ``precision vs range'' issue}
+
+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{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{Alternate Number Representations}
+
+\rephrase{They exist\cite{HFP}}.
+
+
+++ /dev/null
-\chapter{Physical Limitations on Precision}\label{BackgroundHardware}
-
-This chapter will focus on the physical limitations on precision due to hardware. It will describe the traditional approaches to working with real numbers and the current state of the art.
-
-NOTE: Depending on how much I get into the VHDL stuff, this chapter may seem less relevant to the actual research we are doing and it might be very short.
-However I think even if I do not actually do any hardware designs, a literature review about precision of numbers would not be complete if it only mentioned software algorithms.
-
-
-
-\section{Real Number Representations}
-
-This section will discuss representations of real numbers in hardware, including the trivial: fixed point, IEEE floating points, and anything else I find that is interesting.
-
-
-\section{Floating Point Units}
-
-This section will give an overview of FPUs, focusing on IEEE.
-
-\section{Graphical Processing Units}
-
-This section will discuss anything relevant we can find on GPUs, but will probably be very short.
-
+++ /dev/null
-\chapter{Virtual Representations of Real Numbers}\label{BackgroundSoftware}
-
-SoftFloat libraries (fixed precision)
-
-boost library for increased (but still fixed) precision.
-
-Algorithms for arbitrary precision?
-Mathematica uses arbitrary precision numbers. Will they have a reference or report on this anywhere?
-
\chapter{Conclusion}\label{Conclusion}
-We will have hopefully done the following:
-
-\begin{itemize}
- \item Demonstrated precision issues due to traditional (Select one or more of the following!)
- \begin{itemize}
- \item Physical representation of real numbers
- \item Algorithms
- \item Document formats
- \end{itemize}
- \item Demonstrated something better
- \item Written a less shitty report than this one.
-\end{itemize}
+This report has provided motivation for considering approaches to achieving an infinite level of zoom in a document.
+
+\section{Acheived Milestones}
+
+\section{Areas of further Research}
+
+\section{Witty Conclusion Goes Here}
+++ /dev/null
-\chapter{Implementation Notes}\label{Implementation}
-
-This will be the easiest and also least important chapter to write.
\chapter{Introduction}\label{Introduction}
-The introduction will be witty and engaging and a joy to read.
+\rephrase{Most of this chapter is copy pasted from the project proposal} \\
+ \url{http://szmoore.net/ipdf/documents/ProjectProposalSam.pdf}
-I hope.
+Early electronic document formats such as PostScript were motivated by a need to print documents onto a paper medium. In the PostScript standard, this lead to a model of the document as a program; a series of instructions to be executed by an interpreter which would result in ``ink'' being placed on ``pages'' of a fixed size\cite{plrm}. The ubiquitous Portable Document Format (PDF) standard provides many enhancements to PostScript taking into account desktop publishing requirements\cite{cheng2002portable}, but it is still fundamentally based on the same imaging model\cite{pdfref17}. This idea of a document as a static ``page'' has lead to limited precision in these and other traditional document formats.
-Points to address:
+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}.
+
+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.
+
+\section{Aim}
+
+In this project, we will explore the state of the art of current document formats including PDF, PostScript, SVG, HTML, and the limitations of each in terms of precision.
+We will consider designs for a document format allowing graphics primitives at an arbitrary level of zoom with no loss of detail. We will refer to such a document format as ``infinite precision''. A viewer and editor will be implemented as a proof of concept; we adopt a low level, ground up approach to designing this viewer so as to not become restricted by any single existing document format.
+
+\rephrase{New bit} \\
+It is necessary to clarify what we mean by ``infinite'' precision. We do not propose to be able to contain an infinite amount of information within a document. The goal is to be able to render a primitive at the same level of detail it is specified by a document format. For example, the precision of coordinates of primitives drawn in a graphical editor will always be limited by the resolution of the display on which they are drawn, but not by the viewer.
+
+There are many possible applications for documents in which precision is unlimited. Several areas of use include: visualisation of extremely large or infinite data sets; visualisation of high precision numerical computations; digital artwork; computer aided design; and maps.
+
+\section{Methods}
+
+Initial research and software development is being conducted in collaboration with David Gow\cite{proposalGow}. Once a simple testbed application has been developed, we will individually explore approaches for introducing arbitrary levels of precision; these approaches will be implemented as alternate versions of the same software. The focus will be on drawing simple primitives (lines, polygons, circles). However, if time permits we will explore adding more complicated primitives (font glyphs, bezier curves, embedded bitmaps).
+
+At this stage we have identified two possible areas for individual research:
+
+\begin{enumerate}
+
+ \item {\bf Arbitrary Precision real valued numbers} --- Sam Moore
+
+ 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.}
+
+ \item {\bf Local coordinate systems} --- David Gow \cite{proposalGow}
+
+ An alternative approach involves segmenting the document into different regions using fixed precision floats to define primitives within each region. A quadtree or similar data structure could be employed to identify and render those regions currently visible in the document viewer.\rephrase{Say more here?}
+
+\end{enumerate}
+\pagebreak
+We aim to compare these and any additional implementations considered using the following metrics:
\begin{enumerate}
- \item What this is.
- \item Why we should care
- \item Most recent development
- \item Do we really mean ``infinite''? (No. Sorry. We lied)
- \item Foundational papers. Historical notes.
+
+ \item {\bf Performance vs Number of Primitives}
+
+ As it is clearly desirable to include more objects in a document, this is a natural metric for the usefulness of an implementation.
+ We will compare the performance of rendering different implementations, using several ``standard'' test documents.
+
+ \item {\bf Performance vs Visible Primitives}
+
+ There will inevitably be an overhead to all primitives in the document, whether drawn or not.
+ As the structure of the document format and rendering algorithms may be designed independently, we will repeat the above tests considering only the number of visible primitives.
+
+
+ \item {\bf Performance vs Zoom Level}
+
+ We will also consider the performance of rendering at zoom levels that include primitives on both small and large scales, since these are the cases under which floating point precision causes problems in the PostScript and PDF standards.
+
+ \item {\bf Performance whilst translation and scaling}
+
+ Whilst changing the view, it is ideal that the document be re-rendered as efficiently as possible, to avoid disorienting and confusing the user.
+ We will therefore compare the speed of rendering as the standard documents are translated or scaled at a constant rate.
+
+ \item {\bf Artifacts and Limitations on Precision}
+
+ As we are unlikely to achieve truly ``infinite'' precision, qualitative comparisons of the accuracy of rendering under different implementations should be made.
+
\end{enumerate}
-See also: The Abstract.
-See also: The Conclusion.
+\section{Software and Hardware Requirements}
+
+Due to the relative immaturity and inconsistency of graphics drivers on mobile devices, our proof of concept will be developed for a conventional GNU/Linux desktop or laptop computer using OpenGL. However, the techniques explored could easily be extended to other platforms and libraries.
+
+
+\pagebreak
-The remainder of this report will be organised as follows: Chapters \ref{BackgroundHardware} and \ref{BackgroundSoftware} will discuss approaches to representation of numbers in both Hardware and Software respectively; Chapter \ref{Approach} will outline the approach [reword] considering <insert fuzzy list of faculty dependent requirements here (Safety, Ethics, Group Work Process, etc)>. Chapter/Appendices \ref{Implementation} will provide implementation notes. Chapter \ref{Results} will describe our results. Chapter \ref{Conclusion} will be the conclusion.
+\section{Timeline}
+Deadlines enforced by the faculty of Engineering Computing and Mathematics are \emph{italicised}.\footnote{David Gow is being assessed under the 2014 rules for a BEng (Software) Final Year Project, whilst the author is being assessed under the 2014 rules for a BEng (Mechatronics) Final Year Project; deadlines and requirements as shown in Gow's proposal\cite{proposalGow} may differ}.
+\begin{center}
+\begin{tabular}{l|p{0.5\textwidth}}
+ {\bf Date} & {\bf Milestone}\\
+ \hline
+ $17^{\text{th}}$ April & Draft Literature Review completed. \rephrase{This sort of didn't happen...}\\
+ \hline
+ $1^{\text{st}}$ May & Testbed Software (basic document format and viewer) completed and approaches for extending to allow infinite precision identified. \\
+ \hline
+ $26^{\text{th}}$ May & \emph{Progress Report and Revised Literature Review due.}\\
+ \hline
+ $9^{\text{th}}$ June & Demonstrations of limitations of floating point precision in the Testbed software. \\
+ $1^{\text{st}}$ July & At least one implementation of infinite precision for basic primitives (lines, polygons, curves) completed. Other implementations, advanced features, and areas for more detailed research identified. \\
+ \hline
+ $1^{\text{st}}$ August & Experiments and comparison of various infinite precision implementations completed. \\
+ \hline
+ $1^{\text{st}}$ September & Advanced features implemented and tested, work underway on Final Report. \\
+ \hline
+ TBA & \emph{Conference Abstract and Presentation due.} \\
+ \hline
+ $10^{\text{th}}$ October & \emph{Draft of Final Report due.} \\
+ \hline
+ $27^{\text{th}}$ October & \emph{Final Report due.}\\
+ \hline
+\end{tabular}
+\end{center}
-NOTE: Given that I don't actually need a full thesis, change from Chapters to Sections?
-NOTE2: Will treat as a full thesis but if it gets too big, submit a condensed version as the MCTX "report".
-NOTE3: In final version, put the Approach at the end and/or in appendices before the Implementation notes rather than the start (?)
--- /dev/null
+\chapter{Progress Report}\label{Progress Report}
+
+This chapter outlines the current state of our research in relation to the aims outlined in Chapter \ref{Introduction}.
+\rephrase{It will serve as an explanation for where the Figures in Chapter \ref{Background} came from. It will just be a short summary of the implementation details}.
+
+\section{Development of Testbed Software}
+
+We wrote a very simple OpenGL 1.1 program to experiment with, and then David Gow converted it to OpenGL 3.1 and I have no idea how it works anymore.
+
+\section{Design and Implementation of ``Tests''}
+\begin{itemize}
+ \item Compile by swapping out \verb/main()/ for a tester
+ \item There are tests for doing some of the things in Chapter \ref{Introduction} but most still aren't written yet.
+
+\end{itemize}
+
+\section{Floating Point Number Representations}
+
+\rephrase{I have\footnote{Ok... ``will have''} some figures that I would prefer to include in Chapter \ref{Background} when I am talking about the papers that inspired them.}
+\rephrase{This section will probably briefly talk about how they were created and just refer back to them}.
+
+\begin{itemize}
+ \item \verb/calculatepi.test/
+ \item \verb/typedef/ of \verb/Real/
+\end{itemize}
+
+\section{Virtual FPU}
+
+Techniques for dealing with FP numbers can be implemented in software (CPU) or on dedicated hardware (FPU). We are able to run FP arithmetic on arbitrary simulations of FPUs created using VHDL. \rephrase{Hopefully explore this a bit in Chapter \ref{Background}}.
+
+\section{Version Control}
+
+Git is a distributed version control system widely used in the development of open source software\cite{}. All rescources created for or used by this project have been placed in git repositories on several servers. The repositories are publically accessable at \url{http://git.ucc.asn.au}
+
+
+
+
-What we will be doing and why.
+\section*{Abstract}
-See also the Introduction.
-See also the Conclusion.
+At the fundamental level, a document is a means to convey information. The limitations on a digital document format therefore restrict the types and quality of information that can be communicated. Whilst modern document formats are now able to include increasingly complex dynamic content, they still suffer from early views of a document as a static page; to be viewed at a fixed scale and position. In this report, we focus on the limitations of modern document formats (including PDF, PostScript, SVG) with regards to the level of detail, or precision at which primatives can be drawn. We propose a research project to investigate whether it is possible to obtain an ``infinite precision'' document format, capable of including primitives created at an arbitrary level of zoom.
-\begin{itemize}
- \item Research into document formats is mostly focusing on embedding dynamic content in the document
- \item TODO: Desperately try to find research into increasing precision in documents
- \begin{itemize}
- \item I suspect the reason it is hard to find references saying ``We increased the precision you can get in this graphics format'' is because the real research is into ``how to get more precision out of a number'' and increasing the precision in a graphics format is just an application.
- \item Talk about why precision in itself is a good thing?
- \begin{itemize}
- \item Reduced error in computations
- \end{itemize}
- \item Somehow manage to link this to graphics formats.
- \begin{itemize}
- \item Increased precision means you can have more zoom, you can have more range
- \item This is useful because the view of a document as a sheet of paper is increasingly outdated
- \end{itemize}
- \item Precision in itself is necessary in order to address the document format issue.
- \end{itemize}
- \item In particular we are looking into increasing precision vs IEEE floats because:
- \begin{itemize}
- \item Such research is important in its own right; eg: Doing numerical calculations requires high accuracy results
- \end{itemize}
- \item
-\end{itemize}
-I guess what I am trying to say very badly is:
-
-We want to be able to do more things with documents.
-We are currently limited by the precision of floating point operations. This is a fundamental and physical limit on what can be done.
-
-Even things like postscript are already turing complete. All the fancy papers about putting dynamic content and javascript and things in documents
-are not addressing a physical limitation, merely one of convenience for the document creator.
-
-So it is worth looking into how we can reduce or eliminate the physical limitations on what can be done with a document due to floating point precision.
+\rephrase{Move to introduction? But it discusses the Introduction :S} \\
+In Chapter \ref{Introduction} we give an overview of the current state of the research in document formats, and the motivation for implementing ``infinite precision'' in a document format. We will outline our approach to research in collaboration with David Gow\cite{}. In Chapter \ref{Background} we provide more detailed background examining the literature related to rendering, interpreting, and creating document formats, as well as possible techniques for increased and possibly infinite precision. In Chapter \ref{Progress} gives the current state of our research and the progress towards the goals outlined in Chapter \ref{Introduction}. In Chapter \ref{Conclusion} we will conclude with a summary of our findings and goals.
+{\bf Keywords:} \emph{document formats, precision, floating point, graphics, OpenGL, VHDL, PostScript, PDF, bootstraps}
+\rephrase{TODO: Make document smaller; currently 16 pages with almost no content; limit is 20 with actual content}
\usepackage{amsmath, amsthm,amssymb}
\usepackage{mathrsfs}
\usepackage{hyperref}
-
\usepackage{epstopdf}
\usepackage{float}
-
-
+\usepackage{anyfontsize}
+\usepackage{mdframed}
+\usepackage[compact]{titlesec}
+\usepackage[table]{xcolor}
+%\titlespacing{\chapter}{0pt}{-50pt}{0pt}
+% spacing glue: how to read {12pt plus 4pt minus 2pt}
+% 12pt is what we would like the spacing to be
+% plus 4pt means that TeX can stretch it by at most 4pt
+% minus 2pt means that TeX can shrink it by at most 2pt
+%\titlespacing\section{0pt}{0pt plus 0pt minus 14pt}{0pt plus 0pt minus 14pt}
+%\titleformat{\chapter}
+%{\normalfont\LARGE\bfseries}{\thechapter.}{1em}{}
+
+%\usepackage[usenames,dvipsnames]{color}
+%\usepackage{listings} % For code snippets
+\definecolor{pink}{rgb}{1.0,0.5,0.5}
+\definecolor{darkgray}{rgb}{0.1,0.1,0.1}
+\definecolor{lightgray}{rgb}{0.95,0.95,0.95}
+\definecolor{gray}{rgb}{0.5,0.5,0.5}
+\definecolor{darkred}{rgb}{0.75,0,0}
+\definecolor{darkblue}{rgb}{0,0,0.35}
+\definecolor{green}{rgb}{0,0.70,0}
+\definecolor{black}{rgb}{0,0,0}
+%\lstset{language=Java}
+%\lstset{backgroundcolor=\color{darkgray}}
+%\lstset{numbers=left, numberstyle=\tiny, stepnumber=1, numbersep=5pt}
+%\lstset{keywordstyle=\color{darkred}\bfseries}
+%\lstset{commentstyle=\color{darkblue}}
+%\lstset{stringsyle=\color{red}}
+%\lstset{showstringspaces=false}
+%\lstset{basicstyle=\small}
+
+% keeps text within our margins
+%\sloppy
\newtheorem{theorem}{Theorem}[section]
\newtheorem{lemma}[theorem]{Lemma}
\newcommand{\phasor}[1]{\tilde{#1}} % make a phasor
\newcommand{\laplacian}[1]{\nabla^2 {#1}} % The laplacian operator
+\renewcommand{\url}[1]{$\langle$\href{#1}{\underline{\color{blue}{#1}}}$\rangle$}
+\newcommand{\rephrase}[1]{ \textcolor{red}{#1}}
%\usepackage{endfloat}
%\nomarkersintext
%---------------------------------------------------------
% Do the table of Contents and lists of figures and tables
%---------------------------------------------------------
-\tableofcontents
+\linespread{0.3}
+% Do we need these for a fresher guide?
+{\small\tableofcontents}
+%\listoffigures
\markboth{}{}
+\linespread{1.5}
\newpage
\pagenumbering{arabic}
%Include the chapters!
\include{chapters/Introduction}
-
-\include{chapters/BackgroundHardware}
-\include{chapters/BackgroundSoftware}
-
-\include{chapters/Approach} % This is chapter 2
-\include{chapters/Implementation}
-
-\include{chapters/Results} % etc.
-
+\include{chapters/Background}
+\include{chapters/Progress}
\include{chapters/Conclusion}
%\newpage
%---------------------------------------------------------
git.ucc.asn.au / ipdf / sam.git / commitdiff
UCC git Repository :: git.ucc.asn.au