kqueue.org

Correctness of a compiler for arithmetic expressions in Lean

2020-10-15T00:00:00+00:00

“Correctness of a compiler for arithmetic expressions” (McCarthy and Painter 1967) describes the first proof of compiler correctness. To make it easier to play with the proof, I coded it up using the Lean theorem prover.

The Lean code is self-explanatory, so I won’t go into the details here.

Browse the Lean code on GitHub.
Run in the browser (laptop or desktop recommended; tested with Lean/mathlib 3.21.0c).

Lean’s support for calculational proofs is particularly nice for mirroring the proof in the paper. For example, below is an excerpt of the proof in the paper:

\[\begin{aligned} \zeta_1 & = \mathit{outcome}(\mathit{compile}(s1(e),t),\eta) \\ & =_t a(\mathit{ac}, \upsilon_1, \eta) & \textrm{Induction Hypothesis} \end{aligned}\]

Here’s the corresponding part in Lean:

calc ζ₁
    = outcome (compile map e_s₁ t) η : by cc
... ≃[t] {ac := ν₁, ..η}             : by apply e_ih_s₁; assumption

Typos

The reprint version of the paper contains a number of typos (not present in the original version):

Theorem 1: “\(c(\mathit{loc}(v, \eta) = c(v, \xi)\)” should be “\(c(\mathit{loc}(v, \mathit{map}), \eta) = c(v, \xi)\).”
Section 5.III, under “\(\zeta_2 = \mathit{outcome}(\mathit{mksto}(t), \zeta_1)\)”: “\(a(t, \upsilon_1), \zeta_1)\)” should be “\(a(t, \upsilon_1, \zeta_1)\).”
Section 5.III, next to “\(c(\mathit{loc}(\upsilon, \mathit{map}), \zeta_2)\)”: “\(c(\mathit{loc}(\upsilon), \mathit{map})a(t, \upsilon_1, \eta))\)” should be “\(c(\mathit{loc}(\upsilon, \mathit{map}), a(t, \upsilon_1, \eta))\).”

Areas of Napoleon triangles

2020-09-12T00:00:00+00:00

NB: I came across a survey paper (Zhao, 2011) on some plane geometry problems that a group of friends and I explored around 2000. It’s a nice trip down the memory lane. I played with computer-aided proofs using Maxima recently and thought it might be fun to write down the results.

Consider triangle \(ABC\). The centers of equilateral triangles constructed outward on the sides form the outer Napoleon triangle, \(DEF\). Similarly, the centers of equilateral triangles constructed inward on the sides form the inner Napoleon triangle, \(D'E'F'\). Napoleon’s theorem says that both \(DEF\) and \(D'E'F'\) are equilateral, one counterclockwise and the other clockwise.

A particularly interesting property is that the sum of the (signed) areas of \(DEF\) and \(D'E'F'\) equals the area of \(ABC\) (Coxeter and Greitzer, 1967, §3.3). A signed area is positive if the vertices are ordered counterclockwise, and negative if clockwise.

Note that in Napoleon triangle, \(A', B', C'\), the reflections of \(A, B, C\) across \(EF, FD, DE\), respectively, coincide such that \(\mathrm{area}\ A'B'C' = 0\). A general and symmetric form of the areal property is the following:

\[\mathrm{area}\ ABC + \mathrm{area}\ A'B'C' = \mathrm{area}\ DEF + \mathrm{area}\ D'E'F'.\]

This post focuses on generalizations of the areal property.

Antisimilitude and involution

First, we would like to generalize how \(D, E, F\) are chosen. What’s a necessary and sufficient condition for their reflections \(D', E', F'\) across \(BC, CA, AB\), respectively, to form a triangle inversely similar to \(DEF\) (i.e., with the same shape and opposite rotations)?

Zhonghao Ye and Gang Cao (1997) answered this question with the following theorem.

Theorem 1: Consider non-degenerate triangles \(ABC\) and \(DEF\). Let \(A', B', C', D', E', F'\) be the reflections of \(A, B, C, D, E, F\) across \(EF, FD, DE, BC, CA, AB\), respectively.

Triangles \(DEF\) and \(D'E'F'\) ‘are inversely similar if and only if the Möbius transformation that maps \(A, B, C\) to \(D, E, F\) is an involution (or simply, \(A, B, C, D, E, F\) are involutoric).

Let’s start with some definitions. A Möbius transformation is a linear fractional transformation in the following form:

\[\varphi(z) = \frac{\alpha z + \beta}{\gamma z + \delta}.\]

Here \(\alpha, \beta, \gamma, \delta\) are complex numbers such that \(\alpha\delta - \beta\gamma \neq 0\). We use a lowercase letter \(z\) to represent the complex number of the corresponding point \(Z\).

A transformation \(\varphi\) is an involution if \(\varphi(\varphi(z)) = z\). For example, if an involutoric transformation maps \(A\) to \(D\), then it also maps \(D\) to \(A\).

A Möbius transformation is uniquely determined by three pairs of points (Deaux 1956, article 74). When the transformation determined by \((A, D), (B, E), (C, F)\) is an involution, these points satisfy the following (Deaux 1956, article 102):

\[\begin{vmatrix} ad & a + d & 1 \\ be & b + e & 1 \\ cf & c + f & 1 \end{vmatrix} = 0.\]

We use the above definition in the proofs.

A more intuitive way is to rewrite the determinant as:

\[\frac{(a - f)(b - d)(c - e)}{(f - b)(d - c)(e - a)} = -1.\]

Therefore, one may view an involution as a hexagon that satisfy the following properties:

\(\dfrac{AF}{FB} \cdot \dfrac{BD}{DC} \cdot \dfrac{CE}{EA} = 1\);
\(\angle AFB + \angle BDC + \angle CEA = 0\).

We use \(\angle XYZ\) to denote the directed angle from line \(XY\) to line \(YZ\).

With this view, it’s easy to see that below are a few examples of involution:

A triangle \(ABC\) and its outer (or inner) Napoleon triangle \(DEF\);
A triangle \(ABC\) and points \(D, E, F\) on \(BC, AC, AB\), respectively, such that \(AD, BE, CF\) are concurrent (Ceva’s theorem);
A triangle \(ABC\) and points \(D, E, F\) on \(BC, AC, AB\), respectively, such that \(D, E, F\) are collinear (Menelaus’s theorem);
The three pairs of opposite vertices of a complete quadrilateral (Deaux 1956, article 103).

Proof. \(DEF\) inversely similar to \(D'E'F'\) translates to:

\[\begin{vmatrix} d & \overline{d'} & 1 \\ e & \overline{e'} & 1 \\ f & \overline{f'} & 1 \end{vmatrix} = 0.\]

Since \(D'\) is the reflection of \(D\) across \(BC\), we have \(d' = \dfrac{(b - c)\overline{d} + \overline{b}c - b\overline{c}}{\overline{b} - \overline{c}}\). We obtain \(e'\) and \(f'\) similarly. Plug \(d', e', f'\) into the above equation, which simplifies to:

\[\begin{vmatrix} ad & a + d & 1 \\ be & b + e & 1 \\ cf & c + f & 1 \end{vmatrix} \begin{vmatrix} a & \overline{a} & 1 \\ b & \overline{b} & 1 \\ c & \overline{c} & 1 \end{vmatrix} = 0.\]

Since \(ABC\) is a non-degenerate triangle, the above reduces to:

\[\begin{vmatrix} ad & a + d & 1 \\ be & b + e & 1 \\ cf & c + f & 1 \end{vmatrix} = 0.\]

Therefore, a necessary and sufficient condition for \(DEF\) and \(D'E'F'\) to be inversely similar is that \(A, B, C, D, E, F\) are involutoric. Q.E.D.

Note that by symmetry, this is also the necessary and sufficient condition for triangles \(ABC\) and \(A'B'C'\) to be inversely similar.

How are antisimilitude and involution related to the areal property? Below is my answer to this question in a letter to Zhonghao Ye (personal communication, 1999; Zhao, 2011).

Theorem 2: Consider points \(A, B, C, D, E, F\) in the plane. Let \(A', B', C', D', E', F'\) be the reflections of \(A, B, C, D, E, F\) across \(EF, FD, DE, BC, CA, AB\), respectively.

If \(A, B, C, D, E, F\) are involutoric, the sum of the areas of \(ABC\) and \(A'B'C'\) equals the sum of the areas of \(DEF\) and \(D'E'F'\):

\[\mathrm{area}\ ABC + \mathrm{area}\ A'B'C' = \mathrm{area}\ DEF + \mathrm{area}\ D'E'F'.\]

Proof. Suppose the involution determined by \(A, B, C, D, E, F\) is:

\[\varphi(z) = \frac{\alpha z + \beta}{\gamma z + \delta}.\]

This boils down to three cases.

If \(\gamma = 0\), given \(\varphi(\varphi(z)) = z\), this reduces to one of the following:

\(\alpha = \delta, \beta = 0\). In this case, \(\varphi\) reduces to the identity transformation \(\varphi(z) = z\), where \(DEF\) coincides with \(ABC\). We have \(d = a, e = b, f = c\).
\(\alpha = -\delta\). In this case, \(\varphi\) reduces to \(\varphi(z) = -z + {\beta}/{\delta}\), where \(DEF\) is the symmetry of \(ABC\) with respect to point \(\dfrac{\beta/\delta}{2}\). Choose that point as the origin. We have \(d = -a, e = -b, f = -c\).

If \(\gamma \neq 0\), \(\varphi\) has two fixed points \(p_i\) such that \(\varphi(p_i) = p_i (i = 1, 2)\):

WLOG, choose the midpoint of \(p_1, p_2\) as the origin and the unit such that \(p_1 = 1, p_2 = -1\). In this case, \(\varphi\) reduces to \(\varphi(z) = 1/z\). We have \(d = 1/a, e = 1/b, f = 1/c\).

The rest is calculation for each of the three cases. See area.mac in Maxima. Q.E.D.

Concyclicity

Involution is necessary and sufficient for antisimilitude (e.g., \(DEF\) inversely similar to \(D'E'F'\)). It is also sufficient for the areal property, but not necessary, as evidenced by the following theorem.

Theorem 3: Consider points \(A, B, C, D, E, F\) in the plane. Let \(A', B', C', D', E', F'\) be the reflections of \(A, B, C, D, E, F\) across \(EF, FD, DE, BC, CA, AB\), respectively.

If \(A, B, C, D, E, F\) are concyclic, the sum of the areas of \(ABC\) and \(A'B'C'\) equals the sum of the areas of \(DEF\) and \(D'E'F'\):

\[\mathrm{area}\ ABC + \mathrm{area}\ A'B'C' = \mathrm{area}\ DEF + \mathrm{area}\ D'E'F'.\]

Proof. Choose the circle on which \(A, B, C, D, E, F\) all lie as the unit circle.

We have \(\overline{a} = 1/a, \overline{b} = 1/b, \overline{c} = 1/c, \overline{d} = 1/d, \overline{e} = 1/e, \overline{f} = 1/f\).

The rest of the proof is similar to that of Theorem 2. See area.mac. Q.E.D.

Theorems 2 and 3 indicate that to unify the areal property for both involutoric and cyclic cases, a property “weaker” than antisimilitude is needed, as detailed next.

Hexagons with opposite sides parallel

Yong Zhao (2011) described several new results regarding the areal property.

First, Yong Zhao considered the hexagon formed by \(A_1, B_1, C_1, D_1, E_1, F_1\), the feet of the altitudes from \(A, B, C, D, E, F\) to \(EF, FD, DE, BC, CA, AB\), respectively: if \(A, B, C, D, E, F\) are involutoric, the opposite sides of hexagon \(A_1F_1B_1D_1C_1E_1\) are parallel (not necessarily equal in length): \(A_1F_1 \parallel D_1C_1, F_1B_1 \parallel C_1E_1, B_1D_1 \parallel E_1A_1\).

Second, it’s straightforward to show that if \(A, B, C, D, E, F\) are concyclic, the opposite sides of hexagon \(A_1F_1B_1D_1C_1E_1\) are also parallel.

Third, the hexagon with opposite sides parallel has the following property:

\[\mathrm{area}\ A_1B_1C_1 = \mathrm{area}\ D_1E_1F_1.\]

Zhouxing Mao further derived an alternative proof of Theorem 2 using the above property, demonstrating the connection between the areal property and the hexagon with opposite sides parallel.

Therefore, the key is to find a necessary and sufficient condition for the opposite sides of hexagon \(A_1F_1B_1D_1C_1E_1\) to be parallel.

Libing Huang conjectured the following:

Theorem 4. Consider distinct points \(A, B, C, D, E, F\) in the plane. Let \(A_1, B_1, C_1, D_1, E_1, F_1\) be the feet of the altitudes from \(A, B, C, D, E, F\) to \(EF, FD, DE, BC, CA, AB\), respectively.

The opposite sides of hexagon \(A_1F_1B_1D_1C_1E_1\) are parallel if and only if \(A, B, C, D, E, F\) are either involutoric or concyclic.

Libing Huang mentioned that he had a computer-aided proof but didn’t provide details. Below I’ll describe a proof in Maxima.

Proof. The proof of the sufficient condition is similar to those of theorems 2 and 3. Let’s focus on the necessary condition.

Since \(A_1\) is the midpoint of \(A\) and \(A'\) (the reflection of \(A\) across \(EF\)), we have:

\[a_1 = \frac{a + a'}{2} = \frac{a(\overline{e} - \overline{f}) + \overline{a}(e - f) + \overline{e}f - e\overline{f}} {2(\overline{e} - \overline{f})}.\]

We obtain \(b_1, c_1, d_1, e_1, f_1\) similarly.

\(A_1F_1 \parallel D_1C_1\) translates to:

\[(a_1 - f_1)(\overline{d_1} - \overline{c_1}) - (\overline{a_1} - \overline{f_1})(d_1 - c_1) = 0.\]

Plug \(a_1, c_1, d_1, f_1\) into the above equation, we have:

\[\left[(a - b)(\overline{e} - \overline{f}) + (\overline{a} - \overline{b})(e - f)\right] \left[(b - c)(\overline{d} - \overline{e}) + (\overline{b} - \overline{c})(d - e)\right] p_1 = 0.\]

The detail of \(p_1\) is omitted due to the complexity (120 subexpressions!). The other two expressions correspond to the degenerate cases, \(AB \bot EF\) (\(A_1\) coincides with \(F_1\)) and \(BC \bot DE\) (\(D_1\) coincides with \(C_1\)), which we don’t consider. Therefore, the above equation simplifies to \(p_1 = 0\).

Similarly, from \(F_1B_1 \parallel C_1E_1\) we obtain \(p_2 = 0\) (details omitted).

Eliminating \(\overline{d}\) from \(p_1 = 0, p_2 = 0\) gives the following two cases:

\[\begin{vmatrix} ad & a + d & 1 \\ be & b + e & 1 \\ cf & c + f & 1 \end{vmatrix} = 0\] \[\left(c - a\right)\left(f - b\right)\left(\overline{c} - \overline{b}\right)\left(\overline{f} - \overline{a}\right) - \left(\overline{c} - \overline{a}\right)\left(\overline{f} - \overline{b}\right)\left(c - b\right)\left(f - a\right) = 0.\]

The first corresponds to the case where \(A, B, C, D, E, F\) are involutoric. The second corresponds to the case where \(A, B, C, F\) are concyclic; similarly, we obtain that \(A, B, C, D\) and \(A, B, C, E\) are concyclic, together implying that \(A, B, C, D, E, F\) are concyclic. See parallel.mac in Maxima for the complete proof. Q.E.D.

Summary

Below is a list of the Maxima files used in this post.

Common library: geometry.mac (see Automated geometry bashing)
Proof of Theorems 2 and 3: area.mac
Proof of Theorem 4: parallel.mac

Acknowledgments: Zhonghao Ye provided a copy of my original proof of Theorems 2 and 3. Zhilei Xu provided feedback on a draft of this post.

References

H. S. M. Coxeter and S. L. Greitzer. (1967). Geometry Revisited. The Mathematical Association of America.
Roland Deaux. 1956. Introduction to the Geometry of Complex Numbers. Translated by Howard Eves.
Zhonghao Ye and Gang Cao. (1997, September). Solutions to Problem 165. Bulletin of Mathematics, no. 9. 问题征解栏: 165题的解答. 数学通讯.
Yong Zhao. (2011). A Survey of Involutoric Hexagons. 完美六边形研究综述 (draft).

Automated geometry bashing

2020-08-31T00:00:00+00:00

The IMO Grand Challenge aims to “build an AI that can win a gold medal in the (International Mathematical Olympiad) competition.” Geometry problems are an attractive target (e.g., see this MathOverflow discussion or this Lean’s Zulip stream), given the rich literature on automated theorem proving in geometry.

Olympiad participants have long been using well-known computational techniques (i.e., “bashing”) to solve geometry problems, such as complex numbers or barycentric coordinates. How much can we automate these techniques? As a case study, I write programs to solve the two geometry problems in IMO 2019. For this post, I use Maxima, a computer algebra system (easy to install via apt-get on Debian/Ubuntu or Homebrew on macOS). The focus is to explore how to encode these geometry problems such that they can be solved by Maxima within a reasonable amount of time.

NB: I also tried several SMT solvers that support nonlinear real arithmetic. I was able to prove Napoleon’s theorem (the first example below), but not the other two IMO 2019 problems (with a 30-minute timeout). If you have success in finding the right SMT encodings, please let me know!

Complex numbers

There are many good notes on encoding geometry problems using complex numbers. Search for “complex bashing” or refer to Evan Chen’s “Bashing Geometry with Complex Numbers”. The high-level idea is to represent each point with Cartesian coordinate \((x, y)\) as complex number \(z = x + yi\). This often leads to simpler calculation.

The rest of the post uses \(a\) (in lower case) to denote the complex number of the corresponding point \(A\) (in upper case). Below are a few examples.

The reflection of point \(A\) over the real axis is: \(\overline{a}\) (i.e., the conjugate of \(a\)).
The rotation of point \(A\) about point \(B\) by counterclockwise angle \(\theta\) is: \((a - b) \exp(i\theta) + b\).
The centroid of triangle \(ABC\) is: \({(a + b + c)}/{3}\).

See the file geometry.mac for more results (e.g., collinearity, concyclicity, and intersection) coded up in Maxima, which will be used for later proofs.

As a simple example, let’s prove Napoleon’s theorem: the centers of equilateral triangles constructed outward on the sides of a triangle form an equilateral triangle (known as the outer Napoleon triangle).

Let’s do the calculation manually first. \(A, B, C\) are free points.

\(M_1\) is the rotation of \(B\) about \(C\) by \(60\degree\) (i.e., \(\pi/3\)):

\[m_1 = (b - c)\exp(i\pi/3) + c = \dfrac{(\sqrt{3}i + 1)b - (\sqrt{3}i - 1)c}{2}.\]

\(N_1\) is the center (centroid) of equilateral triangle \(M_1BC\), \((m_1 + b + c) / 3\). Therefore, we have:

\[n_1 = \dfrac{(\sqrt{3}i + 3)b - (\sqrt{3}i - 3)c}{6}.\]

Similarly,

\[\begin{aligned} n_2 & = \dfrac{(\sqrt{3}i + 3)c - (\sqrt{3}i - 3)a}{6} \\ n_3 & = \dfrac{(\sqrt{3}i + 3)a - (\sqrt{3}i - 3)b}{6}. \end{aligned}\]

With all the points calculated, it’s straightforward to show that triangle \(N_1N_2N_3\) is equilateral using any of the following encodings for equilaterality:

\((n_3 - n_2)\exp(i\pi/3) + n_2 = n_1\),
\(\lvert n_1 - n_2\rvert = \lvert n_2 - n_3\rvert = \lvert n_3 - n_1\rvert\),
\(n_1^2 + n_2^2 + n_3^2 = n_1n_2 + n_2n_3 + n_3n_1\) (see proof).

Now let’s automate the calculation using the following Maxima program:

load("geometry.mac");
  
/* Declare triangle ABC. */
declare([a, b, c], complex);

/* Compute the outer Napoleon triangle. */
p(x, y) := centroid(x, y, rotate(x, y, %pi/3));
[n1, n2, n3] : [p(b, c), p(c, a), p(a, b)];

/* Prove that the outer Napoleon triangle is equilateral. */
prove(equilateral(n1, n2, n3));

quit();

The prove function (defined in geometry.mac) calls Maxima’s built-in is function to determine whether a predicate is provably true. Below is the execution trace of this program:

% maxima -b napoleon.mac
Maxima 5.44.0 http://maxima.sourceforge.net
using Lisp SBCL 2.0.5
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) batch("napoleon.mac")

read and interpret napoleon.mac
(%i2) load("geometry.mac")
(%o2)                             geometry.mac
(%i3) declare([a,b,c],complex)
(%o3)                                done
(%i4) p(x,y):=centroid(x,y,rotate(x,y,%pi/3))
                                                        %pi
(%o4)            p(x, y) := centroid(x, y, rotate(x, y, ---))
                                                         3
(%i5) [n1,n2,n3]:[p(b,c),p(c,a),p(a,b)]
              sqrt(3) %i   1                sqrt(3) %i   1
       2 c + (---------- + -) (b - c) + b  (---------- + -) (c - a) + c + 2 a
                  2        2                    2        2
(%o5) [----------------------------------, ----------------------------------, 
                       3                                   3
                                                   sqrt(3) %i   1
                                            2 b + (---------- + -) (a - b) + a
                                                       2        2
                                            ----------------------------------]
                                                            3
(%i6) prove(equilateral(n1,n2,n3))
(%o6)                                true
(%i7) quit()

If we attempt to prove something false, such as \(N_1N_2C\) equilateral, the execution fails:

(%i6) prove(equilateral(n1,n2,c))
prove(equilateral(n1,n2,c))
Unable to evaluate predicate errexp1
...
 -- an error. To debug this try: debugmode(true);

Exercise 1: Extend the above program to prove that the center of the outer Napoleon triangle \(N_1N_2N_3\) corresponds to the centroid of triangle \(ABC\).

Exercise 2: Prove Napoleon’s theorem using an SMT solver or Gröbner bases.

For SMT, you may find Leonardo de Moura’s “Complex Numbers in Z3” useful. To make the code work in Python 3, change __div__ to __truediv__ and __rdiv__ to __rtruediv__.
For Gröbner bases, you may find Dan Roozemond’s “Gröbner Bases in Practice” chapter useful. The paper uses the Singular computer algebra system. Maxima and SymPy should also work.

IMO 2019, problem 2

In triangle \(ABC\), point \(A_1\) lies on side \(BC\) and point \(B_1\) lies on side \(AC\). Let \(P\) and \(Q\) be points on segments \(AA_1\) and \(BB_1\), respectively, such that \(PQ\) is parallel to \(AB\). Let \(P_1\) be a point on line \(PB_1\), such that \(B_1\) lies strictly between \(P\) and \(P_1\), and \(\angle PP_1C = \angle BAC\). Similarly, let \(Q_1\) be a point on line \(QA_1\), such that \(A_1\) lies strictly between \(Q\) and \(Q_1\), and \(\angle CQ_1Q = \angle CBA\).

Prove that points \(P\), \(Q\), \(P_1\), and \(Q_1\) are concyclic.

See the solution in Maxima imo2019p2.mac.

Here’s the high-level flow. \(A, B, C\) are free points, from which we derive \(A_1\) and \(B_1\). We derive \(P\) and \(Q\) by introducing another free point \(K\), the line through which parallel to \(AB\) intersects \(AA_1\) and \(BB_1\) at \(P\) and \(Q\), respectively. The remaining question is how to encode \(P_1\) and \(Q_1\).

First, \(P_1\) on \(PB_1\) may translate to:

\[\frac{p_1 - b_1}{b_1 - p} = \overline{\left(\frac{p_1 - b_1}{b_1 - p}\right)}.\]

\(\angle PP_1C = \angle BAC\) may translate to:

\[\frac{p_1 - c}{p_1 - p} / \frac{a - c}{a - b} = \overline{\left(\frac{p_1 - c}{p_1 - p} / \frac{a - c}{a - b}\right)}.\]

Since \(a, b, c, p\) are known at this point, one may solve \(p_1\) by eliminating \(\overline{p_1}\) from the above two equations (by hand or using Maxima’s solve function). One may solve \(q_1\) similarly.

Next, it’s straightforward to prove that \(P, Q, P_1, Q_1\) are concyclic by testing the following:

\[\frac{p_1 - p}{p_1 - q} / \frac{q_1 - p}{q_1 - q} = \overline{\left(\frac{p_1 - p}{p_1 - q} / \frac{q_1 - p}{q_1 - q}\right)}.\]

Maxima reported the following error on my first attempt:

PQUOTIENT: Quotient by a polynomial of higher degree (case 2b)
 -- an error. To debug this try: debugmode(true);

I worked around this error by choosing \(C\) as the origin (i.e., \(c = 0\)), with which Maxima is able to finish the proof.

Notice that the problem description is not constructive: it asserts the existence of points \(P_1\) and \(Q_1\) but doesn’t say how to construct them—imagine how to draw the figure without solving polynomials. Below is one way to rephrase the problem (in fact, that’s how I drew the above figure), inspired by “solution 1” of this problem’s reference solutions.

Problem 2*: Points \(A_2\) and \(B_2\) are on the circumcircle of triangle \(ABC\). \(AA_2\) intersects \(BC\) at \(A_1\). \(BB_2\) intersects \(CA\) at \(B_1\). Let \(P\) and \(Q\) be points on segments \(AA_1\) and \(BB_1\), respectively, such that \(PQ\) is parallel to \(AB\). \(PB_1\) intersects the circumcircle of triangle \(CB_1B_2\) again at \(P_1\). \(QA_1\) intersects the circumcircle of triangle \(CA_1A_2\) again at \(Q_1\).

Prove that points \(A_2, B_2, P, Q, P_1, Q_1\) are concyclic.

It’s easy to see that this constructive version is equivalent to the original problem, given \(\angle PP_1C = \angle B_1B_2C = \angle CAB\) and \(\angle QQ_1C = \angle A_1A_2C = \angle CBA\).

Exercise 3: Write a Maxima program to prove problem 2*.

IMO 2019, problem 6

Let \(I\) be the incenter of acute triangle \(ABC\) with \(AB \neq AC\). The incircle \(\omega\) of \(ABC\) is tangent to sides \(BC\), \(CA\), and \(AB\) at \(D\), \(E\), and \(F\), respectively. The line through \(D\) perpendicular to \(EF\) meets \(\omega\) again at \(R\). Line \(AR\) meets \(\omega\) again at \(P\). The circumcircles of triangles \(PCE\) and \(PBF\) meet again at \(Q\).

Prove that lines \(DI\) and \(PQ\) meet on the line through \(A\) perpendicular to \(AI\).

See the solution in Maxima imo2019p6.mac.

The problem description is constructive, and it’s fairly straightforward to calculate each point. Two optimizations are worth mentioning.

First, to avoid calculating the incenter, a standard approach is to choose \(I\) as the origin and \(D, E, F\) as points on a unit circle. Let’s introduce angle \(\theta_d\) such that \(D\) is \(\exp(i\theta_d)\); \(E\) and \(F\) are calculated similarly. The rest of the points can be derived from \(D, E, F\).

Second, choose \(IA\) as the real axis (i.e., \(\theta_f = -\theta_e\)), which exploits the symmetry of \(E\) and \(F\). Without this optimization, the program timed out (in 30 minutes).

One may notice the complexity in calculating \(L\), the intersection of \(DI\) and \(PQ\), which is due to the complexity in \(P\) and \(Q\). One possible optimization to calculate \(L\) from points with simpler coordinates, \(DI\) and the line through \(A\) perpendicular to \(AI\), and instead prove that \(P, Q, L\) are collinear.

Exercise 4: Optimize the Maxima code using the above approach.

Summary

Below is a list of the Maxima files used in this post.

Common library: geometry.mac
IMO 2019, problem 2: imo2019p2.mac
IMO 2019, problem 6: imo2019p6.mac
Solution to exercise 3: imo2019p2e3.mac
Solution to exercise 4: imo2019p6e4.mac

The proofs described in this post are close to those written by hand using complex numbers. The optimizations are fairly standard, such as choosing a point as the origin or choosing the real axis to exploit symmetry, which might be possible to automate in the future.

The IMO Grand Challenge expects an AI to produce mechanical proofs that can be checked by the Lean theorem prover. Some of the other IMO 2019 problems are already formalized in Lean (e.g., problem 1 by Kevin Buzzard and problem 4 by Floris van Doorn). Maxima doesn’t produce Lean-checkable proofs, so it requires further work (e.g., building on efforts such as GeoCoq). Another important factor is how these problems will be encoded formally.

Acknowledgments: Luke Nelson, Emina Torlak, and Zhilei Xu provided feedback on a draft of this post.

The shifting range in RISC-V

2020-08-22T00:00:00+00:00

There are several commonly used RISC-V instruction pairs with 32-bit immediates. Below is an example of loading a 32-bit immediate into a register using lui/addi:

lui	rd,imm[31:12]
addi	rd,rd,imm[11:0]

Here lui places a (sign-extended) 20-bit immediate into register rd and fills the lowest 12 bits with zeros, and addi adds a sign-extended 12-bit immediate to register rd.

Question: does this work for any 32-bit immediate? It may be trickier than you think.

Clearly, on 32-bit systems, this instruction pair can be used to load any 32-bit immediate in the range [-2³¹, 2³¹-1]. For example, to load 0x7fffff00, one may use lui with a 20-bit 0x80000 and addi with a 12-bit 0xf00, as adding 0x8000000 and 0xffffff00 (sign-extended from 0xf00) produces 0x7fffff00.

How about 64-bit systems? Specifically, let’s look at loading the 32-bit immediate 0x7fffff00 again. Note that the same 20-bit and 12-bit values used on 32-bit systems won’t work, as adding 0xffffffff_8000000 (sign-extended from 0x80000000) and 0xffffffff_ffffff00 (sign-extended from 0xf00) produces 0x0fffffff_f7ffff00. Does there exist any 20-bit and 12-bit values that make lui/addi work on 64-bit systems?

Similar questions can be asked about other instruction pairs, such as lui/ld for loading a value at a 32-bit address, or auipc/jalr for jumping to a 32-bit pc-relative offset.

The short answer is no. You may be interested in the discussion in the RISC-V ISA Dev group started by Luke Nelson, which prompted the RISC-V ISA specification to clarify the range in the “RV64I Base Integer Instruction Set” chapter:

Note that the set of address offsets that can be formed by pairing LUI with LD, AUIPC with JALR, etc. in RV64I is [−2³¹−2¹¹, 2³¹−2¹¹−1].

In other words, the 32-bit range reachable by such instruction pairs in 64-bit RISC-V is shifted by -2¹¹ from [-2³¹, 2³¹-1]. Therefore, 0x7fffff00 doesn’t fall in the range.

Intuitively, the shifting is caused by the choice of the sign extension of immediates in the RISC-V ISA. See examples of issues reported in coreboot and the BPF JIT for RV64 in the Linux kernel, as well as our upcoming Jitterbug paper.

To check the correctness of the range, I wrote a simple Rosette program, as follows:

#lang rosette

; integer register width in bits
(define XLEN 64)

; symbolic 20-bit and 12-bit values
(define-symbolic imm20 (bitvector 20))
(define-symbolic imm12 (bitvector 12))

; mimic the result of an instruction pair
(define v (bvadd (sign-extend (concat imm20 (bv 0 12)) (bitvector XLEN))
                 (sign-extend imm12 (bitvector XLEN))))

; lower and upper bounds
(define-symbolic lower upper (bitvector XLEN))

; find the lower and upper bounds via optimization
(optimize #:maximize (list lower)
          #:minimize (list upper)
          #:guarantee (assert (forall (list imm12 imm20)
                                      (&& (bvsge v lower)
                                          (bvsle v upper)))))

Rosette invokes the Z3 SMT solver to find the lower and upper bounds of the reachable range (you may also use SMT or the Z3 API directly). The output of the above program is:

(model
 [lower (bv #xffffffff7ffff800 64)]
 [upper (bv #x000000007ffff7ff 64)])

This is consistent with the clarification in the RISC-V ISA specification.

Exercise: if you were asked to make one change in the 64-bit RISC-V ISA (e.g., the semantics of an instruction) to make the range remain [-2³¹, 2³¹-1], what would you do? The above Rosette program may be helpful. You may also want to check the addiw instruction.

Acknowledgments: James Bornholt, Luke Nelson, and Emina Torlak provided feedback on a draft of this post.

Mars retrograde in 2020

2020-08-19T00:00:00+00:00

There is a Mars retrograde this year, from September 9 to November 13. Mars appears to move backwards as Earth overtakes Mars. Below is a plot of its positions in the sky using d3.js. It also includes Jupiter and Saturn retrogrades, both from mid May to mid September.

As described in the earlier posts Mars close approach in 2016 and Mars or UFO, the coordinates of the planets (Mars, Jupiter, and Saturn) are computed via a small program using NASA’s SPICE toolkit, and the coordinates of the stars are retrieved from Wikipedia (e.g., Pisces).

Mars close approach in 2016

2016-05-15T00:00:00+00:00

According to NASA, Mars Close Approach this year is May 30 (or wait until 2018). So I re-ran my program from the earlier post Mars or UFO to compute the locations of Mars in the night sky in 2016, including retrograde from April to June, as shown below:

One thing still missing is updating the size of Mars. Feel free to send me a patch.

A mini symbolic execution engine

2015-05-26T00:00:00+00:00

It has been a while since I blogged last time. One change is that I started to have nightmares about me forgetting to prepare for lecture, rather than forgetting to turn in homework as in the past 20(?) years—life does get better.

This post is about teaching. Last week in grad OS class (CSE 551) we talked about symbolic execution, using the papers of KLEE and SAGE. To illustrate the basic idea, I wrote a mini symbolic execution implementation (~20 lines of Python code), mini-mc, using Z3.

Consider a simple example, test_me.py:

from mc import *

def test_me(x, y):
  z = 2 * x
  if z == y:
    if y == x + 10:
      assert False

x = BitVec("x", 32)
y = BitVec("y", 32)
test_me(x, y)

Here test_me() looks like a normal Python function: the program would crash if the execution hits assert False. The two input variables x and y are initialized to symbolic 32-bit integers, through Z3’s python interface.

To find input that would trigger a crash with symbolic execution, one can fork at every if-branch, and explore each side of the branch. With mini-mc, simply running the Python program will do so, producing the following output:

[3216] assume (2*x == y)
[3217] assume ¬(2*x == y)
[3217] exit
[3216] assume (y == x + 10)
[3218] assume ¬(y == x + 10)
[3218] exit
[3216] Traceback (most recent call last):
  File "./test_me.py", line 11, in <module>
    test_me(x, y)
  File "./test_me.py", line 7, in test_me
    assert False
AssertionError: x = 10, y = 20
[3216] exit

The output says that the execution starts with PID 3216, and forks a child process 3217 to explore the false branch of if z == y, while itself continues to explore the true branch. It does so similarly for a second branch if y == x + 10, and then hits assert False with input x = 10, y = 20.

Here’s an almost complete implementation of the symbolic execution engine in mc.py:

def sched_fork(self):
  pid = os.fork()
  if pid:
    solver.add(self)
    r = True
    mc_log("assume (%s)" % (str(self),))
  else:
    solver.add(Not(self))
    r = False
    mc_log("assume ¬(%s)" % (str(self),))
  if solver.check() != sat:
    mc_log("unreachable")
    sys.exit(0)
  return r
# intercept BoolRef -> bool conversions
setattr(BoolRef, "__bool__", sched_fork)
setattr(BoolRef, "__nonzero__", getattr(BoolRef, "__bool__"))

That’s it - just one function, to show the basic fork-explore-check idea.

The trick is that, as values are symbolic (e.g., via Z3’s BitVec), the Python VM will try to convert them into bool at if statements; let’s intercept the conversion and replace it with sched_fork(), by rewriting __bool__ (Python 3.x) or __nonzero__ (Python 2.x).

There are two more fun examples on equivalence checking:

ffs_eqv.py: check the equivalence of two find-first-set implementations, from the UC-KLEE paper (CAV 2011); and
mod_eqv.py: check the equivalence of two modulo implementations, from the KLEE paper (OSDI 2008).

Hope this is useful for classroom demonstration.

BTW, mc.py also contains a mini implementation of concolic execution. Run bad.py, which resembles Figure 1 of the SAGE paper, and you will see 5 (out of 16) inputs that trigger the exception:

[4324] ============================================================
[4324] #0: s[0] = 0, s[1] = 0, s[2] = 0, s[3] = 0
[4324] s[0] == 98: False
[4324] s[1] == 97: False
[4324] s[2] == 100: False
[4324] s[3] == 33: False
[4324] ============================================================
[4324] #1: s[0] = 0, s[1] = 0, s[2] = 0, s[3] = 33
[4324] s[0] == 98: False
[4324] s[1] == 97: False
[4324] s[2] == 100: False
[4324] s[3] == 33: True
       ...
[4324] ============================================================
[4324] #15: s[0] = 98, s[1] = 97, s[2] = 100, s[3] = 33
[4324] s[0] == 98: True
[4324] s[1] == 97: True
[4324] s[2] == 100: True
[4324] s[3] == 33: True
[4324] Traceback (most recent call last):
  File "./bad.py", line 32, in <lambda>
    mc_fuzz(lambda: top(s), s, [0] * n)
  File "./bad.py", line 26, in top
    assert False
AssertionError: s[0] = 98, s[1] = 97, s[2] = 100, s[3] = 33
[4324] exit

You can modify test_me.py to do the same. See the mini-mc repo on github for details.

The cltq story

2013-09-17T00:00:00+00:00

Stare at the C code below and guess what could go wrong. It’s originally from a CPU simulator, implementing a 16×16⇒32 unsigned multiplication. Thanks to Mattias Engdegård at Intel for sharing the story.

uint64_t mul(uint16_t a, uint16_t b)
{
	uint32_t c = a * b;
	return c;
}

To be more specific, let’s assume x86-64. Is it possible that for some a and b, the result of mul(a, b) changes when compiling the code with different optimization levels using gcc?

Spoiler alert: here’s what will happen. When compiling the code with gcc -O0, you’ll get:

$ ./mul 65535 65535
65535 * 65535 = 4294836225 (0xfffe0001)

Hope you’re not expecting the multiplication to overflow and output 1 here, which would be the case in Go but not in C/C++. We’ll come back to that later.

With gcc -O2, you’ll get this:

$ ./mul 65535 65535
65535 * 65535 = 18446744073709420545 (0xfffffffffffe0001)

This doesn’t look pretty, does it? And here’s what gcc 4.7.3/4.8.1 actually emits with -O2:

movzwl  %di, %eax       ; zero-extend %di (a) to %eax
movzwl  %si, %esi       ; zero-extend %si (b) to %esi
imull   %esi, %eax      ; store their product in %eax
cltq                    ; sign-extend %eax to %rax
ret

Wait, the C code uses unsigned integers only. What’s this sign-extension instruction cltq (cdqe in Intel/AMD manuals) doing here? Is this a gcc bug?

Actually, even though emitting cltq is odd, it doesn’t violate the C standard. There’s a very subtle bug in the mul function. I’ll show how gcc emits cltq by exploiting two odd C rules, integer promotions and undefined behavior, and discuss possible ways to avoid/detect such problems.

How gcc emits cltq

To see what gcc does, invoke it with -fdump-tree-all to dump the IR after each pass. Here’s the (simplified) output after vrp (value range propagation).

mul (uint16_t a, uint16_t b) // a, b: VARYING
{
  uint32_t c;
  int _2;
  int _4;
  int _5;
  uint64_t _7;

  <bb2>:
  _2 = (int) a;              // _2  : [0, 65535]
  _4 = (int) b;              // _4  : [0, 65535]
  _5 = _2 * _4;              // _5  : [0, +INF(OVF)]
  c = (uint32_t) _5;         // c   : [0, +INF]
  _7 = (uint64_t) _5;        // _7  : [0, 4294967295]
  return _7;
}

First of all, a and b are of type uint16_t, which is smaller than int (assuming 32-bit int). According to the rule of integer promotions (C11, 6.3.1.1/2), they are converted to int for multiplication. In other words, a * b is actually (int)a * (int)b, a signed multiplication.

Second, since signed integer overflow is undefined behavior in C, gcc assumes the signed multiplication doesn’t overflow. This is shown in the range information: the product _5 is considered non-negative. Therefore, c and _5 are indistinguishable.

Now the sign conversion c = (uint32_t) _5 becomes dead code, and gcc’s next pass dce (dead code elimination) removes it. The return value _7 is basically (uint64_t)((int)a * (int)b). Note that this is a sign extension from int to uint64_t, which will be lowered to cltq. This is how cltq pops out.

Fixes and workarounds

One way to fix the C code is to convert a and b to uint32_t before multiplication (assuming int is 32-bits).

uint64_t mul_fixed(uint16_t a, uint16_t b)
{
	uint32_t c = (uint32_t)a * (uint32_t)b;
	return c;
}

Instead of fixing the code, another approach is to add a workaround compiler option. Here’s what gcc 4.7.3/4.8.1 emits with -O2 -fwrapv:

movzwl  %si, %eax
movzwl  %di, %edi
imull   %edi, %eax
ret

Everything looks good now. However, if you use -fno-strict-overflow instead of -fwrapv, congratulations, you’ll get bitten by cltq again:

movzwl  %di, %eax
movzwl  %si, %esi
imull   %esi, %eax
cltq
ret

I never really understand the difference between -fwrapv and -fno-strict-overflow, and which option to choose. Looks like it’s safer to just fix the C code.

As a comparison, here’s what clang 3.3 emits with -O2:

imulq   %rdi, %rsi
movq    %rsi, %rax
ret

Don’t worry, no cltq here.

Possible detection methods

In our STACK paper, we use the term unstable code to refer to program fragments being optimized away by the compiler due to undefined behavior. STACK is a static checker for detecting unstable code. While it works well for other cases, unfortunately, STACK doesn’t work here. The main reason is that STACK accepts LLVM IR, which has no sign conversion instruction; the code being optimized away, the sign conversion c = (uint32_t) _5 as in gcc, doesn’t exist in LLVM IR:

define i64 @mul(i16 zeroext %a, i16 zeroext %b) #0 {
entry:
  %conv = zext i16 %a to i32
  %conv1 = zext i16 %b to i32
  %mul = mul nsw i32 %conv, %conv1
  %conv2 = zext i32 %mul to i64
  ret i64 %conv2
}

Since in LLVM IR there’s no instruction to be optimized away, STACK doesn’t report any warning. One could port STACK to gcc to catch this case though.

Another possible way is to extend STACK with an oracle that rewrites zext (zero extension) to sext (sign extension). The idea is that if the code after rewriting is equivalent to the original only under the assumption of undefined behavior, then this rewriting exploits undefined behavior, and the code may be unstable.

I coded up a prototype and it did work for this mul case (see the sign branch in STACK’s git repository if interested). But it reported too many false positives. After all, the compiler being able to remove code often indicates a bug, while being able to flip between zext and sext doesn’t. Maybe we need better heuristics to reduce false positives.

There are a few handy tools for finding undefined behavior. For example, run the C code with Frama-C’s value analysis and you’ll see the following warning:

$ frama-c -val mul.c
[value] Analyzing a complete application starting at main
...
mul.c:3:[kernel] warning: signed overflow. assert (int)a*(int)b ≤ 2147483647;
mul.c:3:[value] assigning non deterministic value for the first time
...

You can also compile it with clang’s -fsanitize=undefined (based on IOC). You need an input to trigger the undefined behavior, such as:

$ ./mul 65535 65535
mul.c:3:17: runtime error: signed integer overflow
          : 65535 * 65535 cannot be represented in type 'int'

Though these tools won’t tell you what code may be “miscompiled” as STACK does, fixing the warnings will reduce the chances of being bitten by the compiler.

Summary

This is one of my favorite unstable code examples. The code is very short, uses unsigned integers only, and yet confusing. Fixing the problem, especially by using gcc’s workaround options, is tricky.

Update from Sep 18th: Add results from Frama-C and clang’s -fsanitize=undefined. Thanks to David Mentré and John Regehr.

Mars or UFO: The DIY night sky

2013-08-21T00:00:00+00:00

Came across a funny book titled 5000 years of UFOs (1997) last weekend. The author claims that a number of ancient astronomical records from Chinese history books are actually about UFOs. Here’s one example, where the author cites the chronicle Zizhi Tongjian (1084):

In the 9th lunar month of the year 415, Mars looped the loop in the constellation Gemini, sometimes forward, sometime backward, sometimes left, sometimes right.

The author questions “how can Mars move like this”¹ and suspects a UFO.

Well, Mars can move like this. That’s why Mars is called a planet (“wandering stars” in Greek). Here’s the last retrograde motion of Mars in 2011–2012, plotted using D3.js (JavaScript+SVG required) and data from NASA.

Compare it with the actual photos from NASA, and you can see how Mars brakes, changes its direction, and moves forward again. Mars appears to move backward in the sky when Earth overtakes Mars, since Earth moves faster around the sun (see more explanations from NASA and BBC).

However, according to either my plots or other historical records, Mars did not loop the loop in Gemini in late 415 at all. In fact, it is nowhere near Gemini at that time. I suspect that the actual date of this record is late 414 or early 415; the chronicle Zizhi Tongjian may make a mistake here. I’ll explain this later.

Plotting the night sky

Here are some technical details. The x-y coordinates of my plots are right ascension (RA) and declination (dec), “longitude” and “latitude” of the celestial sphere, respectively. For stars, I got their RA/dec data (see stars.txt) from Wikipedia (e.g., Gemini), which are assumed not to change.

The key part is to get the RA/dec of Mars over time. There are a few options:

Use Stellarium, but it’s hard to export the coordinates from there;
Calculate the coordinates using lower accuracy formulae;
NASA’s HORIZONS provides a nice web service for generating coordinates, but it doesn’t work for dates earlier than 1900.

I ended up with writing a small program (see coordgen.c) using NASA’s SPICE toolkit, along with the ephemeris data DE431 that covers dates back to 13210BC.

$ ./coordgen "MARS BARYCENTER" 2011-SEP-01 2012-AUG-31
2011-SEP-01 00:00 110.18800  22.84568
2011-SEP-02 00:00 110.87321  22.77037
...
2012-AUG-31 00:00 212.12717 -13.52374

Now we have the RA/dec of Mars for that time span (see mars2011.txt). Similarly, we can get those of Mars in the year 415 (and even those of other planets such as Saturn), as I’ll show later.

Note that these coordinates may not be exactly the same as seen from Earth. They are of the Mars barycenter, not the mass center. Also, they don’t take into account atmospheric refraction nor the light time from Mars to an observer on Earth. They are accurate enough for our purpose though.

I wrapped up my plotting code in ti.js. To generate a plot, simply call ti.load() with your data and configuration. See the source code of this webpage for details.

The fall of a kingdom

Mars in the year 415 played an interesting role in history. According to Zizhi Tongjian, in the 9th lunar month of 415, an astronomical officer of the Northern Wei dynasty reported that Mars was “gone,” which was a serious issue at that time. The emperor then called for a meeting. A high-level official Cui Hao predicted that another kingdom, Later Qin, would fall soon, as indicated by the motion of Mars, though others didn’t believe him. About 80 days later, Mars appeared looping the loop in Gemini. The emperor of Later Qin, Yao Xing, died the next year (416), and Later Qin did collapse the year after (417).²

Let’s plot the motion of Mars from late 415 to early 416.

Clearly, Mars was traveling between Virgo and Aquarius, way far away from Gemini.

I also looked up the astronomical records from Book of Jin (648), which mentioned the following:

Jul 13th, 415, Mars moved to Virgo.³ (Note that all the dates in this article are converted from the original lunar dates and should be considered approximate.)

We can confirm the accuracy of this record using the plot above. Based on this record, since Mars was in Virgo around July, we can also infer that it wouldn’t reach Gemini soon.

415 or 414?

So, what went wrong?

Later, I found one record for the previous year 414, also from Book of Jin (648):

Aug 19th, 414, Mars approached Gemini and Saturn approached Cancer, looping the loop.⁴

Hmm, let’s plug in the data.

This plot shows Mars (in Gemini) and Saturn (in Cancer) in late 414 and early 415, both in retrograde motion. This is consistent with the ancient records.

So, is it possible that Zizhi Tongjian (1084) made a mistake on the actual date?

From Book of Wei (554), I found an earlier version of the story that Cui Hao predicted the fall of Later Qin based on the motion of Mars. It is basically the same story, but the date recorded in that book is “qian sui” before Yao Xing, the emperor of Later Qin, died in 416.⁵

Well, “qian sui” is a confusing term in Chinese. It could mean one year before (415), two years before (414), or even several years before. Based on the plot above, I suspect the actual date of the story is 414, while the author of Zizhi Tongjian misread the date, possibly due to the ambiguity of the term “qian sui.”

To sum up, this is what I believe happened:

Aug 414, Mars started retrograde motion in Gemini.
Late 414, Cui Hao predicted the fall of Later Qin.
Early 415, Mars ended retrograde motion and moved out of Gemini.
416, Yao Xing, the emperor of Later Qin, died.
417, Later Qin collapsed.
554, Book of Wei was published; it says the prediction was made “qian sui” before Yao Xing died.
1084, Zizhi Tongjian was published; it says the prediction was made in late 415, which should have been late 414.

Footnotes

Excerpts from 5000 years of UFOs: “415年，《資治通鑑》「東晉安帝十一年九月，熒惑出東井（雙子座），留守句己，久之乃去。去而復來，乍前乍後，乍左乍右」，熒惑火星會如此飛來飛去嗎？” While the first half of the cited piece does appear in Zizhi Tongjian, the second half doesn’t. It is actually from Book of Jin (晉書·志第二·天文中), talking about observing Mars in general. The author mixed them up, probably due to using a commented version of Zizhi Tongjian. ↩
資治通鑑·卷第一百一十七·晉紀三十九: “義熙十一年…九月…魏太史奏…” ↩
晉書·志第三·天文下: “義熙…十一年三月…己卯熒惑入輿鬼… 五月癸卯熒惑入太微…” ↩
晉書·志第三·天文下: “義熙…十年…七月庚辰…熒惑犯井鉞填星犯輿鬼遂守之…” ↩
魏書·列傳第二十三·崔浩: “初姚興死之前歲也…” ↩

IDIV DoS

2012-12-31T00:00:00+00:00

A little fun for the last day of 2012: how to crash a program via division? x86’s IDIV instruction traps not only on division by zero, but also on INT_MIN / -1 (signed integer overflow).

C/C++

Try to compile this little function.

long long crash()
{
	return (1LL << 63) % -1;
}

It will crash the tcc compiler and the sparse checker.

SQL

You need a 64-bit PostgreSQL (older than 9.2.2/9.1.7/9.0.11) installed on Windows.

Try the following SQL statement.

SELECT ((-9223372036854775808)::int8) % (-1);

Instead of producing 0 from modulo -1, it will crash your PostgreSQL server. The modulo trick also worked in Firebird. This is fixed by adding a check on the divisor.

Here goes more evil SQL.

SELECT ((-2147483648)::int4) / ((-1)::int2);
SELECT ((-9223372036854775808)::int8) / (-1);
SELECT ((-9223372036854775808)::int8) * ((-1)::int8);

The first two are straightforward. The third one (multiplication) crashes PostgreSQL because the overflow check is done via division.

The fix is simple: do the overflow check before the division, not after.

It’s interesting that the developers fixed 32-bit division crashes, but missed 64-bit cases. My guess is that the developers did the tests on a 32-bit Windows. In that case, since there’s no 64-bit IDIV instruction, the compiler instead generates a call to a runtime function lldiv, which doesn’t trap on INT_MIN / -1. This would lead to the incorrect conclusion that 64-bit division wouldn’t trap.

ClamAV bytecode

The ClamAV engine accepts bytecode signatures as extensions to detect new viruses. You can write one to crash ClamAV’s interpreter, as follows.

int entrypoint(void)
{
	long long x = 1LL << 63;
	int y = __is_bigendian() - 1;
	if (x / y)
		foundVirus("idiv");
	return 0;
}

It basically does INT_MIN / -1, only to prevent ClamAV’s bytecode compiler from optimizing away the division. Then compile the function into bytecode, load it into clamscan, and it will crash the interpreter.

Actually the interpreter does have a sanity check for signed division, which was introduced in 2009.

static always_inline int check_sdivops(int64_t op0, int64_t op1)
{
	return op1 == 0 || (op0 == -1 && op1 ==  (-9223372036854775807LL-1LL));
}

The sanity check doesn’t work because, well, you really should swap op0 and op1 in the second half of the check.

Let me know if you have more stories. Happy new year!

kqueue.org

Correctness of a compiler for arithmetic expressions in Lean

Typos

Links

Areas of Napoleon triangles

Antisimilitude and involution

Concyclicity

Hexagons with opposite sides parallel

Summary

References

Automated geometry bashing

Complex numbers

IMO 2019, problem 2

IMO 2019, problem 6

Summary

The shifting range in RISC-V

Mars retrograde in 2020

Mars close approach in 2016

A mini symbolic execution engine

The cltq story

How gcc emits cltq

Fixes and workarounds

Possible detection methods

Summary

Mars or UFO: The DIY night sky

Plotting the night sky

The fall of a kingdom

415 or 414?

Footnotes

IDIV DoS

C/C++

SQL

ClamAV bytecode