51

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

enter image description here

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.

enter image description here

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.

enter image description here

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.

JDH
  • 45,373
  • See further discussion, links and images on https://twitter.com/JDHamkins/status/1179028081836744705. – JDH Oct 02 '19 at 12:53
  • It might help if people double-check the 203 number, since it is easy to miscount, and also help verify that the figure indeed shows all the relevant lines and circles. – JDH Oct 02 '19 at 13:20
  • 2
    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. – Intelligenti pauca Oct 03 '19 at 10:18
  • @Aretino Great! I am very pleased. Andrej Bauer also reports having done the same thing in the conversation on the Twitter feed https://twitter.com/andrejbauer/status/1179674591477796865. – JDH Oct 03 '19 at 11:27
  • 1
    Here's the gist to my notebook, if anyone cares. I have to put this on hold, but an obvious improvement would be to use PossibleZeroQ with the option Method->"ExactAlgebraics". – Andrej Bauer Oct 03 '19 at 13:43
  • Incidently, using the 203 points, we may construct 20503 many lines and twice this many circles, or 61509 lines and circles. By consideing pairs of these, and noting at most two new points from each pair, we have an upper bound of 3783295572 for the fourth constructibility number. Not even four billion! – JDH Oct 03 '19 at 15:28
  • But there is good reason to think that it will be considerably less. – JDH Oct 03 '19 at 15:43
  • 2
    Even if it is 1000 times smaller, it's still too big for a naive Mathematica program. – Andrej Bauer Oct 03 '19 at 16:37
  • I see, that's too bad. – JDH Oct 03 '19 at 16:41
  • 2
    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. – Andrej Bauer Oct 03 '19 at 22:41
  • @JDH Looking at your graph, it appears that you are only allowing circles with radii equal to the distance from the center of the circle to another constructed point. The way I learned this subject, we were allowed to use any two points to fix the radius of the compass, and then center the compass at any other given point. Is it easy to see that your process still gets all of the constructible numbers? – Pace Nielsen Oct 04 '19 at 20:54
  • 6
    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 04 '19 at 20:54
  • 1
    https://en.m.wikipedia.org/wiki/Compass_equivalence_theorem – JDH Oct 04 '19 at 20:58
  • @JDH In light of that theorem, wouldn't it then be more parsimonious to just use the sequence of points you get from collapsible compass constructions alone (without a straightedge)? – Pace Nielsen Oct 04 '19 at 21:19
  • 1
    I guess you are referring to the Mohr-Mascheroni theorem, rather than the compass equivalence theorem. That would be an alternative. I find my universal construction the most natural, because it is using the classical tools in the classical manner. – JDH Oct 05 '19 at 07:53
  • 5
    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. – Pace Nielsen Oct 08 '19 at 23:22
  • 1
    Now that I have the full list of curves, it might be possible to use them approximate the number of intersection points. I have some ideas I'm playing with, but I've been running into RAM issues. I'll post more if I can work them out. – Pace Nielsen Oct 08 '19 at 23:25
  • @AndrejBauer any luck? – theHigherGeometer Oct 09 '19 at 07:06
  • 2
    I am looking for a library that computes with constructible numbers. I found one in Haskell. I am still hoping I won't have to do this in Haskell, but I might have to. – Andrej Bauer Oct 09 '19 at 11:03
  • 2
    The exact arithmetic finished, and did show there are exactly 32719 circles. – Pace Nielsen Oct 10 '19 at 14:37
  • @PaceNielsen Fantastic! I would encourage you to post an answer with the exact information about the number of lines and circles. Is there any way you can also make the data available? If also you could mention the floating-point approximations for the intersections, that also would be great. – JDH Oct 10 '19 at 16:09
  • I have now created an OEIS entry for this sequence: https://oeis.org/A333944. – JDH Apr 11 '20 at 14:42
  • Your growth bound should be $\lambda^{\frac{4^n - 1}{3}} , 2^{4^n}$ where $\lambda = 18$ in your case. If you actually use binomial coefficients and also note that two lines intersect in at most one point, then you get $\lambda = \frac{17}{8}$. The recurrence for lines becomes $L_n = \binom{P_{n-1}}{2}$, for circles $C_n = 2\binom{P_{n-1}}{2}$, and for points $P_n = \binom{L_n}{2} + 2\binom{C_n}{2} + 2L_nC_n \approx \lambda ,P_{n-1}^2$. I can sharpen the recurrence a little bit, but not enough to change the leading term (the value of $P_4$ is reduced by a factor of $\sim 2^{10}$). – Andrew Szymczak Mar 17 '21 at 03:26
  • Actually I will mention the sharpened recurrence because I think it's interesting. We note that collinear points only generate one line (similar for circles). Given our line/circle intersection assumption (manifest in the recurrence for $P$), we can actually count the number of points that lie on any given line or circle. This yields $L_n = \binom{P_{n-1}}{2} - L_{n-1} \left[\binom{L_{n-1} , + , 2C_{n-1} , - , 1}{2} - 1\right]$ and $C_n = 2\binom{P_{n-1}}{2} - C_{n-1} \left[2L_{n-1} + 2C_{n-1} - 3\right]$. However, the leading term for $P_n$ remains unchanged, and $P_4 \sim 2^{170}$. – Andrew Szymczak Mar 17 '21 at 04:41
  • Just noticed our indexes are off by one and there is a slight typo in my last comment. My initial conditions are $L(0) = C(0) = 0$ and $P(0) = 2$. Compare the actual values $[2, 6, 203, \sim2^{30}, ?]$ to the bounds $[2, 6, 1077, \sim2^{41}, \sim2^{166}]$ computed with the code. – Andrew Szymczak Mar 20 '21 at 20:31

2 Answers2

17

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: enter image description here If we focus at the area from $0$ to $1$ we get: enter image description here

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.

Teo C
  • 386
  • Do you have any data on the closest that the coordinates of the intersection points get? (Nice idea by the way!) – Pace Nielsen Jan 21 '20 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? – Teo C Jan 21 '20 at 18:31
  • 1
    Is your computation almost done? – Pace Nielsen Mar 16 '20 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 – Teo C Mar 17 '20 at 17:29
  • Yes, my code should have given a lower bound, unless Mathematica was doing something unexpected. – Pace Nielsen Mar 18 '20 at 15:18
  • 1
    @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. – Teo C Apr 03 '20 at 10:41
8

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.

Pace Nielsen
  • 699
  • 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: https://mathematica.stackexchange.com/questions/207351/fast-way-to-count-distinct-pairs-of-integers/207398?noredirect=1#comment533128_207398 – Pace Nielsen Nov 01 '19 at 19:39
  • 1
    Fantastic! I am very grateful for your work. – JDH Nov 01 '19 at 20:55
  • 1
    @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. – Pace Nielsen Nov 01 '19 at 21:07
  • 1
    Ah, I'm sorry I misunderstood. This is progress, but evidently we still have a ways to go. – JDH Nov 01 '19 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. – Pace Nielsen Jan 01 '20 at 03:58