Data Imprecision in Computational Geometry Typeset in LATEX
Total Page:16
File Type:pdf, Size:1020Kb
Data Imprecision in Computational Geometry Typeset in LATEX. Cover and figures designed using the Ipe extensible drawing editor. Printed by BOX Press, Oisterwijk, the Netherlands. www.proefschriftmaken.nl Copyright c 2009 Maarten Loffler.¨ All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of Maarten Loffler.¨ ISBN 978-90-8891-121-7 Data Imprecision in Computational Geometry Data-Imprecisie in de Computationele Meetkunde (met een samenvatting in het Nederlands) PROEFSCHRIFT ter verkrijging van de graad van doctor aan de Universiteit Utrecht op gezag van de rector magnificus, prof.dr. J.C. Stoof, ingevolge het besluit van het college voor promoties in het openbaar te verdedigen op maandag 19 oktober 2009 des middags te 4.15 uur door Maarten Loffler¨ geboren op 14 augustus 1982 te Amsterdam Promotor: Prof.dr. R.C. Veltkamp Co-promotor: Dr. M.J. van Kreveld Chapter Preface It seems that my PhD thesis is finished. It feels strange to realise this fact: I actually put together a more or less coherent book of more than 200 pages, most of which even have content that makes sense. Before starting with those, though, let me briefly look back at how this came to be. When I was in primary school, arithmetic was easily my least favourite subject. I remember that each year there was a new book, its pages filled with countless additions, multiplications, divisions, and similar operations, neatly aligned in rows and columns. Each equation would look something like “108 29 =” or “7 31 =”. I believe the idea was that I had to copy these equations to my− exercise book,× and then write down a number behind each “=” sign, to make the equation true. I could never see the point in doing this, and have spent a lot of time staring at these pages, wondering why we couldn’t be spending that time doing something fun like handenarbeid1 instead. I remember that in the eighth year, the children who finished their arithmetic work within the assigned time were allowed to play a game on the school computer. However, this was never an option for me because I was still working in the book of year six. When I was twelve years old, though, everything changed. I advanced to secondary school, and there we did not learn arithmetic, but mathematics. Suddenly a door was opened for me into the wondrous world of logic, of abstract thoughts, relations and riddles, of algebra and number theory, and, not unimportantly, of geometry. I was instantly hooked. I first learnt to program about four years later. We did have a computer at home as well, and when my sister and I were small children, my father had been experimenting with computer programming, and made a few games for us to play. Of course, at the time I never guessed that he had made them himself. Then, one day he decided to 1Literally, “handenarbeid” translates to “hand labour” or “manual labour”, but the kind taught at Dutch elementary schools is more about being creative with carton and glue than about, say, cutting down trees. vi PREFACE teach me the basics of a computer language called “BASIC”. Computers were already fairly common in those days, and I had been working (or rather, playing) with them all my life, but the idea that I could make a computer do virtually anything I wanted it to, by simply typing in a few words, had never really crossed my mind. After this introduction, though, I soon had balls flying around the screen, and in no time at all I had written elaborate interactive stories, and implemented several intricate strategic games. Looking back at them now, I must admit that these products of my creativity were not all that impressive, but I clearly remember the excitement with which I laboured on those projects at the time. It was the discovery of computer programming that made me doubt my implicit decision to study mathematics after school for the first time. Fortunately, by the time I had to choose the Direction of my Future, a programme called “TWINFO” (TWIN WIskunde and INFOrmatica) was being offered by the university of Utrecht, which promised to combine both studies in a single curriculum. This turned out to be the case only during the first year, after which it was left to my own creativity and organisational skills to complete the remaining four years of both studies; but, it was enough to lure me in. Though I encountered some very different branches of mathematics during my studies that I liked, somehow the courses that involved geometry in some form always specifically interested me. Visual drawings could directly transfer an idea to my mind, and I found them more appealing than formulae involving endless strings of these funny RRR symbols, that require significant staring at before they start making anything resembling sense. The computer science programme, though, did not offer many courses that were supplied with nice pictures. Instead, I was led astray by the intricacies of compiler construction, and at the end of my third year, I wrote what was the equivalent of my Bachelor thesis about generating error messages in a compiler for the functional programming language “Haskell”. However, in my fourth year, the university was just in the process of introducing the Bachelor/Master system, and I had to choose a Master programme, even though technically I was still a student in the old Propedeuse/Doctoraal system. Although I had enjoyed my two months of work in the software technology lab, I was intrigued by a programme called “GIVE” (Geometry, Imaging and Virtual Environments). I decided to take this direction, and as the name suggested it included several computer science courses that were rather more visual in nature than any I had seen so far. I particularly enjoyed a course on “geometric algorithms”, which nicely combined the two main directions that my interest had taken. I decided that I wanted to write my Master thesis on some topic in this field. Probably due to the fashion of the moment, I ended up studying the effects of data imprecision on the computation of the convex hull, a topic which turned out to be conceiling many intriguing puzzles for me to unveil and solve. In fact, one of the results from that thesis is repeated in this one, in Chapter 4. After I finished my studies, I was offered the option to continue for a PhD on the same topic, on the “GOGO” (Geometric Optimisation with Geometric cOnstrants) project. During this time, I was able to get to know the subject better, and it has always provided me with more than enough nice, challenging, and perhaps vii most importantly, unsolved problems. And that is how I ended up writing a PhD thesis about data imprecision in computa- tional geometry. For those who do not immediately appreciate the implications of the last sentence, I would like to point ahead to Chapter 1, where the topic is discussed in some detail. When I had finished my Master thesis about imprecision in convex hulls, of course I proudly showed it to many of my friends, family, and other acquaintances. Most of them would, after the obligatory praising words, invariably ask the same question in the end: “What is it about?” Since they would not be satisfied with the obvious answer, “imprecision in convex hulls”, I thought it was nice to make things a little more concrete by explaining the elastic band analogy: the convex hull of a set of points is what you get when releasing an elastic band around a bunch of nails sticking out of a flat surface. I then proceeded to describe the problems that arise when the locations of the nails are unknown, but this is where I usually lost my audience. Since then, there have been persistent rumours in certain circles that everything I do all day long at my work is put nails into every available flat surface, and wrap elastic bands around them. I want to use this opportunity to stress that this is really not the case, and that there are still several undamaged flat surfaces left in my office. I hope you enjoy reading this thesis. Maarten Loffler¨ Wageningen, September 2, 2009 viii PREFACE Chapter Contents Preface v Contents ix PART I Introduction 1 Introduction 3 1.1 Computational Geometry 3 1.2 Imprecision 9 1.3 Imprecision and Computational Geometry 14 1.4 Contribution of this Thesis 15 2 Modelling Imprecise Data 17 2.1 Imprecision in Input and Output 17 2.2 Imprecise Points Modelled as Regions 22 2.3 Other Models for Imprecise Points 26 2.4 Imprecision in Other Types of Input 29 2.5 Closing Remarks 33 x CONTENTS PART II Bounds on Output Imprecision 3 Bounds on Shape Fitting 37 3.1 Axis-Aligned Bounding Box 38 3.2 Smallest Enclosing Circle 43 3.3 Width 45 3.4 Closing Remarks 50 4 Bounds on the Convex Hull Area 51 4.1 Largest Convex Hull of Parallel Line Segments 52 4.2 Largest Convex Hull of Squares 53 4.3 Smallest Convex Hull 57 4.4 Disks 64 4.5 Closing Remarks 65 5 Approximate Largest Convex Hull 67 5.1 Preliminaries 68 5.2 Approximating the Largest Convex Hull 69 5.3 Squares 70 5.4 Disks 73 5.5 Closing Remarks 77 6 Bounds on the Diameter 79 6.1 Largest Possible Diameter 80 6.2 Smallest Possible Diameter 82 6.3 Smallest Diameter for Squares 84 6.4 Smallest Diameter for Disks 89 6.5 Closing Remarks 91 CONTENTS xi PART III Preprocessing Imprecise Points 7 Preprocessing for Triangulation 95 7.1 Triangulations 97 7.2 Splitting a Triangulation 98 7.3 Triangulating Imprecise Points 104 7.4 Extensions 106 7.5 Closing Remarks 107 8 Preprocessing for Delaunay Triangulation