Andrew Garrard

Alternative versions: Non-annotated | Word document | Annotated Word document | PostScript | PDF (Acrobat)

Curriculum Vitae

Name:

Andrew William Garrard

Address:

Available on request.

E-mail:

Date of Birth:

20^th February 1974

Education (since age 11)

King's College, London

September 2000

September 2001

Downing College, Cambridge

October 1992

July 1995

King Edward VI's School, Norwich

September 1985

July 1992

Examination results and qualifications

Degree results:

MSc

Distinction

2001

Graduated BA (hons) Computer Science 1995 / MA 1999:

Part II Computer Science Tripos

3^rd

1995

Part IB Computer Science Tripos

2:2

1994

Part IA Computer Science Tripos

2:2

1993

S-levels:

Physics

1992

A-levels:

Physics

1992

Chemistry

1992

Mathematics

1992

Further Mathematics

1992

A.E.B. Basic Test:

Electronics

Distinction

1991

Computer Awareness

Distinction

1991

G.C.S.E.:

1991

1990

1990

1990

Projects:

MSc: A program conditioner (a program comprehension tool)
BA: A simple compiler with a pre-emptive run-time environment

MSc course component options

`Data structures and their implementation in C++', `Algorithm design and analysis', `Geometric algorithms and their applications', `Scientific parallel and distributed computing', `Parallel algorithms', `Text searching and processing', `Advanced research topics' and `Cryptography and information security'

I also attended, but was not examined on:

`Numerical analysis', `Multimedia compression methods and systems', `Group project' and `Algorithmic issues in the world wide web'.

References:

Available on request.

Previous employment

Software Engineer, Advanced Rendering Technology Ltd, July 1996-September 2000
	Writing a shading language compiler for a custom architecture, writing shaders in assembler, test suite development, implementing a reference software version of the architecture, hardware assembly, working on a chip simulator, debugging and developing a revision of the ASIC in VHDL, plug-in development for Windows NT applications
Junior Programmer, Perihelion Distributed Software , August 1995-July 1996
	Testing the Helios-ARM embedded real-time operating system, working on the Pardi distributed computing library, developing a multi-platform user interface with Zinc, developing an embedded graphics library
Programmer, LOOKSystems, August-September 1994
	Implementing routines for printer drivers and font manipulation (on the Acorn platform)
Programmer, Norwich Computer Services, June-August 1994
	Designing and implementing the Archive magazine bulletin-board system and supporting software

Computing skills

Operating systems:

Substantial experience developing under (x86/Alpha) Linux, Solaris, NetBSD (RiscBSD) and RISC OS.

Some exposure to developing under Windows NT (Visual C++), DOS, AIX, DEC UNIX, SunOS, IRIX, AmigaDOS, BeOS, MVS and Helios-ARM.

Languages:

Fluent in C++, ISO C, ARM assembler, RenderMan shading language, (BBC) BASIC, UNIX shells (bash), PERL 4, (X)Emacs LISP and HTML.

Varying limited experience in OpenGL, ADA95/83, Modula-3, FORTRAN 77, ML, Logo, PERL 5, Java, FORTH, VHDL, NESL, tcl, and assembly language for Alpha, x86, 6805, 68K and MIPS.

Also substantial development with Flex/Bison, CVS/RCS, Expect/DejaGNU and PVM.

Positions of responsibility

Marking undergraduate coursework at King's College London (2001):

`Operating systems' (second year),
`Computer graphics systems' (second year),
`Human computer interaction' (first year - including lab session supervision),
`Systems architecture & assembly language programming' (first year)

Publicity Officer to the Cambridge University Tiddlywinks Club (1998-2001) and to the English Tiddlywinks Association (1998-2001, 2002-)

Head of Computer Society, Norwich School, 1992

Head of Robotics Society, Norwich School, 1990-1992

Member of Computer Club Committee, Norwich School, 1990-1992

Secretary, Young Enterprise company, 1991

Non-academic achievements

Young Enterprise Scheme (Examination passed: Merit 1991)

Clean UK driving licence, normal road vehicles (Test passed: July 1991)

Annotations

Because the above CV is necessarily brief, some sections may be prone to misinterpretation. The following annotations are intended to fill in missing details and remedy any misconceptions which may arise.

Email contact details: I prefer to be contacted at this hotmail address; I have a number of other addresses used for specific purposes. On principle, I will not purchase any product from a company which has contacted me as part of an unsolicited bulk emailing campaign, and I delete emails which appear as such without reading them - I politely (and optimistically) request that any such company refrain from contacting me or including me on any automated mailing lists. As such, I would also be grateful if those reading this document would refrain from placing my email address anywhere where it can be publicy read, and picked up by such a company, without my views on the subject being made known to them. If you have a legitimate reason for contacting me, I encourage you to send the message from a valid email address, and to provide a meaningful subject line, so as to avoid accidental deletions - or to use my contact form. Please see also my home page.
Education before age 11: Tradition has it that you only list education since age 11 on a CV. For completeness, though, I went to SS Peter and Paul Voluntary Aided Primary school in Eye (a.k.a. Eye Primary School) from age 4 to 11.
On my MSc results: A PostScript transcript of my results is available here. Unlike my undergraduate course I had learnt the benefits of doing some work here, so my results are reasonably satisfactory. Some of the examiners had a slightly higher expectation for exact transcription of a given code fragment (over proof of comprehension of its functionality) than I would like - a view shared by some of my fellow students - or my results may have been more uniformly high. Still, I don't feel in a position to complain. I should state that my borderline exam (text searching and processing) was due primarily to bad planning. I was involved in some undergraduate coursework marking, which took up a lot of my time near the start of my exams. This was partly due to an unexpected additional coursework, for which some of my fellow markers was not available; retrospectively I should have said "no" rather than feeling obliged to help out. Anyway, finding I had little time to revise my cryptography, I rushed the revision, and only found out after that exam that I had less recollection of the text searching course than I had believed, hence producing my problem. I'm chalking that one up to experience.
On why I got a third: If anyone cares about my academic record, this is going to be a question. And the answer is simple - I didn't do enough work until it was too late. That's not to say that I wasn't learning anything, just that I was spending too much time on interesting problems (mostly computer related) rather than doing work. I'd like to think that I've learn my lesson, albeit too late. Getting a third is not to be recommended, but I wish I'd done it earlier so that I'd had a bigger impetus to pull my socks up before the end of the course. I managed to make excuses for my performance for the first two years (that I wasn't a physicist, and that I'd spent so much time typing in my second year that I couldn't write fast enough - both are true, but not nearly so much of an issue as the amount of work I wasn't doing). I'd like to think that I've since managed to cover most of the tripos in my self-education, but I'd have far preferred to have learnt it when I was supposed to.
Computer Studies GCSE: This is separate because Norwich School didn't actually offer this qualification - I had to arrange it separately.
A-grade GCSEs: Namely Maths, Nuffield combined science (two subjects), French and English language.
B-grade GCSEs: Namely English Literature, Latin and Classical civilisation.
C-grade GCSEs: Namely Art (bit too much time generating computer graphics, which sadly put me out of practice at drawing before the exam came up).
My MSc project: a program conditioner: This project is on-line in my software page. It's not really production quality code, but it might be useful (I intend to tidy it up in the near future, and possibly get a paper out of it). This project, written in C++ and using flex and bison, used some of the knowledge of compilers I'd picked up in ART (and some interest that I had from beforehand, including my undergraduate days).
On a similar theme, I've since been doing some work for a PhD student at KCL on satisfiability checkers for S5, propositional temporal logic, and first order temporal logic. Between various bits of graphical hackery, that is.
My undergraduate project: a simple compiler with a pre-emptive run-time environment: This was actually intended to be a starting step towards my ongoing project (with some friends) of getting an operating system that I'd actually like to use. What I ended up doing was writing a compiler (for a language that was C-like and a little PERL-like) in BBC BASIC mainly because I wasn't yet comfortable with C, and didn't want to use the ARM linking system. The resulting ARM binary ran on an Acorn RiscPC, using it's own pre-emptive scheduler, running under RISC OS's interrupt handling. Sadly Martin Richards's advanced compiler course came too late in the tripos to help me, and what I learnt most of all is not to reinvent the wheel - or at least to do it properly. I still have an interest in operating systems, though.
MSc topics I attended, but on which I was not examined: The MSc course required that I undertake a fixed number of courses; however, since I was there to learn, I attended a few extras (and did the coursework for them). Of the group project (which was the design of a web site) I was involved in some design discussions, but not the implementation (other than in an advisory role). Retrospectively I should have taken the data compression exam rather than text searching - of which I was less confident, and left myself too little revision time while trying to get some marking done - but I decided that a challenge was the way forward.
Writing a shading language compiler for ART: A little background: Advanced Rendering Technology make a RenderMan compatible renderer (see Pixar's web site for what RenderMan is), which uses a hardware-accelerated ray-tracer to generate images from a a RenderMan scene description. Part of this is a compiler which takes shading language and produces binary code for the custom hardware, including some code transformations specific to the architecture. I actually had three goes at this, with various complexity and functionality. Others later took over the project, with more experience with compilers, and slightly less ambitious plans for what code would be acceptable (which enabled faster results than I was managing). My compilers were written in C++.
Writing shaders in assembler for ART: In addition to the shading language compiler, ART had some custom shaders provided for use with their 3D Studio Max plug-in (and later the Maya one). For efficiency, these shaders were hard-coded in assembler, rather than in RenderMan Shading Language. Hence I have a pretty good understanding of a number of common texturing algorithms. As a consequence I had the dubious distinction of having the largest number of lines of code in ART's first release, although since they were in assembler (which was closely related to ARM code) it's not really a fair comparison.
Test suite development for ART: As ART's product developed, they required an automated test suite. This I was tasked with, and coded in Expect and Tcl/Tk using DejaGNU; it was a "run a set of tests and compare the results for speed and for a difference threshold" problem, so there were a few auxiliary utilities too.
A reference software version of ART's architecture: The ART hardware ran in an embedded environment; I was in a team of two who re-implemented the renderer matching the API of the embedded version, with a view to allowing the research team to try out some relatively major changes in functionality and see in detail what was happening to the data structures involved. Hence I'm pretty up on handling data structures for ray-tracing, although the ART architecture is patented.
Hardware assembly for ART: By this I mean a screwdriver, not a C to VHDL conversion. Shortly before I left (so I wasn't in a long-term project) ART was preparing to ship a new product revision; I helped put together some products to ship, before the external supplier was up to speed. This means I'm competent at assembling computers (although I'd done this for myself a few times before) and securing cables and internal components for shipping (which is a bit keener than I've been with my own hardware).
A chip simulator for ART: While ART has a VHDL variant of the behaviour of their custom chips, the simulator of this level of detail runs very slowly. I worked on updating a C-based simulator of the functionality of the chip (which interpreted binaries in simulated memory) to cross-check against the VHDL code, and which could be used by the renderer development team to test their code when chips were not available - and when the details of chip behaviour were to be examined. This taught me a little about how to emulate hardware, and a bit about how the hardware itself works.
Debugging and developing a revision of ART's ASIC in VHDL: While not actually part of the hardware team, after the aforementioned chip simulator I was tasked with reviewing some of the functionality of the custom ASIC, which was being revised. This involved examining the VHDL from which the ASIC was generated, and making some corrections to it. This gave me a grounding in VHDL, upon which I continue to expand.
Plug-in development for ART: ART's hardware renderer ships with plug-ins for 3D Studio Max and Maya (both, at the time I worked on them, under Windows NT). I was involved in some of the development of these plug-ins, in Visual C++, and hence know the internal workings of these products in some detail.
Testing Helios-ARM for Perihelion Distributed Software: As I joined Perihelion (after graduating with my B.A.), Helios-ARM was being developed. I was tasked with producing some simple tests, and re-running them as updates were made. These were written in C, and spawned from the shell - and manually examined for success.
Working on Pardi for Perihelion Distributed Software: Perihelion were developing a PVM and MPI-compatible library based on the (Transputer) Helios IPC protocol. I was tasked with some early testing and development for it, giving me a little experience in the development of parallel applications under PVM.
Developing a multi-platform GUI for Perihelion Distributed Software: This was intended to be a front-end to Pardi - although only preliminary work was done, mainly due to the fragility of Zinc (at the time) on its various platforms. Only a subset of the available features of Zinc worked on any given platform, and the subset varied according to platform. I did learn a bit about GUI programming, though.
Developing a graphics library for Helios-ARM for Perihelion: Shortly before I left Perihelion, I began development on an ARM-based graphics library for use in Helios. This was developed in parallel in C and ARM-code, and involved a fair bit of low-level optimisation.
Developing for LOOKSystems: I developed most of a printer driver (for a dye-sublimation printer under RISC OS), giving me a bit of an insight into the working of printer drivers and colour correction, mostly in ARM code. I also helped code some curve simplification code in BASIC and ARM code, for font translation. I was only employed there for a couple of weeks during a summer vacation, though.
Developing a BBS at Norwich Computer Services: Before the internet took off, Norwich Computer Services (who produced Archive magazine for Acorn computers) were running a bulletin-board; this I implemented, using some Acorn BBS software. One achievement was an implementation of minesweeper, using the bulletin-board scripting language - which had no array support and no loop constructs!
Substantial experience at developing under...: To clarify, this means I have developed hundreds of programs under these environments - mostly using gcc/g++ except for RISC OS, where the Acorn C Desktop Development Environment and BBC BASIC or its internal assembler were used. Incidentally, I frequently use several variants of Windows and Mac OS, but do not develop code under them.
Some exposure to developing under...: To clarify, this means I've developed a few programs under these environments. Although these programs are generally not very complex, I do have some understanding of the unique features of each O/S.
Languages: Fluent in...: By this I mean that I am happiest in these languages, and have written at least tens if not hundreds of programs (or scripts, or pages) in each. I almost never need to refer to a manual, and I could write a compiler or interpreter, given time, which would process code from any of these languages and produce a good approximation to appropriate output without reference to a language specification.
Languages: Varying limited experience in...: This means I'm at least happy reading code in these language, and have written some code in each. I understand the "way the language works", and would be able to produce simple code in them with occasional reference to a manual of some sort. I'm actively revising my PERL, Java and VHDL knowledge, along with several assemblers.
Driving licence: I hold a clean UK driving licence, and I am currently preparing to take a RoSPA advanced driving test.