Achievements and Challenges in Automatic Locus and Envelope Animations in Dynamic Geometry

A survey on the speed of real-time animation of loci and envelopes in the dynamic geometry software GeoGebra is presented.


Introduction
Dynamic geometry experiments on loci and envelopes may be fruitful activities in learning and research contexts. In particular, studying the behavior of certain geometry constructions when changing some initial parameters of them, may lead to new conjectures or to new kind of visualization of well-known theorems. Some recent papers on modeling planar linkages and proving some properties on their moving parts [15,17] show just one possible way to use locus animation in modern classrooms.
In the paper [14] we reported that non-trivial locus and envelope animations can be performed quickly enough by using today's computers with implicit computer algebra use. In the background, without notifying the user on the fact that thousands of symbolic computations are performed, a pure dynamic geometry experience can be relived, making geometry more geometrical than before.
Six examples were shown in [14] in details when benchmarking them in four different computer algebra systems. In this technical paper we continue investigating the computation speed in three systems, all used directly in the dynamic mathematics tool GeoGebra [12]. It is remarked that the obtained data is a result of continuous improvements of many "ingredients" of the underlying system, including GeoGebra, its embedded computer algebra system Giac, and the construction steps that describe the mathematical content in a faster way than in some earlier attempts. In this sense the focus is on measuring if the assembled parts of the investigated system is capable of supporting classroom and research use of animating locus and envelope curves. Quick computations may be beneficial in both a learning or a scientific context. When a learner or a researcher can obtain visual information of a locus being changed on the initial parameters (that is, on the given free points), the pieces of information can be compared quickly enough by experimenting. Conjectures can be found faster when the animation is quicker, because more special cases can be overviewed during the same time. In addition, the speed of animation can be classified into several categories-some of them are acceptable for the learning/researching process, but some are not.
Therefore, the speed of displaying or animating locus/envelope curves can be crucial when using a dynamic geometry tool for this purpose. Our report summarizes how GeoGebra's capabilities in this direction are evaluated. By studying the output of the benchmarking system we will confirm that the symbolic dynamic geometry approach is useful in investigating several non-trivial research problems, not only well-known classroom exercises.
Last, but not least we emphasize that by using this tool beautiful "new" algebraic curves can be created surprisingly quickly. In Fig. 1 a sliding ladder C D is leaning against the wall x = 0, y ≥ 0, whilst y = 0, x ≥ 0 is the base. The line G H is fixed. A circle with center C and radius C D is drawn. Let the point I be the intersection of C D and G H. Also, point F is created as any of the intersection points of the circle and a perpendicular to C D at point I . Here the continues thick curve shows the real locus of point F. By using fast elimination via Gröbner basis computations it turns out that this curve is a part of the dashed curve which is 4 x 8 + 8 y 8 + 16 x 2 y 6 + 8 x 3 y 5 + 12 x 4 y 4 + 16 x 5 y 3 + 8 x 6 y 2 + 8 x 7 y − 12 x 6 − 8 y 6 − 4 x y 5 − 44 x 2 y 4 − 20 x 3 y 3 − 24 x 4 y 2 − 32 x 5 y + 12 x 4 + y 4 + 32 x 2 y 2 + 24 x 3 y − 4 x 2 = 0, an irreducible algebraic curve that is the Zariski closure of the real locus.
On the structure of this paper: In Sect. 2 the benchmarking system is described. Section 3 depicts the items of the used database. Section 4 shows a test case in detail. In Sect. 5 some possible steps for the future work are sketched up.

The Benchmarking System
In the lifecycle of a new algorithm there is a step when it is integrated into a software tool as an experimental feature. Later on, the feature has to be foolproof to be applicable in a production environment. Schools are especially good examples for production environments where the implemented algorithms must work reliable.
In the paper [14] the new algorithms for the LocusEquation and Envelope commands in GeoGebra have been explained. We set up 152 test cases in order to test the reliability and speed of the discussed algorithms. The test cases are GeoGebra files: each file consists of a geometric construction and a final output which is a certain planar algebraic curve with integer coefficients. The benchmarking system, available at https://dev.geogebra.org/ trac/browser/trunk/geogebra/test/scripts/benchmark/art-plotter, is written in Unix shell, connected with an SQLite database to collect the results of various test runs based on the actual codebase of GeoGebra. An automatic run is performed on a daily basis initiated by a local installation of the Jenkins continuous integration system at https:// prover-test.geogebra.org since March 2017.
The benchmarking system runs each test on three different computer algebra environments. In two cases the Giac computer algebra system is used, once as a Java Native Interface, and once as a JavaScript system [20]. The latter method was tested by using the PhantomJS system [11], primarily created for headless website testing. The third case calls Singular [6] as its backend.
While the performing algorithm in the Giac tests are the same, for Singular a slightly different algorithm has been programmed, namely the one described in [3], based on Singular's grobcov library. It sometimes results in a more sophisticated output, but also requires more time to finish.
Classification of a run is somewhat subjective, mainly because there is no official classification standard of animation speeds. On one hand, 24 FPS is the normal framerate considered "good enough" in movies as it became standard for 35 mm sound film in the 1930s [22] and is still used frequently. Thomas Edison however recommended using at least 46 FPS, "anything less will strain the eye" [9]. On the other hand, cartoons have usually much less frames per second, e.g. 12 or even less [23]. Also, over a certain frame rate human eyes cannot even distinguish between them, although visual evidence can be seen at [1] that 15, 30 and 60 FPS result differently. Actually, [22] considers animations over 5 FPS as motions, so we also accept results above this value as satisfactory.
A test run is classified as follows.
1. "Fast" if the frame rate is at least 12 FPS. 2. "Moderate" between 5 and 12 FPS. 3. "Jerky" between 1 and 5 FPS. 4. "Heavy" below 1 FPS. 5. "Infeasible" if the computation has timed out, or was unsuccessful because of lack of resources. By default the timeout is 60 s. 6. "Incorrect" if the result differs from the expected value. In the database there can be multiple correct output results for the same input because some points can be considered also correct from different approaches. Table 1 shows an output of a full test run-it is a hardcopy of the web page at https://prover-test.geogebra.org/ job/GeoGebra-art-plottertest/268/artifact/test/scripts/benchmark/art-plotter/html/all.html. Here we refer to some colors that may be fully checked on the web page, namely, fast case runs are colored green, moderate runs are light blue, jerky runs are orange, heavy runs are red, infeasible runs are white and incorrect runs are black. The results for the grobcov library are sometimes incorrect because of some technical issues-they should be addressed in the future. For each run "deg" shows the degree of the output polynomial and FPS reports the measured speed.
The results for the web runs are somewhat inaccurate, because the obtained time includes the first initialization of the computer algebra system as well. On the user's intervention (that is, on dragging the free points) the later computations will be somewhat faster, therefore these results show worse data than they are in reality.
The table was obtained with full automatization, that is, without any human modification of the measured data. Finally we highlight that the benchmark contains only one part of the computation for one frame. Some other steps are also required to visualize the plot, and to maintain user interaction (see Fig. 2), but those steps are computationally much easier than eliminating variables from a polynomial ideal (see [14] for more details).

The Database
The test database being used consists of various kinds of tests. It focuses on covering former or present bugs and inaccuracies of the implemented algorithms. The first implementation of computing locus equations in GeoGebra goes back to 2010, that time, in the frame of the Google Summer of Code project Sergio Arbeo programmed the prototype. He created several GeoGebra files which were uploaded to his project blog https://dev.geogebra.org/ trac/wiki/LocusLineEquation. One part of the benchmark database consists of Arbeo's examples (A01-A10 and B02-B16: 25 tests).
During the past years the system has been improved, extensively rewritten and tested by several researchers and end users. As a result, another part of the database, 11 tests were created by Noël Lambert, who was one of the primary testers of the implicit locus equation subsystem. 8 tests (named linkage-. . .) come from direct use of loci in GeoGebra's Automated Reasoning system [18], concentrating on the possible role of planar linkages in STEAM education-23 additional tests are also related to linkages [17]. 11 tests are a demonstration of the implicit locus subsystem for triangles in an elementary context (named variations-. . ., [13]). The other tests are different experiments, including well known results (like the trace of the midpoint of a sliding ladder) or completely new ones (like the Pech-Blažek theorem, [4]).
This also means that many of the tests were created or inspired by various people, including (alphabetically) Miguel Abánades, Sergio Arbeo, Jiří Blažek, Francisco Botana, Jesús Escribano, Roman Hašek, Markus Hohen-  [2,4,5,7,10,19,21] for some more references. An immediate remark that the database has entries of different difficulty levels from the computational point of view. Some tests (e.g. Arbeo-B13, Arbeo-B14 and Arbeo-B15) are reasonably fast on all computer algebra systems, others are fast on the DesktopInternal backend but infeasible on the other two. The DesktopInternal backend is seemingly the fastest one, and just a few tests are reported to be slow on it. The most difficult one is Blažek's first example [4] which cannot be computed in 60 s if the input parameters are not integers.
It is remarkable that the output may heavily depend on the input parameters. Table 2 shows how the FPS value changes when the coordinates of the free points are changed.
This behavior can be observed in other tests, too. For example, when checking Euler's inequality [19], the case R = 2r results in 0.28 FPS, the R = 2.1r case gives 0.22 FPS, and the R = 2.01r case reaches only 0.16 FPS, when A = (0, 0), B = (1, 0). For R = 2r and a randomly chosen A only 0.01 FPS can be achieved.
As a conclusion, dragging is not recommended on these "heavy" examples, because the user can quickly get into a situation that the software tool is keeping computing the next frame without success, and the program seems to be "freezing". For a next step it is suggested to improve the software to avoid such situations.
Finally we note that the degree of the output polynomials are between 1 and 20. It is not uncommon that the coefficients of the polynomials (that is, the elements of matrix A) are "big" integers. For example, in the test case Blazek-example1 the top-left constant is 13032282395006214457548753 (and the other coefficients are of similar magnitudes). The example with the biggest integers is HartAFramedifficult which is stored with more than 30,000 decimal digits (this means about 70 digits as an average for each coefficient).

An Example
As a real life example we refer to the nephroid curve as caustic of a circle (Fig. 3). This curve can be seen, among others, in a coffee cup or a mopping bucket every day. By using GeoGebra's desktop version one can animate the curve in real time, depending on different positions of the source of the light. The name of the example is nephroid-concurrent which provides a motion of 7.87 FPS. (The Gröbner cover algorithm can also compute the envelope equation, but it is definitely slower by reaching only 0.50 FPS.) Figure 3 can be obtained by performing the following ideas and steps. The point D is the source of the light. The light ray collides with the perimeter of the circle in point C. The mirrored ray continues its way further in another direction. When D is fixed, the envelope of the mirrored rays is a nephroid curve. While D is dragged from an external source into an internal point of the circle, several curves will be drawn as different frames of an animation. The final one here is 45095 x 6 + 36995 y 6 − 10800 x y 5 + 119085 x 2 y 4 − 21600 x 3 y 3 + 127185 x 4 y 2 − 10800 x 5 y + 43320 x 5 + 86640 y 5 + 43320 x y 4 + 173280 x 2 y 3 + 86640 x 3 y 2 + 86640 x 4 y + 35580 x 4 + 93540 y 4 + 77280 x y 3 + 129120 x 2 y 2 + 77280 x 3 y + 20800 x 3 + 56960 y 3 + 48960 x y 2 + 51840 x 2 y + By experimenting with the dynamic applet one can realize that the envelope equation is usually a sextic, but in some special cases it falls back to a quartic, as it is the case for the point D = (−4, 0). Namely, the computed curve is (x + 4) 27 x 4 + 54 x 2 y 2 − 288 x 2 + 512 x + 27 y 4 − 288 y 2 + 256 = 0, which means that the envelope here is a union of a line (the tangent to the circle at D) and a quartic. Also in the special case D = (0, 0) the output collapses to x 2 + y 2 = 0.
By obtaining several curves with their algebraic equations in a short response time the user can make a conjecture for the general case. For the caustics it may be difficult to actually prove this conjecture rigorously-the relevance of the presented approach is to obtain a valid conjecture.
Let us remark that in this example a CAS step was required to better understand the result, namely, factorization. There are other examples where the locus or envelope equation is a product of various polynomials, and sometimes the geometric content is a subset of the factors. This is also the case in the tests HartAFrame-. . . and HartInversor. . . that describe linear motions in some planar linkages, and those linear motions can be observed only through one of the factors.

Conclusion and Future Work
We presented a survey of GeoGebra's abilities in animating locus and envelope curves. It turned out that the desktop version of GeoGebra is capable of visualizing 150 test cases out of 152, while its web version is able to do that in 129 cases. The alternatively available method, via Singular's grobcov library was successful in 100 cases.
On one hand, these capabilities could be successfully used in teaching introductory or more advanced planar Euclidean geometry in classrooms. Even if the output of a computation is a simple geometric object, namely a line or a circle, the fact that such a result must be the output, may be non-trivial for the student, and, from the computational point of view, it may require heavy computations. For example, constructions containing angle bisectors (see test case Lambert-anglebisector), or some special setup of Ptolemy's theorem (see test case Ptolemy-4) are surprisingly difficult to compute. We also highlight that easy questions can lead to difficult geometry. For instance, in [13] simple formulas may result in quartic curves, or a detailed study [19] on Euler's inequality leads to two irreducible octic polynomials (see test case Euler-ineq-2).
On the other hand, such experiments may be interesting in research to obtain new kind of curves with interesting properties.
Clearly, there is still room for improving the underlying algorithms, particularly in the web version, by speeding up computations, and avoid that the software is not responding because of the heavy or infeasible amount of remaining operations.
Futher speedups can be achieved via using various techniques: • one possibility is to harness asm.js [24] support in modern browsers (this feature, as of October 2017, is already working in Microsoft Edge, but it might be solved for Firefox as well), • the other one is running native code as it is already implemented in GeoGebra Classic 6 via Electron/Node builds (as of October 2017), see [16] for a simple application based on Giac. • Finally, another promising possibility is to use WebAssembly [8] (but this kind of technology is not yet available in all browsers).
We lastly remark that obtaining the exact identification of the locus by using the grobcov library should be solved as a future work, including the test cases which currently do not work yet.