# What is the next number on the constructibility sequence? And what is the asymptotic growth?

Let us systematically generate all constructible points in the plane. We begin with just two points, which specify the unit distance.

With the straightedge, we may construct the line joining them. And with the compass, we may construct the two circles centered at each of them, having that unit segment as radius. These circles intersect each other and the line, creating four additional points of intersection. Thus, we have now six points in all.

Using these six points, we proceed to the next stage, constructing all possible lines and circles using those six points, and finding the resulting points of intersection.

I believe that we now have 203 points. Let us proceed in this way to systematically construct all constructible points in the plane, in a hierarchy of finite stages. At each stage, we form all possible lines and circles that may be formed from our current points using straightedge and compass, and then we find all points of intersection from the resulting figures.

This produces what I call the constructibility sequence:

$$2\qquad\qquad 6\qquad\qquad 203\qquad\qquad ?$$

Each entry is the number of points constructed at that stage. I have a number of questions about the constructibility sequence:

Question 1. What is the next constructibility number?

There is no entry in the online encyclopedia of integer sequences beginning 2, 6, 203, and so I would like to create an entry for the constructibility sequence. But they request at least four numbers, and so we seem to need to know the next number. I'm not sure exactly how to proceed with this, since if one proceeds computationally, then one will inevitably have to decide if two very-close points count as identical are not, and I don't see any principled way to ensure that this is done correctly. So it seems that one will need to proceed with some kind of idealized geometric calculus, which gets the right answer about coincidence of intersection points. [Update: The sequence now exists as A333944.]

Question 2. What kind of asymptotic upper bounds can you prove on the growth of the constructibility sequence?

At each stage, every pair of points determine a line and two circles. And every intersection point is realized as the intersection of two lines, two circles or a line and circle, which have at most two intersection points in each case. So a rough upper bound is that from $$k$$ points, we produce no more than $$3k^2$$ many lines and circles, and so at most $$(3k^2)^2$$ many pairs of line and circles, and so at most $$2(3k^2)^2$$ many points of intersection. This leads to an upper bound of growth something like $$18^n2^{4^n}$$ after $$n$$ stages. Can anyone give a better bound?

Question 3. And what of lower bounds?

I suspect that the sequence grows very quickly, probably doubly exponentially. But to prove this, we would seem to need to identify a realm of construction patterns where there is little interference of intersection coincidence, so that one can be sure of a certain known growth in new points.

• I used Mathematica to check your numbers and can confirm 203 points at third stage. But couldn't find the fourth stage with the same code, it takes too much time. Oct 3, 2019 at 10:18
• Even if it is 1000 times smaller, it's still too big for a naive Mathematica program. Oct 3, 2019 at 16:37
• I am told there's an OCaml library for constructible numbers. That would be fast enough, I am trying to get my hands on it. Oct 3, 2019 at 22:41
• The traditional use of the compass is to place one end on each point and to draw the circle. The compass equivalence theorem asserts that one can also simulate the operation of carrying a radius to another center point, but this takes more steps. So in the universal construction process, those circles come a bit later.
– JDH
Oct 4, 2019 at 20:54
• I've checked that the number of distinct lines on the next step is exactly 17562, using minimal polynomials and exact arithmetic. I double-checked this number using floating point approximations to more than 25 places. I'm currently computing the number of circles. The exact arithmetic will take a bit of time, but the same floating point calculation finishes quickly and gives 32719 circles. Oct 8, 2019 at 23:22

I have written some Haskell code to compute the next number in the constructibility sequence. It's confirmed everything we have already established and gave me the following extra results:

There are $$149714263$$ line-line intersections at the 4th step (computed in ~14 hours). Pace Nielsen's approximation was only off by 8! This includes some points that are between a distance of $$10^{-12}$$ and $$10^{-13}$$ from each other.

I have found the fourth number in the constructibility sequence: $$1723816861$$ I computed this by splitting the first quadrant into sections along the x-axis, computing values in these sections and combining them. The program was not parallel, but the work was split amongst 6 process on 3 machines. It took approximately 6 days to complete and each process never used more than 5GB of RAM.

My data can be found here. I've produced these two graphs from my data, which give a sense of how the points are distributed: If we focus at the area from $$0$$ to $$1$$ we get:

## Implementation Details:

I represent constructible reals as pairs of a 14 decimal digit approximation (using ireal) and a symbolic represenation (using constructible). This is done to speed up comparisons: the approximations give us quick but partial comparisons functions, while the symbolic representation gives us slower but total comparison functions.

Lines are represented by a pair $$\langle m, c \rangle$$ such that $$y = mx + c$$. To deal with vertical lines, we create a data-type that's enhanced with an infinite value. Circles are triples $$\langle a, b, r \rangle$$ such that $$(x-a)^2 + (y-b)^2 = r^2$$.

I use a sweep-line algorithm to compute the number of intersections in a given rectangle. It extends the Bentley-Ottoman Algorithm to allow the checking of intersections between circles as well as lines. The idea behind the algorithm is that we have a vertical line moving from the left to right face of the rectangle. We think of this line as a strictly ordered set of objects (lines and circles). This requires some care to get right. Circles need to be split into their top and bottom semi-circles, and we don't only want to order objects based on their y-coordinates but if they are equal then also their slope and we need to deal with circles that are tangential to each other at a point. The composition or order of this set can change in 3 ways as we move from left to right:

1. Addition: We reach the leftmost point on an object and so we add it to our sorted set.
2. Deletion: We reach the rightmost point on our object and so we remove it from our sorted set.
3. Intersection: Several objects intersect. This is the only way the order of objects can change. We reorder them and note the intersection.

We keep track of these events in a priority queue, and deal with them in the order they occur as we move from left to right.

The big advantage of this alogrithm over the naive approach is that it doesn't require us to keep track of the collision points. It also has the advantage that if we compute the amount of collisions in two rectangles then it is very easy to combine them, since we just need to add the amount of collisions in each, making sure we aren't double counting the borders. This makes it very easy to distribute computation. It also has very reasonable RAM demands. Its RAM use should be $$O(n)$$ where $$n$$ is the amount of lines and circles and the constant is quite small.

• Do you have any data on the closest that the coordinates of the intersection points get? (Nice idea by the way!) Jan 21, 2020 at 15:53
• @PaceNielsen Thanks and also thanks for you work on this! I don't have much data on that, but when I was running line-line intersections, I think I found that 15 digit approximations never disagreed with exact comparisons. After doing some cursory tests it looks like 12 decimal digit approximations get it right for the first couple thousand numbers for lines-lines, so line-line intersections are probably never closer than 10^-12. I'm unsure about the general case but I can try to find some bounds for you after my main computation is done, if you're interested? Jan 21, 2020 at 18:31
• Is your computation almost done? Mar 16, 2020 at 16:21
• Sorry for the delay. My computation has finished, but it gave me an overall number slightly lower than your estimate (which I'm assuming is a lower bound). So, I'm double checking the correctness of my code at the moment. I'll update my post as soon as possible Mar 17, 2020 at 17:29
• @PaceNielsen I've updated my post now with my results. I did some testing and found some bugs in my code, fixed them, and re ran (and got a result which was thankfully greater than yours). There shouldn't be any more bugs since I ran some cohesive randomised testing of my sweep-line algorithm against my naive implementation. I took randomised subsets of the points generated at the 3rd step and checked if they agreed. So, as long as my naive implementation is correct, my sweep-line one should be right too. Apr 3, 2020 at 10:41

Mathematica has a command to solve systems of equations over the real numbers; or one can just solve them equationally. It also has a command to find the minimal polynomial of an algebraic number. Thus intersection points between lines and circles can be found using exact arithmetic (as numbered roots of minimal polynomials over $$\mathbb{Q}$$), as can the slopes of lines and radii of circles. Using such methods, there are exactly 17,562 distinct lines and 32,719 distinct circles on the next stage.

Finding the minimal polynomial of an algebraic number this way is somewhat slow (there may be ways to speed that up), but these lines and circles can also be found in just a few minutes if we instead use (10 digit) floating point approximations.

I've now optimized the code a bit, and using those floating point approximations, in a little under 21 hours I compute that there are at least $$149,714,255$$ distinct intersections between those 17,562 lines. This could be undercounting, because the floating point arithmetic might make us think that two distinct intersection points are the same. However, the computations shouldn't take much longer using 20 digit floating points (but they would take a lot more RAM). I expect that the numbers won't change much, if at all. But I did see changes going from 5 digit to 10 digit approximations, so trying the 20 digit computation would be useful.

Storing those 10 digits, for a little more than hundred million intersection points, was taking most of my RAM. It appears that if I try to do the same computation with the circle intersections, it will exceed my RAM limits. However, it is certainly doable, and I'm happy to give my code to anyone who has access to a computer with a lot of RAM (just email me; my computer has 24 GB, so you'd want quite a bit more than that). The code may still have some areas where it can be sped up--but taking less than 1 day to find all intersection points between lines is already quite nice.

Another option would be to store these points on the hard disk---but there are computers out there with enough RAM to make that an unnecessary change.

Edited to add: I found a computer that is slightly slower than my own but had a lot of RAM. It took about 6 weeks, and about 360 GB of RAM, but the computation finished. It is still only an approximation (not exact arithmetic, only 10 digit precision past the decimal place). The number of crossings I get is $$1,723,814,005$$ If you have a real need to do exact arithmetic, I could probably do that, but it would take a bit longer. Otherwise I'll consider this good enough.

• If there is enough RAM, it may be possible to speed this up even more using the "CountDistinctBy" function. See an answer to my mathematica question here: mathematica.stackexchange.com/questions/207351/… Nov 1, 2019 at 19:39
• Fantastic! I am very grateful for your work.
– JDH
Nov 1, 2019 at 20:55
• @JDH Saw your tweet, and needed to clarify. 149714255 is not the next number in the sequence. It is only (very close to) the number of intersections between the lines on the next step. One would need to do a much more RAM intensive computation to get the extra points from intersections with the circles. It can (and should) be done, but I don't currently have the resources to do it. Nov 1, 2019 at 21:07
• Ah, I'm sorry I misunderstood. This is progress, but evidently we still have a ways to go.
– JDH
Nov 1, 2019 at 21:09
• @JDH I edited the answer to now contain the number you seek (if there are no two points both of whose coordinates are within 10^{-10} of each other). It is 1,723,814,005. Jan 1, 2020 at 3:58