TECHNISCHE UNIVERSITÄT MÜNCHEN Department of Mathematics

Real-time Visualization of Geometric Singularities Master’s thesis by Stefan Kranich

Supervisor: Prof. Dr. Dr. J¨urgen Richter-Gebert Advisor: Prof. Dr. Dr. J¨urgen Richter-Gebert Submission date: September 17, 2012

Abstract Dynamic geometry is a branch of geometry concerned with movement of elements in geometric constructions. If we move an element of a construction and update the positions of the other elements accordingly, we traverse a continuum of instances of the construction, its configuration space. In many geometric constructions, interesting effects occur in the neighbourhood of geometric singularities, i.e. around points in configuration space at which ambiguous geometric operations of the construction branch. For example, at a geometric singularity two points may exchange their role of being the upper/lower point of intersection of two circles. On the other hand, we frequently see ambiguous elements jump unexpectedly from one branch to another in the majority of dynamic geometry software. If we want to explain such effects, we must consider complex coordinates for the elements of geometric constructions. Consequently, what often hinders us to fully comprehend the dynamics of geometric constructions is that our view is limited to the real perspective. In particular, the two-dimensional real plane exposed in dynamic geometry software is really just a section of the multidimensional complex configuration space which determines the dynamic behaviour of a construction. The goal of this thesis is to contribute to a better understanding of dynamic geom- etry by making the complex configuration space of certain constructions accessible to visual exploration in real-time. In Section 1, we elaborate on our motivation. To that end, we describe effects observable in dynamic geometry software, a mathe- matical model of dynamic geometry, and complex tracing (a concept for avoiding jumping elements). Section 2 introduces mathematical prerequisites from the the- ory of Riemann surfaces. In Section 3, we present our method for visualizing the complex configuration space underlying certain geometric constructions and discuss its implementation using OpenGL. We make use of our visualization method in Section 4, where it is applied to three elementary geometric constructions. There, we analyze the intersection of a circle with a line, the intersection of two circles, and angle bisectors of a triangle, particularly w.r.t. the involved geometric singularities. The thesis concludes with an outlook on possible directions for further research. I herewith declare that I independently prepared the master’s thesis titled Real-time Visualization of Geometric Singularities using only the specified sources.

Munich, September 17, 2012

Stefan Kranich

ii Acknowledgements

First and foremost, I want to express my deepest gratitude to my wonderful wife Sabine. Your constant support, encouragement, and love has been absolutely invaluable for me! While I was writing this thesis, we often had little time for each other. Also, I could not take enough care of our beloved children Eva and Quirin. I am truly sorry about that and am giving my best to make up for it again.

Thanks to my mom Lore, for being a great mother and grandmother.

I am greatly indebted to J¨urgen Richter-Gebert. Not only do I owe much of my knowledge of geometry to you. You have also introduced me to the topic of this thesis, which I find both delightful and demanding, and have been a committed supervisor and advisor. Despite a tightly packed schedule, you always took time for my questions and problems. Thank you very much!

Thank you everyone at the Chair of Geometry and Visualization. You make work very enjoyable. Thanks for feedback and comments regarding my thesis go to Susanne Apel, Martin von Gagern, Johann Hartl, Tim Hoffmann, and Hermann Vogel.

iii Contents

1 Motivation 1 1.1 Dynamic geometry software ...... 1 1.2 A mathematical model of dynamic geometry ...... 3 1.3 Complex detours and complex tracing ...... 5

2 Some mathematical prerequisites 7 2.1 Riemannsurfaces...... 7 2.2 Analytic continuation ...... 11 2.3 Monodromy theorem ...... 13

3 Implementation of the visualization software 14 3.1 Domain colouring ...... 15 3.2 Camera model and transformations ...... 19 3.3 Usage of OpenGL and GLSL shaders ...... 25 3.4 The visualization algorithm ...... 27

4 Analysis of three elementary geometric constructions 32 4.1 Intersectionofacirclewithaline...... 33 4.2 Intersectionoftwocircles ...... 35 4.3 Angle bisectors of a triangle ...... 42

5 Outlook 50

References 52

iv 1 Motivation

Dynamic geometry is a branch of geometry concerned with movement of elements in geometric constructions. If we carry out a ruler-and-compass construction on a sheet of paper, the resulting image is static. However, in the construction, we can distinguish free and dependent elements. Free elements are those that do not depend on other elements, and can therefore, in principle, be moved around freely. The free elements could e.g. be two circles and the dependent elements their points of intersection. Imagine that we move a free element of a construction and continuously update the dependent elements accordingly. In the process, we traverse a continuum of instances of the construction, the so-called configuration space. In some instances, a geometric singularity occurs, which means that two or more branches of an ambiguous geometric operation used as a construction step touch each other. In other words, two or more elements resulting from the ambiguous geometric operation are indistinguishable. For example, two points of intersection can be indistinguishable w.r.t. their position (because they coincide) or w.r.t. their role of being the upper/lower point of intersection (because they have the same height). The goal of this thesis is to visualize what happens in the neighbourhood of geometric singularities. Using the algorithm presented in Section 3.4, the complex configuration space underlying certain geometric constructions can be explored visually in real-time. The visualization can help explain some effects arising in dynamic geometry. On the one hand, these effects can be observed while working with dynamic geometry software. On the other hand, they are inherent effects of the respective constructions themselves and can be described using a mathematical model of dynamic geometry. Therefore, the visualization can contribute to a better understanding of the dynamics of some constructions from both a practical and a theoretical perspective.

1.1 Dynamic geometry software In practice, geometric constructions are often carried out and analyzed using dynamic geometry software. Such programs allow us to interactively manipulate geometric constructions by letting us move free elements, e.g. a circle, and updating the positions of dependent elements, e.g. its intersections with another circle, appropriately. A priori, it is not clear, what “appropriately” really means in this context. Before we discuss it, please consider the following advice: It is highly recommended that the reader tries and experiments with the constructions presented in this thesis using several dynamic geometry systems. You will notice that in most cases they behave very differently, since their underlying models of dynamic geometry differ significantly. In particular, compare the behaviour of Cinderella 2 [12, http://www.cinderella.de] with that of Cabri II Plus (http://www.cabri.com), GeoGebra (http://www.geogebra.org), or The Geometer’s Sketchpad (http://www. dynamicgeometry.com). In what follows, we contrast Cinderella 2 and GeoGebra. For example, let us consider two intersecting circles, a configuration which we examine in more detail in Section 4.2.

1 direction of movement

Figure 1: An experiment in dynamic geometry: We move a circle (blue) along a line through the midpoint of another circle of equal radius (black) and observe what happens to the intersections of the two circles (red and green points). Two singular situations occur – the first, when both circles overlap exactly, is removable; the second at the touching point, where both intersections collapse. Beyond that point, the intersections become complex (real projections of their positions are indicated using transparent points).

Depending on the position of the circles relative to each other, there may be none, one, two, or infinitely many real points of intersection. Assume that we begin with an instance with two real intersections and two circles of equal radius. If we start to move one circle across the other along a line through their midpoints, we observe what follows (cf. Figure 1): The two points of intersection move continuously on the resting circle until the two midpoints (and thus also the two circles) coincide. In this situation, where both circles have infinitely many points in common, the position of the previous two intersections suddenly becomes ill-defined – we run into a geometric singularity. On the other hand, in accordance with their earlier behaviour, it seems reasonable to expect that they move continuously through the singularity. (More evidence to justify this assumption is presented in Section 4.2.) Hence we also obtain two distinct (imagined) positions for the situation in which the two circles overlap. These allow us to remove the discontinuity and let the intersections proceed continuously afterwards. In Cinderella 2, the construction behaves as we have foreseen. GeoGebra swaps the two points when we cross the singularity. Let us move the two circles further apart, such that there are no real intersections anymore and then bring them together again. In doing so, we are crossing the singularity at the touching point twice. In GeoGebra, both points reappear as the upper intersection. Cinderella 2 assigns exactly one of the points to each intersection. Actually, you may notice that in Cinderella 2 the two points exchange their role of being either the upper or lower intersection each time you carry out the movement. At first sight, this comes as a surprise, but it does make sense, as we will see later.

2 Again, the behaviour of the two programs differs, because their mathematical models of dynamic geometry differ. GeoGebra limits itself to the real perspective, which is why elements sometimes jump unexpectedly. The model underlying Cinderella 2 is described in detail by its authors in [8, 10] and will be discussed in Section 1.2. Our visualization helps explain the behaviour of dynamic geometry software. For example, it can be used to predict when jumps occur or when elements exchange their roles.

1.2 A mathematical model of dynamic geometry In their foundational papers [8,10], Kortenkamp and Richter-Gebert derive a rigorous mathematical model of dynamic geometry. It constitutes the fundament on which they built Cinderella 2. Furthermore, it is the basis of our considerations in this thesis. Therefore, it certainly deserves to be examined in what follows. To start with, “geometric construction” needs be modelled mathematically. A geometric construction comprises a sequence of elements, e.g. points or lines, that are related to each other by a sequence of basic operations, e.g. line through two points (join) or intersection of two lines (meet). In every construction step, we can only operate on input elements or elements constructed previously. A very concise description of what we have outlined can be given via a geometric straight-line program (GSP) over a relational instruction set (RIS) (as suggested by Kortenkamp in his dissertation, cf. [8, Chapter 4 and Section 5.1]). This is a generalization of straight-line program (SLP), which accounts for the fact that some operations are ambiguous or infeasible. For example, the intersection of a circle and a line can yield two points of intersection and we cannot join two identical points. Let us define RIS and GSP. In what follows, we give an overview of the exposition of [10]. First of all, we need to identify the elements that a construction can contain. Since we do not want to overcomplicate things, we restrict ourselves to the Euclidean geometry of points, lines, and circles. Other, more general systems of dynamic geometry can be obtained analogously. Let P , L, and C denote the set of points, the set of lines, and the set of circles, respectively. There should also be an element representing the result of an infeasible operation. Let that element be denoted by . Furthermore, let P˜ := P , ∗ ∪ {∗} L˜ := L , and C˜ := C . We assign a type O = O O O P,˜ L,˜ C˜ n ∪ {∗} ∪ {∗} 1 × 2 ×···× n ∈ { } to any construction based on the types of its elements. An instance of a construction of type O is then a sequence of elements (o ,...,o ) O. Basic operations which 1 n ∈ can be used as construction steps are given by relations ω I I ...I O with ∈ 1 × 2 × n × I ,I ,...,I ,O P,L,C . The first n entries represent the operands and the last entry 1 2 n ∈ { } represents the result of the operation. For example, the intersection of two distinct lines is described by a ternary relation of type L L P . Note that by using relations we × × allow for operations with multiple results, such as the intersection of a circle and a line. To provide for infeasible input, ω can be augmented to ω˜ I˜ I˜ I˜ O˜ with ∈ 1 × 2 ×···× n × I˜ , I˜ ,..., I˜ , O˜ P,˜ L,˜ C˜ by relating infeasible input to . The RIS is the set of 1 2 n ∈ { } ∗ G relations corresponding to admissible basic operations. A GSP describes a geometric construction by means of its type O = (O1,O2,...,On), a sequence of operations (ω˜ , ω˜ ,..., ω˜ ) n and an assignment of elements to the inputs of ω , i = 1,...,n. 1 2 n ∈ G i

3 Every operation ωi must be of type Oi, must be assigned inputs of the correct type, and must use only input elements and elements resulting from previous construction steps. An instance (o ,...,o ) O of a specific construction must satisfy every relation 1 n ∈ determined by its construction steps. Here we only discuss the coordinate-free representation of geometric constructions as a GSP over an RIS. For the introduction of coordinates, the interested reader is referred to [8, Section 5.1.2] [10, Section 3]. Having settled the mathematical description of geometric constructions, we can turn our attention to formalizing their dynamic behaviour. Hence, Kortenkamp and Richter-Gebert postulate four natural expectations. Firstly, a the type of an element of a construction should never change. Regardless of how we move free elements around, points should remain points, lines should remain lines, etc. Secondly, every instance of a construction must satisfy the relations determined by its construction steps. We should not be able to leave the configuration space of a construction by moving free elements around. Thirdly, the dynamic geometry system should be deterministic. From a given initial configuration we should always reach the same final configuration by carrying out the same movement. This condition is automatically satisfied for dynamic geometry systems whose RIS comprises only unambiguous geometric operations. However, if we introduce ambiguous operations, the final configuration is not determined by the initial configuration and the end position of the moved element. Rather, it also depends on the path along which the element is moved. Different paths may lead to different final configurations. Such monodromy effects are described in more detail in Section 2. Finally, the dynamic geometry system should be continuous. If we move free elements along a (piecewise) linear path, the dependent elements must not jump. This can be regarded as a natural expectation insofar as in macroscopic reality, we never see objects jump from one place to another in literally no time. However, in practice, this requirement proves to be the hardest to fulfil. Prior to Cinderella, no dynamic geometry software achieving continuity existed. A priori, we do not even know whether the above expectations are as reasonable as they seem. At first, it is unclear whether continuity can be achieved in a dynamic geometry system satisfying the other requirements. A major result due to Kortenkamp and Richter-Gebert is a necessary and sufficient condition for such a dynamic geometry system to be continuous (cf. [10, Section 4, esp. Theorem 4.2]). As it turns out, the basic operations of such a dynamic geometry system must be representable by algebraic functions. Consequently, a coordinate-based approach must take elements with complex coordinates into account, which may arise as solutions of algebraic equations. The resulting configuration space becomes complex. For certain constructions, the algorithm presented in Section 3.4 makes the complex configuration space arising from the above model of dynamic geometry accessible to visual exploration in real-time. Remarkably, the curious effects observable in dynamic geometry software such as unexpected jumps and elements exchanging their roles are inherent effects of the complex structure underlying the construction. Therefore our

4 Im

singularity ⋆⋆ 0 1 Re

(1 eiπt)/2 1 − 2 detour

Figure 2: The notion of complex detours: Instead of running into a singularity as we move a free element along a real path, we circumvent the singularity by taking a detour through complex space, which connects its initial and final position; adapted from [18, Fig. 27.15]. visualization can help us to obtain a deeper understanding of the dynamics of geometric constructions in general, not only w.r.t. dynamic geometry software.

1.3 Complex detours and complex tracing Closely related to the mathematical model we have just described are the notions of complex detours and complex tracing, which enable us to resolve continuity issues arising from geometric singularities. In other words, they can be used to obtain a continuous dynamic geometry system. Here, our approach diverges from that of the previous subsection in being coordinate-based. The basic idea is the following: Firstly, we recognize that we can unify our approach to some extent, if for the result of geometric operations we take elements with complex coordinates into account. Algebraically, these operations correspond to the solution of (systems of) polynomial equations, which are completely indifferent to whether we are interested in real or complex solutions. The latter may be intangible from a real perspec- tive, but are very helpful nonetheless. For instance, when we discuss the intersection of a circle and a line, we can discard an awkward case distinction – there are always two complex points of intersection (counted with multiplicity). Secondly, we extend this idea naturally and also allow free elements to take complex coordinates. Hence, instead of running into a singularity when moving a free element along a real path, which renders collapsing dependent elements indistinguishable, singularities can be avoided completely by taking a detour through the ambient complex space (cf. Figure 2). We thus obtain distinct dependent elements for every position of the free element along the complex detour and the question, where they should reappear after we “crossed” the singularity and which should be which, is no longer a question at all! As promised at the end of Section 1.1, we would like to explain, under which circum- stances points (or other elements) exchange their roles in Cinderella 2. To that end, we need to examine its implementation of complex tracing in more detail. Assume that we are given an initial configuration of a construction. If that instance happens to be degenerate, because interaction previously stopped in a geometric singularity, the last

5 known non-degenerate configuration is used instead. In order to move a free element, the user needs to click and drag it. During the movement, the mouse position is sampled at a certain rate. We can use the sampling points to obtain e.g. a polygonal, i.e. piecewise linear, path connecting initial and current position of the free element. An edge between two subsequent sampled mouse positions, denoted by x and y, can be parametrized as (1 λ)x + λy, for λ [0, 1]. However, we do not let λ run from 0 to 1 along the real − ∈ axis, but along a semicircle through complex space (substitute e.g. λ = (1 eiπt)/2, for − t [0, 1]). Instead of a semicircular detour, we could as well choose any other continuous ∈ path which runs from 0 to 1 through the complex plane without intersecting itself. In any case, the danger of running into a geometric singularity has not been banned, yet! If we have bad luck, there is a singularity on the detour we have chosen. In that case, we are free to adjust our choice of detour. In theory, our chances of finding a “secure” route for λ are very good, since geometric singularities of primitive geometric operations representable by algebraic functions form a finite, discrete subset of the complex plane, namely the set of branch points of the underlying Riemann surface (cf. Section 2). In practice, however, complex tracing is an intrinsically difficult problem. Kortenkamp and Richter-Gebert analyze the algorithmic complexity of the tracing problem (compute the new positions of dependent elements after a free element moved along a certain path) and the reachability problem (decide whether two different instances of a geometric construction can be continuously deformed into each other) in [9, 11]. We will touch on their results in the following excursus: If we restrict ourselves to a dynamic geometry system involving only points and lines and the admissible basic operations are line through two points (join), intersection of two lines (meet), and angle bisector of two lines, the tracing problem is NP-hard (cf. [11, Theorem 5.1]). We should mention that the algorithmic complexity is due to the ambiguity of the angle bisector operation. It is difficult to make branching decisions which yield continuous behaviour, i.e. to consistently select the appropriate one of the two angle bisectors of two lines. Conversely, in a construction comprising only unambiguous operations such as join and meet, the positions of dependent elements are uniquely determined by those of the free elements and can thus always be computed straightforwardly. What about the complexity of tracing in a dynamic geometry system involving points, lines, and circles? Since angle bisectors can be constructed with ruler and compass, but not all ruler-and- compass constructions can be carried out with join, meet, and angle bisectors alone (cf. [13]), such a system is strictly more general. In this setting, the tracing problem must therefore be at least NP-hard as well. The reachability problem for the dynamic geometry system of points and lines with join, meet, and angle bisector operations is NP-complete (cf. [11, Theorem 4.1, proof by reduction from 3-SAT]). It becomes PSPACE-complete, e.g. if all dependent elements must have real coordinates (cf. [11, Theorem 6.1]). After this excursus on complexity issues in dynamic geometry, we finally answer the question under which circumstances elements of a construction exchange their roles: if and only if their defining parameters wind around geometric singularities on their way from initial to final configuration such that they end up on a different sheet of the underlying Riemann surface. The reader who is not familiar with the theory of Riemann surfaces need not worry. It is discussed in Section 2. In any case, we should point out

6 that this is exactly what can be observed in the experiment where we moved a circle along a line through the centre of another circle and traced the intersections of the two circles. When we move the two circles apart and then bring them back together, we take the following complex detours: one counterclockwise semicircle around the geometric singularity at the touching point on our way forth and another counterclockwise semicircle around it on our way back. Altogether that makes a full circle around the geometric singularity. During the movement, the two points of intersection therefore exchange their roles of being the upper/lower points of intersection. A word of caution is appropriate here: In some cases, the behaviour of Cinderella 2 depends on the velocity at which elements are moved. If the real path between two configurations comes very close to a geometric singularity in complex space, whether or not a semicircular detour winds around it depends on its radius. That radius, in turn, is determined by the distance between adjacent sampling points and thus by mouse speed. If you do not want to “catch” a nearby singularity, a good rule of thumb is: The closer you are to the singularity, the slower you should move the mouse. Besides this subtlety, what often hinders us to fully comprehend the dynamics of geometric constructions is that the real plane presented in dynamic geometry software is in fact just a section of the multidimensional configuration space which determines the behaviour of the construction. Being imprisoned in the real world, many complex effects remain hidden to us. The goal of this thesis therefore is to create the possibility to visually explore the complex configuration space of certain constructions in real-time and to thereby deepen our understanding of these constructions.

2 Some mathematical prerequisites

If we want to visualize something, it is certainly advisable that we first of all understand what we are visualizing, also from a mathematical perspective. Therefore, before we come to the main part of this thesis, let us introduce (or refresh) some mathematical prerequisites. In case you are already familiar with analytic continuation and the theory of Riemann surfaces, you may choose to proceed directly to Section 3. According to the exposition of the previous section, we must adopt the complex viewpoint. Of course, our discussion cannot possibly include everything that is required for understanding what follows. We rather assume that the reader has taken at least an introductory course on complex analysis. You should know what singularities, holomorphic functions, etc. are. If you would like to look up some of these basic definitions and concepts, Needham’s Visual Complex Analysis [15] and, if you are able to read German, the book by J¨anich [5] are very recommendable. Furthermore, we sometimes think in terms of projective geometry (cf. e.g. the book by Richter-Gebert [18]).

2.1 Riemann surfaces The geometric operations we intend to study are rarely uniquely determined. For instance, two distinct lines have exactly one point in common, but a circle and a line have two intersections (counted with multiplicity). This ambiguity arises, if the corresponding

7 algebraic expressions involve square roots or other multivalued functions. Therefore we need a framework to deal with such functions. For the time being, the square root function will serve us as an example of such a multivalued function. In what follows, we use it to introduce the concept of Riemann surfaces. Initially, our approach will sometimes be informal and hand-waving, but we will clarify things later. In real analysis, the value of √x2 is typically defined as x . By constantly restricting | | ourselves to the principal branch of the square root (the one with non-negative real part), we can obtain a unique result again. This approach, however, is inappropriate in our situation, because of what follows: Consider a construction for the square root of a given complex number. It suffices that we acknowledge there exists a ruler and compass construction to accomplish this task (cf. [13], Theorem 2.7). What it looks like exactly, need not concern us here. Suppose we implement such a construction in Cinderella 2 and move point A representing the radicand z around. Then we request that point B representing its square root √z should also move continuously. If the construction were such, that it always returned the principal value of √z, and we moved A on a circle of radius 2 around the origin counter-clockwise, we would see B jump when we cross the negative real axis (cf. Figure 3a), contradictory to our claim. A better (albeit still not satisfactory) approach is to consider the principal branch for complex numbers z with non-negative imaginary part, and the other branch elsewhere. This allows us to carry out the above movement once without any discontinuity (cf. Figure 3b). However, notice that while A lands on its starting position again, B on the other hand, which moves at half of A’s speed, does not come to rest in its original position, but on the negative solution. This effect of going around a certain point in a full circle without returning to the original configuration is called monodromy. It is a common feature of multivalued functions. Note that the path on which we wind around such a point need not be circular – circles were chosen here merely to simplify our discussion and visualization, but we can just as well choose any other analytic path. Points around which monodromy occurs are called branch points. These are exactly the points where two or more branches collapse. Branch points can be either finite or infinite, like e.g. the origin w.r.t. the complex logarithm, depending on whether there are finitely or infinitely many branches. In the former case, one will eventually arrive at the initial configuration again after a finite number of turns around the branch point. In our case, at the origin we have +√0 =0= √0. The only other branch point of the square root is the point at infinity, − since +√ = = √ . ∞ ∞ − ∞ Anyway, our choice of branches is still not satisfactory, since it leads to a jump which occurs, when A now begins its second round around the origin (cf. Figure 3b). In order to remove that jump, we must in some way take into account how often we have moved around the origin. This distinction can be made using polar coordinates: Let (r, φ) R2 denote the complex number r eiφ, then r eiφ = r ei(φ+2π), but ∈ · · · (r, φ) =(r, φ + 2π). If z = r eiφ, then √z = √r eiφ/2. Therefore, as already mentioned, 6 · · the angular velocity of A is exactly twice as large as that of B. Thus we can expect

8 Im Im 4 4 5 3 5 3 7 6 8 7 6 5 9 5 6 4 2 6 10 4 2/14 3 11 3 2 12 2 14 7 1 1 7 13 1 1/13 12 Re Re

ju 11 ju 8 m 10 12 8 m 12 p 9 p 8 9 11 9 11 10 10

(a) If we move a red point representing a com- (b) If we choose the principal branch of the plex number on a circle around the origin, square root for complex numbers with non- we observe a discontinuity in the movement negative imaginary part, and the other of a green point representing its principal branch elsewhere, we can move around the square root as we cross the negative real origin once without discontinuity. A jump axis. now occurs, when we begin a second round.

Im Im 4 4/16 5 3 5/17 3/15 8 7 6 ju 9 5 m 2/14 6/18 10 4 2/14 6 p 11 3 12 2 7 1 13 1/13 7/19 13 1 1/13 14 2 12 Re 14 24 Re 3 11 15 23 8 4 10 12 16 22 5 9 8/20 17 21 12/24 67 8 1819 20 9 11 9/21 11/23 10 10/22

(c) The same holds, if we make exactly the (d) Removing any discontinuity is possible by opposite choice as in b. taking into account how often we move around the origin and by combining the approaches of b and c in a certain way.

Figure 3: Different choices of square root branches.

9 to come back to the initial situation again after A completes two full turns and it makes sense that we identify angles that are congruent modulo 4π. Let φ =: ϕ + k 4π, · 0 ϕ < 4π, k Z, and consider ϕ instead of φ. Since the jumps occur along the ≤ ∈ same lines independently of the radius of our circles, we may hope to achieve continuous behaviour not only locally, but also globally. To that end, the branches can be chosen as in Figure 3b for 0 ϕ 2π and exactly the other way round for 2π ϕ < 4π (cf. ≤ ≤ ≤ Figure 3c). Like that, we obtain a smooth transition from our first choice to the second choice and vice versa, since at the boundaries of the intervals the square roots coincide (cf. Figure 3d). We have finally managed to trace a square root around the origin continuously. In fact, both square roots are taken care of: as they exchange roles after one full turn, one can be obtained from the other by simply adding 2π to φ. Let us recapitulate the discussion so far: It is nontrivial to choose square root branches such that the square root of a complex point does not jump as that point moves continuously on a circle around the origin. Naive approaches yield discontinuous behaviour of the square root. In order to avoid this, we expand the domain on which the square root is defined to two copies of the complex plane whose numbers are distinguished by their polar angles modulo 4π. Furthermore, we choose the negative branch of the square root for numbers whose polar angle ranges between π and 3π (modulo 4π) and the positive branch otherwise. The complex square root is thus uniquely defined on the extended domain. A slightly different, more common method, which leads to the same result, is to consider one copy of the complex plane per branch. The jumps are then removed by slicing both copies along the negative real axis – thereby cutting the negative axis in two halves – and gluing the upper half of one copy to the lower half of the other copy and vice versa. The cut along the negative real axis is a so-called branch cut. It is a line segment extending from the branch point at the origin to that at infinity. While the negative real axis is the canonical choice of a branch cut for the complex square root, other choices of branch cuts are also possible. For instance, they need not be straight, but can be curved. Note that the branch cuts are really just artefacts of the process of “gluing” two copies of C together. The resulting object is the always same indepently of our choice of branch cuts. The copies of the complex plane assigned to the different branches are called sheets. Either way, we have just constructed an analytisches Gebilde for the complex square root function. It can be interpreted as a complex one-dimensional manifold and is then called Riemann surface. To the best of the author’s knowledge, there is no English equivalent of the German term analytisches Gebilde. Therefore, and since we are not primarily interested in the differentiable structure, we will from now on use the term Riemann surface, even if we do not take the manifold point of view. Historically, Riemann surfaces were introduced in 1851 by Bernhard Riemann in his dissertation [19]. He developed the concept of slicing and gluing copies of the complex plane together, which we outlined above. A first rigorous treatment in terms of analytische Gebilde and manifolds was given by Hermann Weyl in his 1913 classic Die Idee der Riemannschen Fl¨ache [24]. The reader who is interested in a more modern, yet more abstract, topological description is referred to the book by Eberhard Freitag [3].

10 The author hopes that this introduction has helped the reader to understand the basic idea of Riemann surfaces. Now it is time to formalize and generalize our approach such that it becomes applicable to a broader range of multivalued functions. To that end, we will specify what we mean exactly, when we say that we are “going around a certain point and observe what happens to another point”.

2.2 Analytic continuation It is an amazing, somewhat counter-intuitive result of complex analysis that the value of a holomorphic function on any open set determines its value at all points in its maximum possible domain. The reason for that is analytic continuation, i.e. the possibility to continue holomorphic functions outside their original domain. Let us see how it works: Suppose that U is an open subset of the complex plane (w.r.t. normal topology), f : U C → a holomorphic function, and a U a point. Then we can use Taylor expansion to obtain ∈ a power series representation of f around a,

∞ f(z)= c (z a)n, n − n=0 X (n) with coefficients c C of the form c = f (a) . Recall that in general such a power n ∈ n n! series converges on a disk around a with radius r, where r R 0 is called its ∈ ≥ ∪ {∞} radius of convergence. r is the infimum of the distance between a and all points which are not included in any domain on which f can be defined holomorphically. If r is a positive real number, the series, then also called function element with centre a, converges in the interior of the disk of convergence and maybe, but not necessarily, for some points on its boundary. The key ingredient of analytic continuation is that from a function element with centre a we can obtain a power series expansion around any point b in the function elements’ disk of convergence by collecting powers of z b as follows: − ∞ ∞ c (x a)n = c ((x b)+(b a))n n − n − − n=0 n=0 X X n ∞ n k n k = c (x b) (b a) − n k − − n=0 k=0   X n X ∞ n k n k = c (x b) (b a) − n k − − n=0 X Xk=0   ∞ ∞ n k n k = c (x b) (b a) − n k − − n=0 X Xk=0   ∞ ∞ n n k k = c (b a) − (x b) n k − − k=0 n=0   ! X Xk d n k n∞=0 cn(x a) ∞ dx − x=b k ∞ k = (x b) =: cˆk(x b) P k! − − Xk=0 Xk=0

11 b

a| b − b ⋆⋆ critical point r r −| a a| b − | ⋆⋆ a singularity

(a) Analytic continuation of a function element (b) We can continue a function element with with centre a around point b in its disk centre a along a path from a to b uniquely of convergence. The disk of convergence by iterating the construction of Figure 4a, around b has a radius of at least r b a , if and only if the disk of convergence has but is often larger than that (dashed).−| − In| positive radius around every point of the the latter case, the domain can be extended path. Otherwise we hit an insurmountable naturally (yellow boundary). critical point somewhere on the way.

Figure 4: Analytic continuation

Note that it is essential that b lies within the disk of convergence around a, since otherwise the coefficients cˆk might be ill-defined. Let r denote the radius of convergence around a. Clearly, a lower bound for the radius of convergence of the function element with centre b is r b a . In many cases, the actual radius of convergence around b will be −| − | larger than that. Then, since both power series agree on the intersection of their disks of convergence, the function element with centre a can naturally be continued to the function element with centre b (cf. Figure 4a). The function element with centre b is called direct analytic continuation of the function element with centre a. Direct analytic continuation can be iterated as long as the radius of convergence at every point around which we would like to expand the domain is always sufficiently large. This motivates the following definition: Let a,b C points in the complex plane ∈ and let f : U C a complex function which is holomorphic on an open disk U around → a. There exists an analytic continuation along a path γ : [0, 1] C with γ(0) = a and → γ(1) = b if we can, starting with the power series expansion of f around a, assign to every point γ(t), t [0, 1), a function element with centre γ(t) by means of iterated ∈ direct analytic continuation. In practice, this enables us to continue the function element around a to point b by successively choosing expansion points on γ which lie in the disk of convergence around their respective predecessor. It should be mentioned that if analytic continuation along γ is possible, then the value at b is determined uniquely, independently of our choice of expansion points. The straightforward proof, which uses the fact that function elements whose centres are close enough can be obtained from each other by direct analytic continuation, is left to the reader.

12 Otherwise, if analytic continuation along γ is not possible, there exists a tˆ (0, 1) ∈ such that any attempt to continue beyond γ(tˆ), called critical point, fails: The disk of convergence around a critical point contains only the point itself. (Hence, at a critical point the path must run through either an isolated singularity or a branch point of f.) Therefore, we cannot choose another expansion point which is closer to b and analytic continuation finds an abrupt end. While analytic continuation along a path is unique, if possible, it is inherently path- dependent. Analytic continuation along different paths connecting two points a and b may yield completely different values at b. Apparently, when we were talking of “going around a point” earlier, we were actually thinking of analytic continuation along a path around that point. An example for the path-dependence therefore can be found in our discussion of the square root function: circular closed paths around the origin with winding numbers of different parity yield different results. An analytic function arises from a function element with centre a as the set of all function elements which can be reached by analytic continuation along paths starting at a. Roughly, we arrive at an analytisches Gebilde by introducing poles and finite branch points to an analytic function. Since this is technically rather involved, we will skip the details here.

2.3 Monodromy theorem As already mentioned, analytic continuation of a function element with centre a C ∈ along a path from a to another complex point b is path-dependent. In general, different paths from a to b may lead to different function values at point b. The monodromy theorem makes a statement about analytic continuation along different paths from a to b which yield the same value at b. Before we present it, we need to remind ourselves what homotopic relative to a set means: Two paths γ ,γ : [0, 1] C are homotopic relative to a set S [0, 1], if there 0 1 → ⊂ exists a continuous map H : [0, 1] [0, 1] C satisfying × → H(0,t)= γ (t) t [0, 1] , 0 ∀ ∈ H(1,t)= γ (t) t [0, 1] , 1 ∀ ∈ H(s, 0) = H(s,t) s S, t [0, 1] . ∀ ∈ ∀ ∈ Now to the monodromy theorem: Let a,b C, f : U C as before. Analytic ∈ → continuation along two paths γ ,γ : [0, 1] C with γ (0) = γ (0) = a and γ (1) = 0 1 → 0 1 0 γ1(1) = b yields the same value at b, if they are homotopic relative to their endpoints via H : [0, 1] [0, 1] C and analytic continuation is possible along H(s,t) =: γ (t) for all × → s s [0, 1] (cf. Figure 5). ∈ For a proof, see e.g. [2, p. 27]. Beware that the monodromy theorem gives a sufficient condition, not a necessary one! Different paths may lead to identical values although they are not homotopic relative to their endpoints. For instance, in the square root example, it makes no difference, whether a circular closed path winds around the origin one or three times. However, the two paths are not homotopic relative to their endpoints.

13 b

singularity ⋆⋆

⋆⋆ singularity

a

Figure 5: Monodromy theorem: Analytic continuation along different paths connecting a and b yields the same value at b if the paths are homotopic relative to their endpoints and analytic continuation is possible for every path in between.

3 Implementation of the visualization software

With the concepts introduced in Section 2, we have at hand what is necessary for a more mathematical formulation of what we want to visualize in order to deepen our understanding of the dynamics of geometric constructions. We want to visualize Riemann surfaces underlying geometric constructions. As mentioned in Section 1.2, the primitive geometric operations of a continuous dynamic geometry system must be representable by algebraic functions. Therefore, we can derive algebraic expressions in the positions of free elements for the position of any dependent element of a construction. We are interested in a visualization of the Riemann surfaces corresponding to these algebraic expressions. The images of Riemann surfaces used throughout Section 4 have been produced using visualization software developed as a complement to this thesis. Given their theoretical importance, the author was surprised to find that there is not much material, i.e. articles and software, on the visualization of Riemann surfaces in general. Notable contributions in that area include a series of papers by Trott [23], who also provides a Mathematica package at http://www.mathematicaguidebooks.org/V6/ downloads/RiemannSurfacePlot3D.m, an article by Kivel¨a[7], and last, but not least, an article by Nieser, Poelke, and Polthier [16]. Trott and Kivel¨ause Mathematica – relying heavily on its built-in symbolic solvers – and output three-dimensional plots as a result. The approach of the last above-mentioned article differs from the former two insofar as its primary concern is the topology rather than the geometry of the surfaces. However, we can “fix” this straightforwardly by an appropriate choice of height function. They construct and output a triangle mesh of the surface and apply domain colouring (cf. Section 3.1) to visualize complex values, keeping both real and imaginary part visually accessible, whereas in Trott’s and Kivela’s images, the information about either real or imaginary part is lost. Therefore, we decided to implement a variant of the mesh-based domain coloured method in the C programming language [6] using OpenGL [22] as graphics framework.

14 Ideally, the software displayed the geometry of the desired Riemann surface accurately and were efficient enough to enable its user to explore and manipulate the surface interactively, i.e. in real-time. Therefore, all surface related computations should be carried out using GLSL shaders [20] in order to fully exploit the hardware acceleration of modern graphics cards. The following overview of our implementation is panoramic in the sense that like an alpinist reaching the peak of a mountain, we are getting a general view, but the level of detail at which we can examine specific points is naturally limited. However, we will give our best to discuss the important implementation aspects as thoroughly as possible.

3.1 Domain colouring One of the problems we are facing when we want to visualize complex functions is that their graphs are (real) four-dimensional objects. In contrast, a computer screen only has a two-dimensional surface which must suffice as a display. Of course, we are ready to consider projections onto the screen as 3D graphics, as long as we are able to rotate, scale and transpose things. In any case, we are accustomed to the three-dimensional space surrounding us and imagining four or more dimensions is difficult for most of us. Indeed, the situation is no different for Riemann surfaces, where we simply have more complex values per complex point in the domain. Domain colouring is a simple, but clever method to resolve the issue (at least partially). It allows to represent a four-dimensional object in two dimensions. The question of priority appears to be a matter of open debate, since some claim to have used the method earlier than others without having considered it worth being published due to its simplicity. Nevertheless, it is a key ingredient of our visualization and thus certainly deserves to be described here. The most natural approach involving colours to display a four-dimensional object is probably the following: 1. identify the complex domain of the function with the xy-plane, 2. plot the real part of the function above that domain, 3. use different colours for different imaginary parts, and 4. project onto the screen. This seems reasonable, but it remained to be determined what a good colour scheme looked like. Domain colouring works slightly differently: Its name is derived from the fact that it colours the domain, rather than the range of the function, using a suitable reference image. The reference image assigns a colour to every point in the complex plane. Suppose we would like to visualize function f : C C. Using an appropriate projection, we → identify the complex plane in the domain of f with the computer screen, such that every pixel (i,j) corresponds to a point x C. Then we assign to every pixel (i,j) the colour ij ∈ of f(xij) in our reference image. The reference image can be designed such that we can read off argument and modulus of the function value from the image of the function under domain colouring and, furthermore, such that we can identify roots and poles of the function and their respective order. Hence, we construct our reference image as in [16] (cf. Figure 6).

15 (a) Hue is determined by argument. (b) Saturation and value are determined by modulus. Under stereographic projection onto the unit sphere from its north pole, the south pole should be black and the north pole should be white.

(c) Rays and circles are added, which enable (d) Value is adjusted in the annulus between us to detect distortion. adjacent circles to indicate the direction of growth of the modulus.

Figure 6: Composition of features of the reference image

16 It is convenient to use HSV (hue, saturation, value) colour space to describe that reference image. The resulting colour can later be converted to the RGB (red, green, blue) colour model of OpenGL, e.g. using the algorithm given in [4, p. 411]. Hue is given by an angle in [0, 2π), which determines the tone of the colour as found on a colour wheel at that angle (cf. Figure 6a). We have pure red, pure green, and pure 2 4 blue at angles of 0, 3 π, and 3 π, respectively. Saturation and value both range in the interval [0, 1]. Saturation is a measure of colourfulness. A saturation of 0 yields shades of grey. Value corresponds to the brightness of the colour (think of a dimmable light source). A value of 0 yields black independently of what values hue and saturation take. For our reference image, the hue of a complex point is defined as its argument modulo 2π (cf. Figure 6a). This means we can, in principle, determine the argument of a complex function at any point in a domain coloured image by looking at its hue, up to multiples of 2π. A nice side-effect of linking hue and complex argument as above is that the order of roots and poles is made visible in domain coloured images. As a consequence of Cauchy’s argument principle, every argument occurs exactly n times among the complex function values around a root or pole of order n. Thus it suffices to count how often the colour wheel winds around a root or pole to recognize its order. On a global scale, saturation and value of a complex point are chosen based on its modulus, such that roots of a complex function correspond to black spots and poles correspond to white spots in the domain coloured image. This mapping can be achieved as follows: Any point z C is projected stereographically onto the unit sphere, ∈ ∪ {∞} parametrized in spherical coordinates, from its north pole, C S2 [0, 2π) [0, π] , z (ϕ,θ) := (arg(z), π 2 atan2(1, z )), ∪ {∞} → ≃ × 7→ − | | where ϕ is the azimuth (which can be used for hue) and θ is the zenith angle. Then we define functions of θ for saturation and value such that the south pole is black (saturation = 0, value = 0), the north pole is white (saturation = 0, value = 1), and the equator is fully saturated (cf. Figure 6b). Given these constraints, the specific choice of functions is really a matter of taste – opinions on whether the resulting domain coloured images are visually pleasing, or not, may vary from person to person. So far, using our reference image, we can read off argument and modulus of complex values from domain coloured images and can identify roots and poles and their orders. We can enhance the reference image yet a little bit by adding white “rays” which subdivide 2π regularly at certain argument angles and concentric black circles around the origin with radii on a logarithmic scale of modulus (cf. Figure 6c). Together, these form a net, which allows us to determine how certain areas of the complex plane are distorted by a complex domain coloured function. In practice, the “rays” are actually implemented as cones between certain azimuth angles. As a last improvement, we combine globally defined value linearly with a locally defined version such that starting at a black circle, colours slowly get darker, if we move inside the circle, and colours slowly become lighter, if we move further outside (cf. Figure 6d). Thus we can see, in which directions the modulus of a complex function value increases, respectively decreases.

17 3 (a) f1(z)= z (b) f2(z) = exp(1/z)

(c) f3(z)=+√z (d) f4(z)= √z − Figure 7: Examples of domain colouring

18 Finally, let us look at some examples of domain colouring in action (cf. Figure 7). These can be interpreted as follows: 3 Figure 7a depicts the function f1(z)= z . In its centre, there is a black spot representing the zero at z = 0. It is a root of order 3, which can be read off the fact that the colour wheel winds around the black spot exactly three times. With increasing modulus, z3 increases relatively fast, namely cubically. Therefore, as the modulus of z increases, the colours become brighter (and whiter) relatively fast as well. The function of Figure 7b, f2(z)= exp(1/z), exhibits an essential singularity at the origin. Casually speaking, it looks like a zero is kissing a pole at z = 0. What we are actually seeing is a visualization of Picard’s theorem (cf. [5, p. 43]): A holomorphic function f(z) which has an essential singularity at z = a, a C, takes every complex ∈ value with at most one exception in any punctured open disk around a. In our case, the exceptional value, which is never attained by exp(1/z), is 0. Apparently, the colours are getting lighter as we approach the origin from the right and darker as we approach from the opposite direction. Indeed, limz 0+ǫ exp(1/z)= and limz 0 ǫ exp(1/z) = 0. → ∞ → − Along the imaginary axis, every colour occurs repeatedly as we move towards z = 0. This corresponds to exp(1/( iz)) = exp( iz) 1 diverging indeterminately for z 0. ± ± − → Figure 7c and Figure 7d show the positive, respectively negative, branch of the complex square root function. Looking at the colours in the images, we immediately notice that the range of these functions is limited. Clearly, the positive (negative) branch of the complex square root function maps the complex plane to the set of complex numbers with positive (negative) real part. Another eye-catching feature of the two figures is the canonical branch cut along the negative real axis. The colours in the upper left quadrant of Figure 7c resemble those in the lower left quadrant of Figure 7d, and vice versa. If we cut both images out, sliced them along the branch cut and glued them together as described in Section 2.1, we could literally construct a Riemann surface. We will do so, at least virtually, later (cf. Figure 12 and Section 3.4).

3.2 Camera model and transformations In this subsection, we attempt to give an answer to the question how a camera and its transformations are best represented in our OpenGL application. Of course, “camera” is really just a metaphor, which allows us to talk about how things actually work more easily. We imagine that the image displayed on the computer screen is captured by a camera, which we can move around freely in the scene. There are several ways of describing camera perspective. We will later in this subsection briefly touch an approach using quaternions. In OpenGL, the perspective is traditionally determined by two matrices: the model-view matrix and the projection matrix. Both are real 4 4 transformation × matrices that can be interpreted as projective transformations applicable to points in R3 represented in homogeneous coordinates, i.e. points in RP3. Before we can discuss the purpose of these transformation matrices and how they are computed, we need to talk about coordinate systems. Usually, in 3D graphics, we deal with several of them. For instance, we may distinguish local coordinate systems per object (object coordinates) and a global coordinate system for the surrounding three-dimensional

19 y′ view frustum

z′

view frustum

y x′

x z (a) In eye coordinates, the view frustum is a (b) In clip coordinates, the view frustum cor- clipped pyramid. The cutting planes in responds to a regular cube. z-direction are called near clipping plane and far clipping plane.

Figure 8: The view frustum in eye space and clip space. space (world coordinates). This offers us the flexibility to separate the description of the relative positions of vertices and faces of an object e.g. w.r.t. its centre (which can be chosen as the origin in object coordinates) from the description of the absolute placement of the object (in world coordinates). Furthermore, there are eye coordinates, which describe the scene as seen by the camera, whose position defines the origin of eye space. If we want to produce a realistic three-dimensional view, we also need to take into account that the view of the human eye as well as that of a camera lens is physically limited. In OpenGL, the visible region is modelled as a clipped pyramid called view frustum (cf. Figure 8a). It is delimited by two planes each for the field of view in x and y direction, and near and far clipping plane in z direction. In order to determine, whether or not a point is visible and should thus be displayed or not, clip coordinates are computed. These are three-dimensional homogeneous coordinates of the form (x,y,z,w) RP3, s.t. ∈ the view frustum is identified with the set of points whose x , y , and z-coordinates − − range in [ w,w] (cf. Figure 8b). Normalized device coordinates are dehomogenized clip − coordinates. The view frustum then corresponds to the cube [ 1, 1]3 of edge length 2 − centred at the origin. In normalized device coordinates, a point in the near clipping plane has a z-coordinate of 1, and a point in the far clipping plane a z-coordinate of 1. − The model-view matrix translates object coordinates into eye coordinates. It can be decomposed into model matrix and view matrix. The model matrix describes how the local coordinate system of an object – the model – is to be embedded in the global coordinate system. Since we are concerned with the display of only one object, a Riemann surface, we can dismiss the distinction between local and global coordinates and set the model matrix to the identity matrix. The view matrix describes how the world needs to be rotated, scaled and shifted in order to match the desired camera perspective. Clearly, if the world rotates in one direction, the camera rotates in the opposite direction, etc.

20 Camera placement is therefore determined by the inverse of the view matrix. Let M,V denote the model matrix and the view matrix, respectively. Then the model-view matrix is simply the composition of both transformations, i.e. the product V M of view and · model matrix. The projection matrix P represents the transformation from eye coordinates to clip coordinates. Clip coordinates can be obtained from object coordinates via the model- view-projection matrix P V M. · · OpenGL dehomogenizes clip coordinates to obtain normalized device coordinates and discards all points that do not lie in [ 1, 1]3. This process is called clipping. By taking − into account the viewport, i.e. the part of the application window occupied by the OpenGL view, window coordinates (xy-coordinates in pixels and depth-coordinate) are then computed. There are some more steps until an image is finally rendered on screen, but these need not concern us here. In OpenGL version 2.1, utility functions for the computation of model-view and projec- tion matrices, e.g. gluLookAt, gluPerspective, glOrtho, glOrtho2D, exist. However, these cannot be used in conjunction with shaders and have therefore been deprecated in OpenGL version 3.0 and removed in newer versions. Since we will use shaders, we need to compute these matrices ourselves. The documentation of the above helper functions can serve as a first clue on how this can be accomplished. How the computation is implemented in detail certainly depends on what information we store about the camera and this design decision in turn should depend on how we allow the user to interactively manipulate the camera perspective. Probably one of the most popular methods for letting the user rotate the camera is arcball rotation [21]. The basic idea is that by clicking and dragging the mouse, the user is rolling a virtual ball on the surface of the computer screen. The inverse of the effective rotation is then applied to the camera (such that the world rotates just like the imagined ball). An elegant implementation works roughly as follows: We obtain a vector pointing in the direction of the axis of rotation as the cross-product of the axis perpendicular to the screen with the vector induced by mouse movement. The axis, which we denote by v, is then normalized and interpreted as a pure imaginary unit quaternion. The angle of rotation in radians, denoted by ω, is determined as the distance across which the mouse moved divided by the circumcentre of the imagined ball, multiplied by 2π. Then we obtain the rotation 3 3 1 R Im H Im H R , x qxq− , ≃ → ≃ 7→ ω ω where q = cos 2 + sin 2 v. However, there are two major drawbacks in using this method (and its variants), which render its usage less intuitive from the user’s perspective than it may sound. The first arises from the experience that one cannot move the mouse precisely as intended. Therefore, we introduce small rotation errors. Usually, sooner or later, an undesired rotation around the axis perpendicular to the screen occurs. In order to revert it, we need to drag the mouse in small clockwise or counterclockwise circles, which is awkward. The second disadvantage is that it can be disturbing to turn the world upside down, which is exactly what happens if we drag the mouse vertically long enough. This poses a

21 problem especially in our context, since we often deal with surfaces which are symmetric up to colours. Of course, one should be able to look at those surfaces from above and below, but it would be beneficial, if we were unable to look at one of its other sides turned upside down. Therefore, we avoid arcball rotation and need to come up with another method. The author acknowledges that the following method is simple enough that it is certainly not a new discovery, but declares that he found it independently. In order to circumvent the disadvantages of arcball rotation outlined above, we disallow rotation around the axis perpendicular to the screen completely and limit vertical rotation appropriately. Our camera object comprises the following attributes: a three-dimensional vector (x, y, z) R3 for the camera position, azimuth α R and zenith angle ζ [0, π] ∈ ∈ ∈ in radians describing camera orientation, and camera zoom factor λ> 0. Since camera orientation is deliberately determined by only two angles, our method also does not suffer from gimbal lock typically encountered with Euler angles. The user may manipulate the camera as follows: If we click and drag the mouse while pressing the shift key, the camera position is translated in x and y-direction proportionally to the delta between initial and final mouse position. If we click and drag the mouse without pressing the shift key, azimuth is increased (decreased) proportionally if the mouse is moved to the right (left) and zenith is increased (decreased) proportionally if the mouse is moved down (up) within the bounds of [0, π]. Similarly, the camera can also be rotated using the arrow keys (another difference to arcball rotation). We adopt the convention of OpenGL and use a right-handed coordinate system as our world coordinate system. If at any stage there is uncertainty about whether we are looking at a surface from above or below, this question can be answered very easily by dragging the mouse vertically or horizontally: Looking down from above we cannot decrease the zenith angle and looking up from below we cannot increase it. Besides, in the former case dragging to mouse to the right increases azimuth and thus rotates the surface counterclockwise, whereas in the latter case the surface is rotated clockwise. The model-view matrix can be obtained from the attributes of our camera as a rotation about world z-axis by the azimuth angle followed by a rotation about the transformed x-axis by the zenith angle and a translation by the camera position in transformed coordinates: 1 0 0 x 1 0 0 0 cos(α) sin(α) 0 0 − 0 1 0 y 0 cos(ζ) sin(ζ) 0 sin(α) cos(α) 0 0 V :=    −    0 0 1 z 0 sin(ζ) cos(ζ) 0 0 0 1 0 0 0 0 1 0 0 0 1  0 0 0 1        cos(α)   sin(α) 0 x  − cos(ζ)sin(α) cos(ζ) cos(α) sin(ζ) y =  −  sin(ζ)sin(α) sin(ζ) cos(α) cos(ζ) z  0 0 0 1    

22 y y view frustum f tan(θ/2) far clipping plane f tan(θ/2) E C n tan(θ/2) near clipping plane n tan(θ/2) 0 camera 0 θ 2 A B D view frustum z x f n 0 0 af tan(θ/2) − − an tan(θ/2)

(a) The view frustum from the left. (b) The view frustum from the front.

Figure 9: Sketches for the derivation of the projection matrix.

The calculation of the projection matrix is taken from function gluPerspective (as documented at http://www.opengl.org/sdk/docs/man/xhtml/gluPerspective.xml).

We have θ cotan( 2 ) a 0 0 0  0 cotan θ 0 0  P := 2 , n+f 2 n f  0 0
n f n· ·f   − −     0 0 1 0   −  where a is the aspect ratio (width divided by height of the field of view), n and f are the distances to the near and far clipping planes (required to be positive) and θ is the angle of view in (transformed) y direction. The user may zoom in or out using the mouse wheel or plus and minus keys. Camera zoom can be modelled either as a shift in (transformed) z-direction or as a scaling factor to the angle of view in (transformed) y-direction. This closes the description of our proposed method for camera interaction. However, the definition of the projection matrix P still lacks explanation. Clearly, P represents a projective transformation of RP3. It is therefore uniquely determined (up to homogeneity) by the images of five points, given that no four of these points are coplanar. Recall that under P , the view frustum in eye coordinates should be mapped to the cube of edge length 2 centred at the origin in clip coordinates. Hence, we select points A, B, C, D, E as depicted in Figure 9b. Since we are talking about finite points, they can be normalized such that the last coordinate entry of all of them is 1. (Still we must work with homogeneous coordinates: In affine coordinates, the desired transformation would

23 no longer be linear.) The normalized coordinates can be read off straightforwardly from Figure 9: an tan θ an tan θ an tan θ − 2 2 2 θ θ θ  n tan n tan n tan A = − 2  , B = − 2  , C =  2  ,  n   n   n   −   −   −   1   1   1              af tan θ af tan θ 2 − 2 θ θ  f tan   f tan  D = − 2 , E = − 2  f   f   −   −   1   1          It is easily verified that no four points of A, B, C, D, E are coplanar (either geometrically or by checking that the determinants [A, B, C], [A, B, D], ..., [C,D,E] do not vanish). The reason behind our choice of preimages is that we know the coordinates of the corresponding images under P . Let these images be denoted by A′,B′,C′,D′, and E′. Then we have 1 1 1 1 1 − − 1 1 1 1 1 A′ = −  , B′ = −  , C′ =   , D′ = −  , E′ =   . 1 1 1 1 1 − − −  1   1   1   1   1                      Next we will compute P step by step. To that end, we first compute a projective 4 transformation P1 which maps the standard basis of R , e1,e2,e3,e4, to A, B, C, D and the vector of all ones, u = e1 + e2 + e3 + e4, to E by solving the system of linear equations

| | | | αβ γ δ AB C D = λE  
| | | |   for α,β,γ,δ and setting

| | | | P := AB C D αβ γ δ . 1   | | | |
  We obtain a solution 1 2 1 1 1 α = , β = , γ = , δ = , λ = n −n n f f and thus a tan θ 2a tan θ a tan θ a tan θ − 2 − 2 2 2 θ θ θ θ  tan 2 2 tan 2 tan 2 tan 2  P1 = − − . 1 2 1 1  − − −   1 2 1 1     n − n n f   

24 Note that P1 is regular. Analogously, we obtain for the projective transformation P2 which maps e1,e2,e3,e4, and u to A′,B′,C′,D′, and E′, respectively, that

1 2 1 1 − − 1 2 1 1 P2 = − −  . 1 2 1 1 − −  1 2 1 1   −    1 Then P is simply the composition of P1− and P2,

θ cotan( 2 ) a 0 0 0 θ 1  0 cotan 2 0 0  P = P2 P − = , · 1 n+f 2 n f  0 0
n f n· ·f   − −     0 0 1 0   −  which matches exactly how we defined the projection matrix.

3.3 Usage of OpenGL and GLSL shaders As of today, OpenGL is the de facto standard in 3D graphics programming. OpenGL stands for Open Graphics Library. Roughly speaking, it is a framework which facilitates the communication with and control over 3D graphics cards. A key benefit of OpenGL, which separates it from its competitors, is its portability across several operating systems and support by most, if not all recent hardware. In what follows, we summarize the history of its development, which affects present-day usage. The historic overview is based on information found in the book by Shreiner [22], the book by Rost et al. [20], and on the OpenGL website at http://www.opengl.org. Furthermore, we explain the components used by our visualization software and how they interact with each other. OpenGL was first released in 1992. In the two decades of its existence, OpenGL has undergone substantial changes. Usually, new features are made available as extensions to the specification by graphics card vendors. After evaluation by the OpenGL Architecture Review Board some of them are included in a later version of the specification. Originally, OpenGL was conceived as a state machine. In early versions, there were stacks of registers holding model-view and projection matrices, which could be modified either by overloading them or by multiplication with another matrix. Utility functions for the computation of the transformation matrices existed. Objects were drawn by sending vertex by vertex to the graphics card between calls to glBegin and glEnd, which determined the type of the primitive (points, lines, triangles, triangle strip, etc.) that the submitted vertices defined. Colours and other vertex attributes were also stored in registers. Back then, OpenGL provided fixed functionality: Across all programs, the graphics processing pipeline worked in exactly the same manner. With the advent of more and more powerful hardware, OpenGL evolved. A turning point in its development was the introduction of the OpenGL shading language, GLSL, in OpenGL version 2.0 (released in September 2004). For the first time, vertex and fragment

25 processing (see below) could be customized with shaders that were written in a portable, high-level language and executed directly on graphics hardware. This enabled developers to move certain tasks from the CPU to the GPU, which – being highly specialized and optimized – can often perform them several times faster. Just like OpenGL, GLSL was subsequently extended and adapted to match the development of OpenGL. In other words, every version of OpenGL greater than 2.0 comes with a certain version of GLSL. The success of GLSL marked the departure from fixed functionality. Starting with OpenGL 3.0, fixed functionality was considered deprecated in favour of the usage of shaders. In OpenGL 3.1, functions related to fixed functionality were actually removed from the specification. In order to retain backward compatibility and support for legacy code, a compatibility extension was introduced. OpenGL 3.2 introduced another shader type, namely geometry shaders (see below). At this point, we skip a few releases, since our program does not rely on newer features. The current version of the OpenGL specification is 4.3 (published on August 6, 2012). At the moment, its features are fully supported by only the most modern graphics cards (and only using beta drivers). By keeping the requirements to a sensible minimum, we ensure that our software can also be run on less recent hardware and with less recent drivers. In fact, for our purposes, a graphics card supporting at least OpenGL 2.1 and geometry shaders via the EXT geometry shader4 extension suffices. Let us turn our attention to the components of OpenGL which are used by our algorithm. These are vertex buffer objects, vertex shaders, geometry shaders, and fragment shaders. We will discuss them one after another. A vertex buffer object, or VBO for short, allows us to transfer vertex data (positions, normals, etc.) from our program to the graphics card and store them there. Two types of vertex buffer objects exist, namely array buffers and element array buffers. Array buffers hold the actual vertex data. Element array buffers hold indices of vertices in an array buffer. We use both types in combination to describe triangle meshes efficiently. Instead of specifying the attributes of every vertex of a mesh repeatedly for every triangle to which it belongs, we specify the attributes of every vertex just once (using an array buffer). The triangles of the mesh are then described by referencing the indices of their vertices counterclockwise (using an element array buffer). Once we computed the desired mesh and filled (or updated) the buffers accordingly, we can instruct OpenGL to render their contents as a triangle mesh. (Of course, buffer contents can also be rendered as different primitives, e.g. as points, lines, or triangle strip.) Then the vertices enter the graphics processing pipeline and are processed by our GLSL program. A GLSL program comprises several GLSL shaders. Every GLSL program must contain at least a vertex and a fragment shader. Other shaders, such as geometry shaders, can be used optionally. The shaders are compiled separately and linked to a program which can then be used by the graphics card. The vertex shader is invoked once per vertex. It takes the position of the vertex in object coordinates as input and outputs the eye coordinates of the vertex. The developer may choose to specify additional input variables, e.g. normals or model-view matrix and

26 projection matrix. These can be supplied either per vertex (attribute variables) or per primitive (uniform variables). Additional output variables can also be defined per vertex (varying variables) and made available to subsequent shaders. The output of the vertex shader serves as the input to the geometry shader, if any, or otherwise to the fragment shader. The geometry shader, if any, is invoked once per primitive. Unlike the vertex shader, which can only access a single vertex at a time and has absolutely no information about its neighbours, the geometry shader possesses knowledge about all vertices forming the primitive simultaneously. Based on that input, the geometry shader can generate and output additional primitives. For every vertex of these primitives, eye coordinates must be specified. Again, additional input and output variables may be defined. The output of the geometry shader is directed to the fragment shader. As an intermediate step, clipping, primitive assembly, transformation into window coordinates, culling (sorting vertices by their depth information from back to front) and rasterization take place without us having a hand in the matter. The rasterization process computes fragments, i.e. parts of pixels which are covered by the primitives or cut off by their edges. The fragment shader is invoked once per fragment. Vertex attributes and additional output variables from previous shader stages are interpolated to determine corresponding values per fragment, which form the input of the fragment shader. The fragment shader computes colours, lighting, or textures. It outputs the colour of the fragment. Fragment colours are evaluated to determine the colour of each pixel and the rendered image is finally displayed on screen.

3.4 The visualization algorithm The previous subsections have introduced the key ingredients of the visualization algorithm incorporated in our software. We are finally prepared to put things together. The algorithm constructs a domain-coloured Riemann surface mesh for a given multivalued complex function. In order to make the basic idea more accessible, we first present a mathematical formulation of the algorithm. Its implementation will be commented thereafter. In pseudocode, the algorithm looks roughly as follows:

27 Algorithm 1 Input: G =(V,E,F ) planar triangle mesh with V C, and f,g : C C ⊂ → ∪ {∞} Output: H =(V,ˆ E,ˆ Fˆ) a Riemann surface mesh for f √g over G, colours c: Vˆ RGB ± → 1 for all i,j,k F do { }∈ 2 for all v i,j,k do ∈ { } 3 qv := f(v), rv := g(v) 4 if a branch cut runs through i,j,k then p { } 5 for all v i,j,k on one side of the branch cut do ∈ { } 6 r := r v − v 7 for all l 1, 2 do ∈ { } 8 for all v i,j,k do ∈ { } 9 if l = 1 then 10 p := q r v v − v 11 else if l = 2 then 12 pv := qv + rv 13 vˆl := (Re v, Im v, Re pv) 14 c(ˆvl) := colour of pv in domain colouring reference image 15 add triangle ˆı , ˆ , kˆ to H { l l l}

Let us analyze the above algorithm. As already mentioned, it basically constructs a domain-coloured Riemann surface mesh for a given multivalued complex function. Its input comprises a planar triangle mesh G (i.e. a planar graph with vertices V , edges E, and triangular faces F ) and two complex functions f,g. Every vertex v V of G is ∈ identified with a point in the complex plane (i.e. G is embedded in C). The input mesh serves as the domain for our visualization. More exactly, the algorithm computes a mesh (represented by graph H) which discretizes a Riemann surface for f √g restricted to ± the convex hull of V C. Furthermore, it uses domain colouring to assign a colour to ⊂ every vertex of the output mesh. Now that we are informed about its input and desired output, let us see how the algorithm actually works. We tacitly assume that we start with an empty output mesh H. The outermost loop (line 1) lets us inspect all triangles in the planar input mesh one after another. f and √g are evaluated at each vertex of any given triangle i,j,k F { }∈ (lines 2 and 3). Lines 4–6 can be interpreted as a discrete, local version of complex tracing. We defer their explanation until later, when we have understood the rest of the algorithm. For the time being, suppose these lines are commented out and not executed. The for-all-loop in line 7 constructs two triangles of the output mesh, one for each sheet of the Riemann surface. Hence, we iterate over every vertex v of the triangle again (line 8) and determine the appropriate function value f(v) g(v) by selecting the negative ± branch for the first sheet (lines 9 and 10) and the positive branch for the second sheet p (lines 11 and 12). The vertices of the output mesh possess three-dimensional coordinates, which are computed in line 13. The xy-coordinates are simply the coordinates of the corresponding vertex in the input mesh. The z-coordinate, or height, is determined by the real part of the corresponding function value. As a result, the output mesh eventually

28 (a) Actual behaviour: Along a branch cut, a (b) Desired behaviour: We obtain a smooth vertical gap occurs between different sheets. transition between different sheets along (Blackness is due to interpolation.) the branch cut. This behaviour can be achieved by adding lines 4–6 of Algo- rithm 1.

Figure 10: The behaviour of Algorithm 1 without lines 4–6 illustrates the necessity of discrete local tracing.

contains two vertices vˆ1, vˆ2 for every vertex v of the input mesh, which represent the two function values at v. To every output vertex, we apply domain colouring (cf. Section 3.1) based on the function value which we have assigned to it (line 14). Finally, in line 15, the computed triangle is added to the output mesh (including its vertices and edges). Having finished the overview of the above algorithm, let us continue by examining the function of lines 4–6. In principle, for every triangle of the input mesh, the algorithm computes the coordinates of six vertices. Those derived from f √g form a triangle of − the first sheet and those derived from f + √g form a triangle of the second sheet of the Riemann surface mesh. If we removed lines 4–6 from Algorithm 1, it suffered from the following erroneous behaviour: If a branch cut runs through a triangle of the input mesh, then there are vertices of the corresponding output triangles on both sides of the branch cut. Recall that along a branch cut, sheets of a Riemann surface meet. However, if we combined the upper vertices on either side of the branch cut to a triangle and the lower ones to another triangle, this created a gap where the sheets should actually touch each other (cf. Figure 10). Note that this is an effect of the discretization. Indeed, if the input mesh was infinitely fine, i.e. if its triangles had infinitesimal size, everything worked as expected. However, in practice, the quality of our mesh is naturally limited just as memory and processing power of the graphics card and we cannot get rid of the error simply by refining the input mesh. Besides, the form of the branch cut may vary from function to function

29 Figure 11: a tetrakis square tiling of a square and may depend on user-modifiable parameters. In any case, it may not be linear and the computational effort to dynamically adapt the input mesh such that enough of its vertices lie on the branch cut would possibly reduce performance considerably. Instead, in order to achieve the desired continuity in the appearance of the Riemann surface, whenever a branch cut runs through a triangle of the input mesh, we must let the lower output vertices on one side of the branch cut form a triangle with the upper output vertices on the other side of the branch cut, and vice versa. This is exactly what lines 4–6 take care of. By negating the sign of the radical part of the function, the vertices on one side of the branch cut are made switch sheets. Thus, effectively, in lines 8–15, the vertices are combined correctly. The procedure can be interpreted as a discrete, local version of complex tracing, insofar as the function values change appropriately when we cross a branch cut on our way from one vertex of the Riemann surface mesh to an adjacent vertex. Two central questions remain to be addressed in this section: How can we determine whether or not a branch cut separates two vertices of a triangle? How can we translate Algorithm 1 into terms of OpenGL? The former question can be answered relatively easily. The branch cut of f √g is ± the branch cut of the involved square root expression. The complex square root function we use features the canonical branch cut along the negative real axis. Therefore a branch cut runs through triangle i,j,k F , if and only if there are (at least) two points in { }∈ g(i),g(j),g(k) with negative real part whose imaginary parts differ in their signs. This { } connection is also the reason why we use the radicand g rather than √g in the input of our algorithm. The answer to the latter question, regarding an implementation in OpenGL, is more elaborate. As already mentioned in Section 3.3, we use GLSL shaders to exploit the hardware acceleration provided by graphics cards. In fact, we have implemented most of Algorithm 1 in GLSL shaders. Actually, the CPU is only responsible for the computation of the input mesh and for user interaction. For the images of Riemann surfaces presented in this thesis, we use as input mesh a tetrakis square tiling (cf. Figure 11) of a square centred at the origin of the complex plane. This mesh is computed at program start-up. It is stored in graphics card memory using an array buffer, which holds the two-dimensional floating-point coordinates of its

30 vertices (representing real and imaginary part), and an index buffer, which holds the faces of the mesh (referencing the indices of their vertices in the array buffer). The mesh is static, i.e. never changed after its initialization, which helps reduce the computational effort needed for our visualization. Whenever we would like to (re-)display the Riemann surface, we instruct the graphics card to render the contents of the vertex buffer objects as a triangle mesh. The input mesh then enters the graphics processing pipeline, i.e. it is handled by our GLSL shaders. Clearly, we cannot actually work with the real and complex numbers of Algorithm 1 in GLSL. Instead, we represent real numbers as floating point numbers (GLSL type float) and complex numbers as two-dimensional floating point vectors of real and imaginary part (GLSL type vec2). In what follows, we will sometimes still talk of real and complex numbers instead in order not to overcomplicate our exposition. Since there is no native complex number type in GLSL, we need to implement elementary complex number operations ourselves. This can be done more or less straightforwardly for arithmetic. Our complex square root function is derived from [1, Section 3.7.27 on p. 17]. In our visualization software, Algorithm 1 is spread across three shader stages: vertex shader, geometry shader, and fragment shader. We will discuss each of them in turn. The vertex shader evaluates f and g at every vertex of the input mesh. In some cases, f and g may depend on user-modifiable parameters, which the vertex shader receives as uniform variables. Furthermore, the input mesh is embedded in the xy-plane of RP3 by mapping every vertex v C to (Re v, Im v, 0, 1). The values of f and g and these ∈ homogeneous coordinates are passed to the geometry shader using varying variables. Additionally, the geometry shader receives model-view and projection matrices as uniform variables. Upon every change of the camera attributes due to user interaction, these uniform variables are updated accordingly. The geometry shader outputs two triangles for every triangle of the input mesh, i.e. one per sheet of the Riemann surface of f √g. At every vertex of the input mesh, ± f √g has exactly two values, yielding a total of six function values per triangle. The ± xy-coordinates of the output vertices match those of the corresponding input vertices. Their z-coordinate, or height, is given by the real part of the corresponding function value. We need to determine which of the six output vertices form a common triangle. To that end, the geometry shader inspects the function values of g at the vertices of the input triangle to test whether or not the vertices are separated by a branch cut. If that is the case, we apply discrete local tracing, as described earlier in this section. Otherwise, we simply connect the upper vertices and the lower vertices to a triangle each. The vertices of the resulting triangles are transformed using the model-view-projection matrix and the two (transformed) triangles are emitted. At this point, we briefly leave our sphere of influence as OpenGL carries out some steps of the graphics pipeline independently (cf. Section 3.3). We are back in business, when our fragment shader receives the values of f √g interpolated per fragment as ± a varying variable. The interpolated function value is used by the fragment shader for domain colouring the respective fragment. Finally, the image is rendered on screen. If we apply our implementation to our complex square root function, the resulting Riemann surface looks e.g. as in Figure 12.

31 Figure 12: a Riemann surface for the complex square root

Of course, in Figure 12, we can only see one side of the Riemann surface. In contrast, our implementation is fast enough to allow the user to freely move and rotate the camera in real-time. This means that whenever the user wants to view the surface from a different perspective, the display is updated instantly, creating the illusion of a fluid, undelayed movement. The same holds for user-modifiable function parameters. A change of parameter values is immediately visible on screen.

4 Analysis of three elementary geometric constructions

In this section, we apply the techniques which we developed for the visualization of Riemann surfaces to support our analysis of three elementary geometric constructions. These are commonly known – only in a static context – from school mathematics. Here, on the other hand, we will see how the mathematical concepts of Section 2 provide us with (and in fact are essential for) a deeper understanding of the dynamics of these constructions. To that end, we will restrict ourselves to three characteristic examples, namely the intersection of a circle with a line, the intersection of two circles, and angle bisectors of a triangle. A more general and more complete survey of geometric constructions, sadly, is beyond the scope of this thesis.

32 4.1 Intersection of a circle with a line When we intersect a circle with a line in a paper and pencil (or rather ruler and compass) construction, three distinct cases may be observed. There can be either two (generic case), one (touching case) or no (degenerate case) real points of intersection. Accepting that categorization, however, means missing half of the truth. In fact, these three cases are no different from each other. As we have already seen in Section 1, in order to unify them, we must take complex solutions into account. There are always exactly two (complex) points of intersection between a circle and a line (counted with multiplicity). This can be seen as follows: W. l. o. g., we may restrict ourselves to the case of a vertical line and the unit circle. (All other possible configurations are symmetric to our specific choice by M¨obius trans- formations, which preserve incidence.) This yields the following defining equations for the points of intersection

x2 + y2 1 = 0 (1) − x = λ (2) where λ determines the movement of the line along the x-axis. By plugging x = λ into the first equation, we get

x = λ (3) y = 1 λ2 (4) ± − For λ < 1 we obtain as the two real solutionsp the coordinates of the two real points of | | intersection, for λ = 1 the two solutions coincide and the line touches the unit circle at ± a real double point, and for λ > 1 we have two distinct complex points of intersection. | | Let us now consider y as a multivalued function of λ and let λ range over the Riemann sphere C . While we may have a difficult time trying to imagine the line moving ∪ {∞} into a complex x-direction, this is perfectly feasible mathematically. For λ = , i.e. | | ∞ λ = , we then have as a double point of intersection. ∞ ∞ Let us apply the visualization techniques developed in the previous section to equation (4) to obtain a Riemann surface for the y-coordinate of the intersections. Clearly, 1, 1, and are the branch points of y and we may choose line segments − ∞ from to 1 and 1, respectively, as branch cuts. These branch cuts arise naturally ∞ − from equation (4), if for the square root the canonical branch cut along the negative real axis is chosen. By gluing together the positive and the negative sheets of y along these branch cuts, we arrive at the Riemann surface for y depicted in Figure 13. Recall that we are basically plotting the (two-valued) real part of y over λ C R2. In ∈ ≃ Figure 13b, the Riemann surface is shown from the following perspective: The (Re λ)-axis points to the right, the (Re y)-axis points upwards, and the (Im λ)-axis points into the screen (respectively into the sheet of paper). In Figure 13a, the view is rotated around the (Re y)-axis. Let us examine some characteristic features which can be read off from the picture. Looking at Figure 13a, we might easily get a wrong impression on what the sheets of the

33 (a) (b)

Figure 13: two different perspectives of a Riemann surface underlying the intersection of a circle and a line

Riemann surface actually are. The two sheets do not intersect, they are merely touching each other along branch cuts. The positive branch of y corresponds to the upper half, and the negative branch to the lower half of the picture. This can also be derived from the colours of the surface. The upper half is yellow, orange, red, and purple. These hues are found in our reference image at values with positive real part. On the other hand, the lower half is mostly green and blue, thus representing values with negative real part. The branch cuts, where both sheets touch each other, are also easily identified in Figure 13a and 13b. Furthermore, the values of y apparently change continuously as we move from one sheet across a branch cut to the other sheet. In Figure 13a, this continuous transition is best observed between the blue region of the lower sheet and the purple region of the upper sheet. Remember that to achieve this continuity was the original intention behind the introduction of Riemann surfaces. Because of that, it is a feature which is common to all pictures of Riemann surfaces found in this thesis. Remarkably, the Riemann surface depicted in Figure 13 also admits a different inter- pretation: It represents a complex unit circle! The algebraic equation of the unit circle is given by Equation 1. Intersecting the circle with the vertical line at x = λ for different λ is exactly the same as varying x in the circle equation. If we take complex solutions into account together with their multiplicities, there are two values of y satisfying the circle equation for every value of x = λ C. Therefore, we may regard a complex unit ∈ circle as a double cover of the entire complex plane. Furthermore, the intersection of a circle and the union of all vertical lines is the circle itself, whether from a real or complex

34 perspective. Thus, there is a one-to-one correspondence between our Riemann surface and the complex unit circle. This interpretation also yields a proper generalization of the real perspective. We find the real unit circle, which we are intersecting with the line x = λ, in the circular hole at the centre of Figure 13b. Clearly, the real perspective can be obtained from our Riemann surface visualization by intersecting the surface with the Im λ = 0 plane.

4.2 Intersection of two circles Although the intersection of two circles appears to be similar to the intersection of a circle and a line from a real perspective in some regards – we can have two, one or no real points of intersection, which arise as the intersection of (an arbitrary) one of the circles with a line (the bisector between the midpoints of the circles) – the underlying complex structure is indeed very different. A first and obvious difference is, of course, that we there may also be infinitely many points of intersection, when the circles are of the same size and overlap precisely, or even no solutions for concentric circles of different size. As we shall see later (on page 37), the former (degenerate) situation corresponds to an essential singularity of the respective complex function. Before we continue, let us make some simplifying assumptions. By symmetry (up to M¨obius transformations), we may w.l.o.g. choose the unit circle as one of the circles. Furthermore, we restrict ourselves to the case in which the two radii are the same, i.e. to the case of two circles of unit radius. Now we may formulate our scenario as follows

x2 + y2 1 = 0 (5) − (x λ)2 +(y µ)2 1 = 0 (6) − − − where λ,µ C determine the position of the second circle. ∈ ∪ {∞} 4.2.1 The special case µ = 0 Instead of solving the system (5), (6) straightaway in full generality, let us first plug µ = 0 into (6), thereby constraining the movement of the second circle to (complex) x-direction, which is an interesting case in its own right. In the non-degenerate case, i.e. for λ = 0, we arrive at x = λ by subtracting (5) from (6), rearranging appropriately and 6 2 dividing by λ. Plugging in and rearranging then leads to λ x = (7) 2 λ2 y = 1 (8) ±r − 4 1 This result differs from the one in Section 4.1 only by a scaling factor of 2 in λ, which accounts for the fact that the two circles touch at λ = 2 whereas the line touched ± the circle at λ = 1. The dilatation of λ by 1 can easily be read off also from our ± 2 visualization: Compare Figure 13 of a Riemann surface underlying the intersection of a

35 circle and a line with Figure 16a and 16b, which depict the Riemann surface underlying our current scenario. Besides, in contrast to the intersection of a circle and a line, we have a discontinuity at λ = 0 in our current scenario, where the system (5), (6) for µ = 0 has infinitely many solutions. However, by equation (8), that discontinuity is obviously removable, if we set y = 1 for λ = 0. This motivates the following experiment: ± Try and move a circle along a line through the midpoint of another circle of equal radius in Cinderella 2 [12] (or your favourite dynamic geometry software) and observe what happens to the points of intersection of the two circles. Due to its underlying mathematical model (cf. Section 1), Cinderella 2 treats the removable discontinuity as can be expected: The points of intersection move continuously through the geometric singularity, i.e. the situation when the two circles coincide, without exchanging their roles (cf. Figure 1). This means that during the whole movement, the upper point of intersection remains the upper point of intersection and the lower one remains the lower one.

4.2.2 The general case µ C ∈ Next, we step away from the special case µ = 0 and let µ take arbitrary complex values again. Then solving the system (5), (6) is a little more involved: We solve (5) for y

y = 1 x2, ± − p plug the result into (6) and expand. This yields

1+ λ2 + µ2 2µy 2λ 1 y2 = 1. − ± − Now we subtract 1 on either side, separate the squarep root from the rest and get

2λ 1 y2 = λ2 µ2 + 2µy. ± − − − Squaring both sides, we arrive atp

4λ2 4λ2y2 = λ4 4λ2µy + 4µ2y2 + 2λ2µ2 4µ3y + µ4, − − − an equation of degree four in λ and µ, but only quadratic in y, which is easily solved:

( 4λ2 4µ2)y2 + (4λ2µ + 4µ3)y λ4 + 4λ2 2λ2µ2 µ4 = 0 − − − − −

(4λ2µ + 4µ3) (4λ2µ + 4µ3)2 4( 4λ2 4µ2)( λ4 + 4λ2 2λ2µ2 µ4) y = − ± − − − − − − 2( 4λ2 4µ2) p − − = ... 1 4 λ2 µ2 = µ λ −2 −2 2 ± s λ + µ !

36 The system (5), (6) is rotationally symmetrical in x and y w.r.t. λ and µ. If we rotate the xy-plane clockwise around the origin through a right angle, the y-axis is mapped to the x-axis, while the x-axis is mapped to the negative y-axis. Therefore we can derive an expression for x from the above expression for y by replacing µ with λ and λ with µ. − This leads to the overall result

1 4 λ2 µ2 x = λ µ −2 −2 (9) 2 ∓ s λ + µ ! 1 4 λ2 µ2 y = µ λ −2 −2 (10) 2 ± s λ + µ !

The reader who has not skipped the calculation is expected to share the author’s relief that x, y as in (9), (10) satisfy equations (5), (6) (verified by plugging in). Another indication of correctness is that for µ 0, the solution converges to (7), (8). → Now there are two ways in which we can think about y and both have their benefits. We may consider y a multivalued complex function in λ and µ, or we may treat y as a family of multivalued functions y in λ, parametrized by µ (parameter µ C is arbitrary, µ ∈ but fixed). Using the former approach, some features of y remain more accessible from a theoretical standpoint. In contrast, the latter is more practical for visualization and more consistent with Section 4.1, insofar as it allows us to regard a Riemann surface for yµ, instead of a complex two-dimensional manifold for y. From now on, we will choose our viewpoint as appropriate, and by a slight abuse of notation simply write y in either case (the semantics should be apparent from the context). For µ = 0, y possesses poles of order 1 at λ = iµ. Evidently, 6 ± 1 4 λ2 µ2 lim y = lim µ λ − − λ iµ λ iµ 2 ± λ2 + µ2 →± →± s ! 1 4 = lim µ iµ = , λ iµ 2 ± λ2 + µ2 ∞ →±  r  and

1 (4 λ2 µ2)(λ iµ)2 lim y (λ iµ)= lim λµ iµ2 λ − − ∓ λ iµ · ∓ λ iµ 2 ∓ ± (λ + iµ)(λ iµ) →± →± s − ! 1 4(λ iµ) = lim iµ2 iµ2 iµ ∓ = 0. λ iµ 2 ± ∓ ± (λ iµ) →± s ± ! Clearly, every pole of y is also a branch point of y. y has many more branch points: λ = 0 for µ = 0; λ = , µ = , or any point satisfying λ2 = 4 µ2. 6 ∞ ∞ − At one of its branch points, namely for λ = µ = 0, y exhibits an essential singularity. This can be seen as follows: A singularity is essential, if it is neither removable nor a

37 Figure 14: The asymptotic position of the intersections (white points) of two circles of equal radius as we align one circle to the other depends on from which side we are approaching (blue or green circles). pole. Equivalently, a singularity is essential, if and only if the limit value changes with the direction from which we are approaching the singularity. Indeed we have

1 4 λ2 µ2 lim lim y = lim lim µ λ − − λ 0 µ 0 λ 0 µ 0 2 ± λ2 + µ2 → → → → s ! λ2 = lim 1 = 1, λ 0 ± − 4 ± → r whereas µ lim lim y = lim = 0. µ 0 λ 0 µ 0 2 → → → Note how well this agrees with the real perspective: if the two points of intersection propagate along a continuous path, when we move one circle across the other, their position asymptotically – as we converge towards the singular situation – depends on from which side we are approaching (cf. Figure 14).

4.2.3 The more general special case µ R ∈ In Section 4.2.2, we considered arbitrary complex values for µ and derived a general formula for y depending on λ and µ (cf. Equation 10). That formula is an essential ingredient for a deeper understanding of the dynamics we observe from the real perspective, e.g. in a dynamic geometry system like Cinderella 2 [12]. In Section 4.2.1, we have already treated the special case µ = 0. There we talked about the experiment of moving a circle along a line through the centre of another circle of equal radius while following what happens to the points of intersection of the two circles. We found that the two points of intersection do not exchange their roles of being the upper or lower intersection when we cross the geometric singularity, i.e. the degenerate situation in which the two circles

38 coincide. Furthermore, we remarked that this behaviour corresponds to a removable singularity at λ = 0. The availability of Equation 10 and our visualization software enables us to extend this experiment. We will now discuss what happens if the line along which we move the circle does not run through the centre of the other circle, but passes closely above (or below) that centre. Hence, we will restrict ourselves to real values of µ for the rest of this subsection. Additionally, we shall not be concerned with values of µ s.t. µ 2, | | ≥ since this would yield only a single real double point or no real intersections at all. The experiment itself is thus limited to the real perspective. However, we will exploit our knowledge about its complex background to explain what can be experienced. We suggest the reader now either carries out the experiment themselves or refers to Figure 15. Before we deal with the results of our extended experiment, we better explain how the visualization is obtained from Equation 10. In order to make Equation 10 accessible to λ Algorithm 1, we bring it into the form f + √g. To that end, we put 2 under the square root:

(10) µ λ 4 λ2 µ2 µ λ2 4 λ2 µ2 y = −2 −2 = −2 −2 2 ± 2 s λ + µ 2 ± r 4 s λ + µ

( ) µ λ2 4 λ2 µ2 µ λ2 λ2 =∗ − − = 2 ± s 4 · λ2 + µ2 2 ± sλ2 + µ2 − 4

The transformation is somewhat subtle, insofar as the starred equality holds only set-wise, i.e.

µ λ2 4 λ2 µ2 µ λ2 4 λ2 µ2 −2 −2 , + −2 −2 ( 2 − r 4 s λ + µ 2 r 4 s λ + µ ) µ λ2 4 λ2 µ2 µ λ2 4 λ2 µ2 = −2 −2 , + −2 −2 , ( 2 − s 4 · λ + µ 2 s 4 · λ + µ ) but not necessarily branch-wise. Generally, √a √b = √a b only holds if at least one of · · a,b is non-negative, particularly real-valued. Wrongly assuming the law for any a,b C ∈ yields the following “proof” that 1 = 1 (cf. [14, Chapter VI, Section I.2, p. 37]): − ( ) 1= i i = √ 1√ 1 =∗ ( 1) ( 1) = √1 = 1 − · − − − · − The “proof” fails to hold at the starred equality.p Regardless of how we choose the branch cut of the complex square root, the branch containing 1 = ( 1) ( 1) cannot contain − · − 1= √ 1 √ 1 as well. Therefore, we actually needed the negative branch on the r.h.s. − − · − p of the starred equation. λ In other words, if we transform Equation 10 by putting 2 under the square root, we change the set of values which belong to the positive and to the negative branch

39 Figure 15: Another experiment in dynamic geometry: We move a circle (blue) along a line which passes closely above the midpoint of another circle of equal radius (black) and observe what happens to the intersections of the two circles (red and green points). When we move through the singular situation, where both intersections possess the same y-coordinate, the two points exchange their roles of being the upper/lower point of intersection. of y, respectively. The transformation is feasible, since by considering both branches simultaneously, we do not change y in its entirety. Thus, we have

µ λ2 λ2 y = . (11) 2 ± sλ2 + µ2 − 4

In our case, the reassignment of branches even turns out to be beneficial. Before the transformation, which branch corresponded to which point of intersection depended on the sign of the real part of λ. In Equation 11, independently of λ, the positive branch corresponds to the upper point of intersection, and the negative branch corresponds to the lower point of intersection of the two circles. Now let us return to our extended experiment. If we move a circle along a line which runs closely above the centre of another circle of equal radius while tracing the intersections of the two circles, we observe what follows (cf. Figure 15): When we move through the singular situation, where both intersections possess the same y-coordinate, the two points exchange their roles of being the upper/lower point of intersection. In contrast, if the line along which we move the circle runs exactly through the centre of the resting circle as in our first experiment, the two points do not exchange their roles (cf. Section 4.2.1). Why is this so? In answering the question, our visualization software proves extremely helpful. Using Equation 11, we obtain the images of Riemann surfaces underlying y for different fixed values of µ which are shown in Figure 16. Looking at Figure 16c–16f, we see that for 1 µ = 2 and µ = 1 a linear branch cut occurs around the origin at Re λ = 0. Who would have guessed that simply by looking at the algebraic representation of Equation 11? From the real perspective, Re λ = 0 is exactly where we observe the geometric singularity and the two points of intersection exchange their roles. They do exchange their roles because – as we now see from the complex viewpoint of our visualization – at λ =0 we are crossing a branch cut. For small real µ, our Riemann surface is almost vertical at Re λ = 0. This corresponds to the fact that the closer the line along which we move the circle is to the centre of the resting circle, the faster the two intersections exchange their roles when we cross the geometric singularity. As µ increases, the Riemann surface gets flatter and flatter at Re λ = 0 until for µ> 2, there are no real intersections which we could observe from the real perspective.

40 (a) µ = 0 (b) µ = 0

1 1 (c) µ = 2 (d) µ = 2

(e) µ = 1 (f) µ = 1

Figure 16: Two perspectives of a Riemann surface underlying the intersection of two circles for different parameter values.

In order to facilitate comparison, the perspective of the images in the left column of Figure 16 matches that of Figure 13a, and the perspective of the images in the right column of Figure 16 matches that of Figure 13b.

41 Apparently, the branch cut at Re λ = 0 connects the poles at iµ (which are branch ± points) and the branch point at the origin. Therefore, the length of the branch cuts is iµ , or µ for µ R. For µ = 0, the scenario of our first experiment, the branch cuts | | | | ∈ collapse into the removable singularity at λ = 0. Since we are then no longer crossing a branch cut at λ = 0, the two intersections no longer exchange their roles. Finally, to convince everyone who does not light-heartedly trust visual proofs, let us work out the branch cuts from Equation 11. Again, for the real perspective of our extended experiment, let µ [0, 2). With respect to Equation 11, the branch cuts of y ∈ are those of the involved square root expression. Our square root carries the canonical branch cut along the negative real axis. Therefore, branch cuts occur at λ,µ which yield a negative, particularly real, radicand. Given µ (0, 2) and λ C, we would like to ∈ ∈ reduce the inequality λ2 λ2 < 0, λ2 + µ2 − 4 but, without the additional visual clue given by our visualization, it is unclear how to continue. Since we are in the lucky position to know what we are looking for, namely a branch cut along the (Im λ)-axis, let λ = il iR. Then ∈ λ2 λ2 l2 l2 < 0 − + < 0 4 ( l2 + µ2) λ2 + µ2 − 4 ⇔ l2 + µ2 4 |· · − − 2 2 2 2 2 2 4l + l ( l + µ ) < 0 if l + µ > 0, 2 − 2 2 − 2 2 − 2 2 l− > 0 ⇔ ( 4l + l ( l + µ ) > 0 if l + µ < 0 |· − − − µ2 4 l2, 2 − 2 2 2 ⇔ (µ 4 >l if µ

4.3 Angle bisectors of a triangle As a third and last scenario, we discuss angle bisectors of a triangle. In Section 1.2, we mentioned that the angle bisector of two lines is an ambiguous operation. Let those lines be denoted by g and h. Then there are two angle bisectors at their point of intersection: one bisecting ∠(g,h), the counterclockwise angle between g and h, and a perpendicular one bisecting ∠(h,g)= π ∠(g,h), the adjacent angle. Likewise, the angle bisectors of a − triangle are ambiguous. Let A, B, and C denote the vertices of a triangle, ∆ABC. Then we can take two angle bisectors at each of A, B, and C, namely those of the lines spanned

42 E2

F 2 C

D E1

a F1 b

Figure 17: A ruler-and-compass construction of angle bisectors (green) of two lines (blue). by the edges of ABC. At every vertex, we distinguish between inner angle bisector and outer angle bisector. The inner angle bisector shall be the angle bisector which intersects the interior of the convex hull of A, B, and C. The outer angle bisector shall be the other angle bisector. Let a,b, and c denote the lines through the edges of ∆ABC opposite of A, B, and C, respectively. In what follows, we analyze the dynamic behaviour of the angle bisectors of a triangle ∆ABC under movement of one of its vertices. By symmetry (up to similarity transforma- tions), we may w.l.o.g. consider A := (0, 0) and B := (1, 0) fixed points, and C := (µ,λ) movable.

4.3.1 The angle bisectors at C We will at first restrict ourselves to the angle bisectors at C, the vertex which we move. Since our visualization algorithm (cf. Algorithm 1) takes a multivalued function whose values are (complex) one-dimensional, we need to find a scalar representation of the angle bisectors. A suitable characteristic is easily identified: the angle bisectors at C are uniquely determined by their slope m R . Let the slope of vertical lines be . C ∈ ∪ ∞ ∞ For all other lines, the slope is defined by rise over run, as usual. Recall a typical ruler-and-compass construction of an angle bisector of two lines a and b which intersect each other in C (cf. Figure 17): Draw a circle centred at C. Let D,E be points of intersection of the circle with a and b, respectively. Draw two circles through C centred at D and E. Clearly, they intersect in C and in another point, which we denote by F . Then CDFE is a rhombus whose diagonal through C and F is an angle bisector at C. The freedom of choice of D and E among the intersections of the circle centred at C with a, b yields the ambiguity of the angle bisector. If we leave D fixed and change our choice of E, we obtain the other angle bisector. Let us imitate the above construction algebraically to derive an algebraic expression for the slopes of inner and outer angle bisector of ∆ABC at C. The directions in which b and a extend from C to A and B, respectively, are given by the vectors A C and A C B C − B C. We choose D := − and E := − , where denotes the Euclidean norm. − A C B C k · k D and E are unit vectorsk –− w.r.t.k the abovek − construction,k they point from C to points of

43 intersection of a unit circle around C with b and a. Let F := D + E be the vector sum of D and E. Then C, C +D, C +F , and C +E form a rhombus, as in the above construction. Consequently, F points in the direction of an angle bisector at C. We obtain the direction of the other bisector at C by inverting the direction of E, i.e. as D E. The slopes of − the angle bisectors at C can be computed by dividing the y-coordinate (rise) of D E ± by its x-coordinate (run). Taking into account our specialization (w.l.o.g.) of A = (0, 0), B = (1, 0), and C =(µ,λ), we arrive at the following expression for D E: ± A C B C D E = − − ± A C ± B C k − k k − k 1 µ 1 1 µ = − − µ2 + λ2 λ ± (µ 1)2 + λ2 λ −  −  −  p p µ√(µ 1)2+λ2 (1 µ)√µ2+λ2 − − ± − √µ2+λ2√(µ 1)2+λ2 =  −  λ√(µ 1)2+λ2 ( λ)√µ2+λ2 − − ± −  √µ2+λ2√(µ 1)2+λ2   −    For the slopes, we obtain

λ (µ 1)2 + λ2 ( λ) µ2 + λ2 − − ± − µ (µ 1)2 + λ2 (1 µ) µ2 + λ2 − p − ± − p p p λ (µ 1)2 + λ2 ( λ) µ2 + λ2 µ (µ 1)2 + λ2 (µ 1) µ2 + λ2 = − − ± − − ∓ − µ (µ 1)2 + λ2 (1 µ) µ2 + λ2 · µ (µ 1)2 + λ2 (µ 1) µ2 + λ2 − p − ± − p p − ∓ − p p p p p (λ (µ 1)2 + λ2 λ µ2 + λ2)(µ (µ 1)2 + λ2 (µ 1) µ2 + λ2) = − ± − ∓ − (µ (µ 1)2 + λ2)2 ((µ 1) µ2 + λ2)2 p −p −p − p p p µ2 + µ + λ2 (µ2 + λ2)((µ 1)2 + λ2) = − ± − =: m . (12) (2µ 1)λ C p −

We want that the positive (negative) branch of mC corresponds to the slope of the inner (outer) angle bisector of oriented triangle ∆ABC at C. By comparing the values of mC for C =(µ,λ)=( 1 1 , 1) with the slopes in the respective constructions, we realize 2 ± 4 ± that mC already exhibits the desired branching behaviour. In other words, we need not put any part of the denominator under the square root.

44 The branch points of mC are those points (µ,λ) at which the radicand of mC vanishes. Therefore, m has branch points at λ = iµ and at λ = i(µ 1). For µ 0, 1 , we C ± ± − 6∈ { 2 } have µ2 + µ + λ2 (µ2 + λ2)((µ 1)2 + λ2) lim mC = lim − ± − λ iµ λ iµ (2µ 1)λ → → p − µ2 + µ µ2 (µ2 µ2)((µ 1)2 µ2) = − − ± − − − (2µ 1)iµ p − 2µ2 + µ (2µ 1)µ = − = − − = i (2µ 1)iµ (2µ 1)iµ − − and, analogously,

lim mC = i. λ iµ − →− For µ 1 , 1 , we obtain 6∈ { 2 } µ2 + µ + λ2 (µ2 + λ2)((µ 1)2 + λ2) lim mC = lim − ± − λ i(µ 1) λ i(µ 1) (2µ 1)λ → − → − p − µ2 + µ (µ 1)2 (µ2 (µ 1)2)((µ 1)2 (µ 1)2) = − − − ± − − − − − (2µ 1)i(µ 1) p − − µ2 + µ (µ 1)2 (2µ2 3µ + 1) (2µ 1)(µ 1) = − − − = − − = − − − = i (2µ 1)i(µ 1) i(2µ 1)(µ 1) i(2µ 1)(µ 1) − − − − − − and, analogously,

lim mC = i. λ i(µ 1) − →− − The branch points of m at µ 0, 1 , λ = iµ, and at µ 1 , 1 , λ = i(µ 1), C ∈ { 2 } ± ∈ { 2 } ± − are essential singularities of mC ! In particular, A and B are essential singularities of mC . (They are so-called transcendental branch points.) Here we only analyze the singularity at A. The rest follows analogously. Recall that an essential singularity is characterized by the fact that the limit as we approach the singularity depends on from which direction we are approaching. Suppose we are heading towards A from (x,y) C2 (0, 0) . We ∈ \{ } can formalize this by substituting µ =0+ αx, λ =0+ αy, α R and considering the ∈ >0 limit of m for α 0. This yields C → α2x2 + αx + α2y2 (α2x2 + α2y2)((αx 1)2 + α2y2) lim mC = lim − ± − α 0 α 0 (2αx 1)αy µ=→αx → p − λ=αy αx α (x2 + y2)((αx 1)2 + α2y2) x x2 + y2 = lim ± − = ± . α 0 (2αx 1)αy y → p − p−

45 (a) µ = 0

1 (b) µ = 4

1 (c) µ = 2

Figure 18: The behaviour of the angle bisectors of ∆ABC at C (green and red) when C crosses the x-axis at different positions, as observed from the real perspective.

If we approach A vertically, e.g. from (x,y) = (0, 1), it looks like a removable discontinuity with m = 1. This agrees with the behaviour which we observe from the real perspective C ∓ (cf. Figure 18a). If on the other hand we approach A horizontally, e.g. from (x,y) = (1, 0), it looks like a pole in the positive branch and like a zero in the negative branch. There are more positions where mC exhibits a pole in one branch and a zero in the other branch, regardless of the direction of approach: at λ = 0, µ 0, 1 , and at 1 6∈ { } µ = 2 . Here we do not elaborate this explicitly. Rather, we point out that this matches the behaviour which we observe from the real perspective. Asymptotically, for λ 0, → µ 0, 1 , the inner angle bisector at C becomes vertical as the angle which it bisects 6∈ { } approaches π; at the same time, the outer angle bisector becomes horizontal as the 1 adjacent angle approaches 0 (cf. Figure 18b). For µ = 2 , we obtain an isosceles triangle ∆ABC. Independently of λ, the inner bisector at C is vertical, and the outer bisector at C is horizontal (cf. Figure 18c). Looking at Figure 18, we see that the angle bisectors of ∆ABC at C exchange their roles of being inner/outer angle bisector, if we move C through A, but not if C crosses 1 1 the x-axis at x = 4 or at x = 2 . We may thus ask ourselves: Under which movement of C in the real plane do the angle bisectors of ∆ABC at C exchange their roles of being

46 inner/outer angle bisector? Since by construction the positive (negative) branch of mC corresponds to the slope of the inner (outer) angle bisector, this question asks for the branch cuts of mC . Recall that our complex square root function carries the canonical branch cut along the negative real axis. Therefore, the branch cuts of mC run along those values of µ, λ, at which the radicand of m , (µ2 + λ2)((µ 1)2 + λ2), is negative. C − For µ,λ R, the radicand is always non-negative. This means the branch cuts touch ∈ the real plane only at the real branch points of mC , i.e. at A and B, where the radicand vanishes. Indeed, for µ 0, 1 , λ = iy, we have ∈ { } (µ2 + λ2)((µ 1)2 + λ2) < 0 − (µ2 y2)((µ 1)2 y2) < 0 ⇔ − − − y4 + y2( 2µ2 + 2µ 1) + µ2(µ 1)2 < 0 ⇔ − − − 0 < y < 1 ⇔ | | All in all, when we move C in the real plane, the angle bisectors at C exchange their roles of being inner/outer angle bisector if and only if we move C through A or B, where we cross a branch cut of mC . Hence, if we construct one angle bisector of a triangle ∆ABC at C and move C through A or B and back to its original position, we experience monodromy: The role of the angle bisector in the final configuration differs from that in the initial configuration, although the positions of C are the same. You should try this in Cinderella 2. For our visualization, we interpret mC as a family of multivalued functions in λ, parametrized by µ (in analogy to the scenario of two intersecting circles). This means that we restrict ourselves to moving C along vertical lines x = µ. Note that mC as in Equation 12 does not have the form f √g expected by Algorithm 1, but rather the f √g ± ± form h . Luckily, we can adapt our visualization algorithm to handle the more general form by inserting the appropriate division step right after the branching decision, i.e. between lines 12 and 13 of Algorithm 1. The Riemann surface which we thus obtain is depicted in Figure 19. Admittedly, it was a bit tedious to work out the branch points and singularities of mC algebraically. Why did we not simply read off the properties of mC which determine the dynamic behaviour of the angle bisectors at C from our visualization? Because we had possibly missed an important detail. The branch cuts of mC w.r.t. Equation 12 cannot be identified only by looking at Figure 19! In contrast to earlier examples presented in this thesis, the positive (negative) branch of Equation 12 does not simply correspond to the upper (lower) half of the Riemann surface. From Figure 19 we can easily read off poles, zeros and (algebraic) branch points of mC . If we want to determine the branch cuts, we must either look at each sheet separately (by adapting the loop in line 7 of Algorithm 1) or highlight the branch cut using a special colour at points where the radicand has negative real part and small absolute imaginary part. The latter approach is shown in Figure 20.

47 (a) µ = 0 (b) µ = 0

1 1 (c) µ = 4 (d) µ = 4

Figure 19: Two perspectives of a Riemann surface underlying the slopes of the angular bisectors of ∆ABC at C for different parameter values.

48 (a) µ = 0 (b) µ = 0

Figure 20: Two perspectives of a Riemann surface underlying the slopes of the angular bisectors of ∆ABC at C. The branch cut can be made visible by highlighting it in a different colour (here: red).

4.3.2 Interaction with the angle bisectors at A and B

Analogously to the derivation of mC , we can compute algebraic expressions for the slopes of the angle bisectors of ∆ABC at A and B. We obtain λ mA = (13) µ µ2 + λ2 ± p and

λ mB = . (14) µ 1 (µ 1)2 + λ2 − ± −

Essentially, we can analyze and visualize pmA and mB analogously to our treatment of mC in Section 4.3.1. In order not to repeat ourselves more than is necessary, here we focus on branching behaviour. By comparing function values and slopes for several instances of our construction, we find that in both Equation 13 and Equation 14 the positive (negative) branch corresponds to the inner (outer) angle bisector at A and B, respectively. mA has branch points at λ = iµ. m has branch points at λ = i(µ 1). As we discussed in Section 4.3.1, the ± B ± − branch points of mA and mB are branch points of mC . Conversely, every branch point of mC is a branch point of either mA or mB. Therefore, if we move C such that the angle bisectors at C exchange their roles of being the inner/outer angle bisector, so do the angle bisectors at either A or B, and vice versa. In other words, if we move C then the

49 C C

B

A A B

(a) (b)

Figure 21: An example of unreachability: two configurations of angle bisectors of a triangle which cannot be continuously transformed into each other by moving the vertices of the triangle around. angle bisectors of ∆ABC exchange their roles in pairs or not at all. By symmetry, this also holds if we leave C fixed and instead move either A or B. Consequently, we obtain a reachability result: Suppose we construct one angle bisector at each vertex of a triangle ∆ABC. Two instances of the construction can be continuously transformed into each other by moving the vertices around if and only if they differ in the roles of an even number of angle bisectors. An example of two instances which are not continuously connected is depicted in Figure 21.

5 Outlook

As with every publication, only a snapshot of the current state of work can be presented. Future work cannot be included. Possibly, there will always be some issues that remain to be addressed. At times, this makes it difficult to decide when to stop writing. But, to quote J¨urgen Richter-Gebert, “better” is the worst enemy of “good”. In what follows, we summarize what we have achieved so far. Afterwards, we provide possible directions for further research. The goal of this thesis has been to contribute to a better understanding of dynamic geometry by making the complex configuration space of certain constructions accessible to visual exploration in real-time. We have explained how the ambiguity of multivalued basic geometric operations can be formalized by means of Riemann surfaces for the corresponding algebraic expressions. In Section 3, we have developed a method for real- time visualization of Riemann surfaces behind certain constructions and have discussed its implementation using OpenGL. Particularly, we have used domain colouring and a discrete local version of complex tracing to obtain a faithful representation of the topology and geometry of those surfaces. Our visualization has turned out to be very useful for the analysis of elementary geometric constructions in Section 4.

50 In fairness, after having advertised the assets of our approach, we also need to mention two defects of our visualization algorithm. Firstly, there is an unresolved boundary case in our discrete local tracing strategy. It creates holes in the Riemann surface near branch points, where we cease to join one sheet to the other. Maybe the reader can spot such holes if they look sharply at the origin in Figure 16c and Figure 16e. Since the holes are reasonably small given a suitable mesh quality, we have decided to currently not invest the extra effort to fill them. Secondly, undesired blackness occurs in some situations due to the automatic fragment interpolation of OpenGL. For example, this can be seen in Figure 10a. Such blackness also occurs along the branch cut of our Riemann surface for the complex square root, if we choose an even number of subdivision steps in our input mesh. Then the branch cut does not cross triangles of the mesh, but runs along edges of the mesh. In that case, the problem can be avoided simply by choosing an uneven number of subdivision steps. The author’s guess is that, more generally, the problem might be amended by computing per-vertex normals instead of relying on the per-face normals which OpenGL automatically generates. Regarding possible directions for future research, we can think of many ways how the visualization algorithm could be extended. A generalization of discrete local tracing could be derived for functions which are not of the form f √g. We encountered functions of f √g ± ± h the form h and of the form f √g in Section 4.3. These can be handled by introducing an appropriate division step after± the branching decision. A more general approach is essential if we want to apply our visualization algorithm to geometric operations with more than two possible outputs. For example, there are four common tangents of two circles. To carry the thought a bit further, we would ultimately like to study arbitrary constructions, not just a bunch of precomputed scenarios, whose corresponding algebraic expressions were worked out manually. Particularly, algorithms for the analysis of branching and monodromy behaviour should be invented. Further work in this area will be done in project B1 of the upcoming transregional collaborative research centre “Discretization in Geometry and Dynamics” (DFG SFB/Transregio 109).

51 References

[1] M. Abramowitz and I. A. Stegun, Handbook of Mathematical Functions: with Formulas, Graphs, and Mathematical Tables, Dover, 1964. [2] W. Fischer and I. Lieb, Ausgew¨ahlte Kapitel aus der Funktionentheorie, Vieweg, Braunschweig, 1988. [3] E. Freitag, Complex Analysis 2: Riemann Surfaces, Several Complex Variables, Abelian Functions, Higher Modular Functions, Springer, Heidelberg, 2011. [4] R. C. Gonzalez and R. E. Woods, Digital Image Processing, 3rd ed., Prentice Hall, Upper Saddle River, NJ, 2008. [5] K. J¨anich, Funktionentheorie: Eine Einf¨uhrung, 6th ed., Springer, Heidelberg, 2008. [6] B. W. Kernighan and D. M. Ritchie, The C Programming language, 2nd ed., Prentice Hall, 1988. [7] S. Kivel¨a, On the Visualization of Riemann Surfaces, The Mathematica Journal 11 (2010), no. 3, available at http://dx.doi.org/doi:10.3888/tmj.11.3-6. [8] U. Kortenkamp, Foundations of Dynamic Geometry, dissertation, ETH Z¨urich, Zurich, 1999. [9] U. Kortenkamp and J. Richter-Gebert, Decision Complexity in Dynamic Geometry, Automated Deduction in Geometry (J. Richter-Gebert and D. Wang, eds.), Lecture Notes in Artificial Intelligence, vol. 2061, Springer, Heidelberg, 2001, pp. 216–220. [10] , Grundlagen dynamischer Geometrie, Zeichnung – Figur – Zugfigur: Mathematische und didaktische Aspekte dynamischer Geometrie-Software (H.-J. Elschenbroich, Th. Gawlick, and H.-W. Henn, eds.), Franzbecker, Hildesheim, 2001, pp. 123–145. [11] , Complexity issues in dynamic geometry, Festschrift in the honor of Stephen Smale’s 70th birthday (M. Rojas and F. Cucker, eds.), World Scientific, 2002, pp. 355–404. [12] , Cinderella: The interactive geometry software, 2006. http://www.cinderella.de. [13] G. E. Martin, Geometric Constructions, Undergraduate Texts in Mathematics, Springer, New York, 1997. [14] E. A. Maxwell, Fallacies in Mathematics, Cambridge University Press, Cambridge, 1959. [15] T. Needham, Visual Complex Analysis, Oxford University Press, Oxford, 1997. [16] M. Nieser, K. Poelke, and K. Polthier, Automatic Generation of Riemann Surface Meshes, Advances in Geometric Modeling and Processing, 2010, pp. 161–178. [17] K. Poelke and K. Polthier, Lifted Domain Coloring, Computer Graphics Forum 28 (2009), no. 3, 735–742. [18] J. Richter-Gebert, Perspectives on Projective Geometry: A Guided Tour through Real and Complex Geometry, Springer, Berlin, 2011. [19] B. Riemann, Grundlagen f¨ur eine allgemeine Theorie der Functionen einer ver¨anderlichen complexen Gr¨osse, dissertation, G¨ottingen, 1851. [20] R. J. Rost and B. Licea-Kane, OpenGL Shading Language, 3rd ed., with contributions by D. Ginsburg, J. M. Kessenich, B. Lichtenbelt, H. Malan, and M. Weiblen, Addison-Wesley, Boston, July 30, 2009. [21] K. Shoemake, Arcball Rotation, Graphics Gems IV (P. S. Heckbert, ed.), Academic Press, Boston, 1994, pp. 175–192. [22] D. Shreiner, OpenGL programming guide: The Official Guide to Learning OpenGL, Version 3.0 and 3.1, 7th ed. (The Khronos OpenGL ARB Working Group, ed.), Addison-Wesley, Amsterdam, 2009. [23] M. Trott, The Return of the Riemann Surface, The Mathematica Journal 10 (2008), no. 4, available at http://dx.doi.org/doi:10.3888/tmj.10.4-1. [24] H. Weyl, Die Idee der Riemannschen Fl¨ache, Mathematische Vorlesungen an der Universit¨at G¨ottin- gen, vol. 5, Teubner, Leipzig, 1913.

52