Abstract
The Traveling Salesperson Problem (TSP) is one of the best-known problems in computer science. Many instances and real world applications fall into the Euclidean TSP special case, in which each node is identified by its coordinates on the plane and the Euclidean distance is used as cost function. It is worth noting that in the Euclidean TSP more information is available than in the general case; in a previous publication, the use of geometric information has been exploited to speedup TSP solving for Constraint Logic Programming (CLP) solvers. In this work, we study the applicability of geometric reasoning to the Euclidean TSP in the context of an ASP computation. We compare experimentally a classical ASP approach to the TSP and the effect of the reasoning based on geometric properties. We also compare the speedup of the additional filtering based on geometric information on an ASP solver and a CLP on Finite Domain (CLP(FD)) solver.
Keywords
Introduction
The Traveling Salesperson Problem (TSP) is a classical COP that, given a graph with non-negative weights on the edges, involves finding the minimal cost cycle that visits each node exactly once. Many instances and real world applications fall into a special case called Euclidean TSP, as also evidenced by the many Euclidean instances present in the famous TSPLIB [32] benchmark set. In the Euclidean TSP each node is identified by its coordinates in the Euclidean plane, and the weight is the Euclidean distance.
The usual way to tackle Euclidean TSPs is to compute the distance matrix and address the problem as a general TSP. However, in the Euclidean TSP more information is available than in the general case: the coordinates of the nodes are available and geometric concepts, like angles and straight lines, can be defined in the Euclidean plane. In a previous publication [5], we showed that the use of geometric information can be exploited to speedup TSP solving in CLP solvers. The work started from the observation that, due to the triangular inequality, in a Euclidean TSPs two edges cannot cross each other, since eliminating the crossing would result in another cycle of shorter length. This observation was then extended and exploited in the development of efficient algorithms that reduce the search space.
Beside CLP, ASP is another logic programming paradigm that due to the expressiveness of the language and the availability of efficient solving systems [10, 34] is used in advanced applications.
In this paper we study the applicability of geometric reasoning to the Euclidean TSP in the context of ASP. We propose an encoding of Euclidean TSP as an ASP program with reasoning based on geometric properties, aiming to eliminate crossings also by leveraging properties associated with the convex hull of the point set. We present and empirically evaluate different ASP encodings for computing the convex hull of sets of points.
To assess the performance and applicability of our proposed techniques we compare how solving time is affected when different types of geometric information are exploited in the encoding. We show that the obtained speedup is often between 1 and 3 orders of magnitude. The experiments involve both randomly generated instances and real-life instances such as those from the aforementioned TSPLIB [32]. On real-life instances, we compare the solution quality after running both methods for the same time, and obtained that the tour length obtained by applying geometric reasoning was 75% with respect to that obtained by the basic ASP approach.
Finally, we compare the speedup of the additional filtering based on geometric information on an ASP solver and a CLP on Finite Domain (CLP(FD)) solver; in both cases the speedup is computed with respect to the usual approach of computing the distance matrix and then solving the TSP with the usual techniques (both in ASP and in CLP(FD)).
Preliminaries
An ASP program Π consists of a finite set of clauses interpreted in the Stable Model semantics [22]. Each clause in an implication H ← B. The full ASP syntax is reported in [9]. The head H of the clause can be an atom of the form
Clauses with empty body are called facts, while clauses with empty head are called ICs, and their head is intended to be false.
An interpretation I of a program Π is a subset (not necessarily proper) of the set of atoms occurring in Π. The atoms in I are considered true in the interpretation, while all remaining atoms are false.
The reductΠ
I
of a program Π with respect to the interpretation I is a set of clauses defined as follows. For each rule r ∈ Π containing a negative literal
Since each node in a graph of a Euclidean TSP is associated with a point in a plane, in the rest of the paper we will often use the terms “point” and “node” indistinctly.
Filtering techniques for the Euclidean TSP in ASP
As stated in previous sections, Euclidean TSP instances include the coordinates on the plane of the points; such coordinates in ASP can be represented by facts
The basic Euclidean TSP encoding in ASP is presented in Listing 1. This encoding includes the degree constraint that ensures that, in the solution, the degree of each node is equal to two. Line 1 ensures that each point has exactly one outgoing edge while line 2 ensures that each point has exactly one incoming edge. Lines 4–6 state that starting from the point with smallest
Listing 1: Euclidean TSP encoding in ASP
Avoiding intersections
The following is a well-known result in the literature.
Intuitively, in Fig. 1 instead of taking segments

A self-crossing circuit. (Picture created with ASPECT [7]).
The Euclidean TSP is a special case of the metric TSP since the Euclidean distance satisfies the triangular inequality; from Theorem 1, one can avoid, during the search for an optimal Euclidean TSP, those paths that include crossing edges.
Avoiding crossings is particularly simple and declarative in ASP; in Listing 2, line 1 imposes that a pair of segments in the TSP should not cross each other (except, possibly, in one endpoint). The
Clearly, in order to have r > 0 and s > 0, the numerators and denominator must all have the same sign (lines 10-12 in Listing 2); in order to have r < 1 and s < 1, the absolute value of the nominator must be less than the absolute value of the denominator (lines 13-14).
Listing 2: Constraint for avoiding crossing edges
It is interesting to notice that currently available intelligent grounders (such as
A useful consequence of Theorem 1 is based on the concept of convex hull and is given in Corollary 1. The convex hull of a set of points P in a Euclidean space is the minimum convex set containing all the points. In the plane it corresponds to a convex polygon, and it is completely defined by its vertices. We denote with
Corollary 1 can be exploited in several ways to reduce the search space; the main idea is to define an order of visit (either clockwise or counterclockwise) of the tour, and impose that in all points belonging to the border of the convex hull such order is preserved. In a sense this type of pruning can be thought as a symmetry breaking constraint, and in the experimental evaluation it will be compared with another symmetry breaking technique that imposes one order of visit of the tour.
The points on the boundary of the convex hull will be identified by means of the
In [5] we devised three ways to exploit the information about the hull for propagation. In the following we report them together with the corresponding ASP encoding. The first constraint, implemented in Listing 3, impose that the successor of a convex hull vertex cannot be another vertex member of
Listing 3: The successor of a convex hull vertex cannot be another vertex on the boundary of the convex hull except for the one that immediately follows it.
This integrity constraint imposes that edges connecting far away nodes in the border of the convex hull cannot be taken, and are immediately propagated by the unit propagation of the solver with no need of search.
The second way is reasoning on the angle formed by the incoming and the outgoing arcs in hull vertexes: in order to visit nodes in a counterclockwise order, the angle between the incoming edge and the outgoing edge of a node H
i
on the boundary of the convex hull cannot be negative (it must be between 0 and π) or, stated otherwise, it must correspond to a left turn.
Listing 4: In order to visit nodes in a counterclockwise order, the angle between the incoming edge and the outgoing edge of a convex hull vertex cannot be negative.
The third way results from stating that any path starting from a convex hull vertex cannot reach any other convex hull vertex except the one that directly follows it. Put it more precisely, each vertex in a path originating from a point H
i
on the boundary of the convex hull cannot reach any vertex in
Listing 5: Each path originating from a convex hull vertex cannot reach any convex hull vertex except for the one immediately following it.
Predicate
Computing the convex hull
Several algorithms exist to compute the border of the convex hull of a set of vertices; however we preferred to compute it with a declarative program directly in ASP. We can declaratively state that a vertex is on the border of the convex hull if it is not internal to any triangle having as vertexes any three nodes of the graph (line 1 in Listing 6). In order to check if a point
This approach computes the set of vertices on the border of the hull in O (n4), when n is the number of vertexes; this is much higher than other available algorithms (e.g., Andrew’s monotone chain has O (n log n) complexity), but it is worth noting that all the computation can be performed by the grounder, and indeed
Once the points belonging to the boundary of the hull have been found, it is necessary to find what is their cyclic order. Given two points A and B on the boundary of the convex hull, point B is successor to point A, chosen the counterclockwise direction, if there are no other points to the “right” of segment
Note that all the computation in Listing 6, concerning the calculation of the convex hull, is performed by the grounder therefore it does not affect solving performance.
Listing 6: Calculation of convex hull in ASP
Jarvis march
The program presented in Section 3.2.1 that computes the points in the border of the convex hull is highly declarative and stratified, and it is completely solved by efficient grounders such as gringo. On the other hand, it has clearly O (n4) complexity (if n is the number of points), and there exist more efficient algorithms.
We implemented in ASP a version inspired by the Jarvis march [26]. In a nutshell, the Jarvis march can be described as follows. First, a point on the border of the hull is found (for example, the point having smallest x coordinate, breaking possible ties by taking the point with smallest y coordinate). Afterwards, the following inductive algorithm is executed: starting from the last point A added to the set
The ASP implementation inspired by the Jarvis march is shown in Listing 7. The point with smallest x is declared a point in the border of the hull; the following ones are found (predicate
Listing 7: Jarvis March in ASP
For this reason, we also experimented with a modification of the program in listing 7, which is stratified; the only difference is that in clauses 4 and 5 the atom
Exploiting acyclicity checker
The
Listing 8: Euclidean TSP encoding in ASP with acyclicity constraints
The rule in line 3 creates an atom
Experimental evaluation
To assess the effectiveness of the proposed algorithms, we compared experimentally a classical ASP encoding for the Euclidean TSP with encodings using the reasoning based on geometric properties presented in the previous section. We also devised experiments to compare the speedup of the additional filtering based on geometric information on an ASP solver and a CLP(FD) solver. As CLP(FD) solver, we chose the
To generate realistic Euclidean TSP instances, we used the generator of the DIMACS challenge [12], that provides instances in two classes: uniform and clustered. We randomly generated instances from 10 to 50 nodes, in both classes. For each size and class, we generated 16 instances.
Uniform random generated instances consist of integer coordinate points uniformly distributed in a square of 103 side. Randomly generated instances consist of clusters of points, whose centers are uniformly distributed in a square of 103 side. Each point is then randomly associated with a cluster center and two normally distributed variables, each of which is then multiplied by 103/# nodes, rounded, and added to the corresponding integer coordinate of the chosen center to obtain the coordinates of the point.
Comparing convex hull algorithms
In Section 3.2, we introduced three approaches for computing the convex hull in ASP. In Fig. 3, we compare the average grounding time of the three convex hull algorithms as the instance size varies. As depicted in the figure, the most efficient algorithm is labeled as JARVIS2 which is the stratified version of the JARVIS algorithm (see Listing 7). Computing the hull using the triangle method (see Listing 6), called INSIDE, achieves intermediate performance. It is noteworthy that for all methods, the grounding time remains below one second, even for the largest instances tested. The size of the ground program is almost the same for the two stratified methods (JARVIS2 and INSIDE), but it is larger for the JARVIS algorithm; for example, in the TSPLIB [32] instance
A second comparison made on solving times of randomly generated Euclidean TSP instances shows how the three algorithms are actually comparable; refer to the scatter plot in Fig. 2 for more details. In light of the results just presented, for the remainder of the experimental evaluation, we will consider the JARVIS2 model as the preferred hull computation method.

Comparison of solving time using different methods for convex hull calculation.

Comparison of grounding time of different methods for convex hull calculation.
For simplicity, we summarized in Table 1 the structure of the various ASP programs tested in the experimental evaluation. The ASP_BASE program is the reference encoding for TSP in ASP (Listing 1), ASP_HULL and ASP_NOCROSS implement only convex hull-based pruning (Section 3.2) and crossing removal-based pruning (Section 3.1), respectively. Finally, ASP_GEOMETRIC implements both geometric reasoning. We also tested Euclidean TSP encodings based on acyclicity constraint called ASP_ACY_BASE and ASP_ACY_GEOMETRIC.
ASP programs tested in the experimental evaluation. *In all experiments we used the stratified variant of Listing 7
ASP programs tested in the experimental evaluation. *In all experiments we used the stratified variant of Listing 7
Since convex hull-based constraints also behave as symmetry breaking by imposing the direction of cycle, we added the following constraint
to the ASP_BASE program to remove symmetries and have a fair comparison.
All tests were run with a time limit of 1800s on Intel® Xeon® Platinum 8358 running at 2.6GHz, using only one core and with 8GB of reserved memory.
Figure 4 compares ASP encodings without acyclicity constraints. In Fig. 4a, each point represents one instance solved with ASP_BASE encoding (whose running time is in the x axis) and with one of the encodings exploiting geometric reasoning (whose running time is reported in the y axis). Since all points stand below the y = x straight line, the geometric properties were able to speedup the running time in all instances. Note the log-log scale: speedups from 1 to 3 orders of magnitude were often obtained. Taken individually, both ASP_NOCROSS and ASP_HULL encodings showed a lower solving time when compared with ASP_BASE encoding. However, the best encoding turns out to be ASP_GEOMETRIC containing all the geometric reasoning presented in this paper.

Comparison of Euclidean TSP ASP encodings using different geometric reasoning.
The graph in Fig. 4b shows how the average solving time varies with respect to the size of Euclidean TSP instances. Each point is calculated as the geometric mean of the solving times for the 32 instances of that size present in the dataset (16 uniform and 16 clustered). In particular, note how the use of the ASP_GEOMETRIC encoding allows solving instances containing up to 30% more nodes.
Figure 5 shows the effect of the acyclicity checker; the use of the acyclicity checker provided very small improvement, and mostly in conjunction with the use of geometric constraints.

Comparison of ASP encoding using acyclicity constraint.
The comparison of grounding times for different encodings is depicted in Fig. 6. Specifically, the grounding time for the ASP_GEOMETRIC encoding increases quadratically as the number of

Comparison of grounding time of different Euclidean TSP ASP encodings.
We also compared the grounding size of the three constraints proposed in Section 3.2 to exploit the information about the convex hull. Figure 7 illustrates how the grounding size changes with varying problem sizes. For each number of nodes, we calculated the average grounding size obtained. The lines on the graph correspond to the visit-in-order constraint (Listing 3), the incoming angle constraint (Listing 4), and the path constraint (Listing 5), as well as the combination of all three constraints used together (see ASP_HULL). To compute the convex hull we used the stratified variant of Listing 7. As illustrated in the graph, the visitin- order constraint constraint is the cheapest, as it excludes only O (h2) edges (where h is the number of nodes on the border of the hull). Constraint incoming angle constraint excludes O (hn2) edges, while path constraint is clearly the most expensive, in terms of grounding size. Overall, the grounding size does not exceed 2.5 MiB with all constraints applied simultaneously.

Comparison of average grounding size of the ASP encoding for the three constraints proposed to exploit the information about the convex hull.
We compared ASP_BASE and ASP_GEOMETRIC approaches also on instances taken from the TSPLIB [32], the Concorde website 1 and the CITIES dataset 2 up to 100 nodes. These sources provide various types of instances, including Euclidean instances, depicted as point sets in a two dimensional plane, and geographical instances, depicted as point sets (with latitude and longitude coordinates) on Earth’s surface. We included all Euclidean instances and additionally incorporated geographical instances where the cities to be visited are situated within a confined region of the Earth’s surface, allowing for the approximation of geographical distances using Euclidean distances.
All tests were run with a time limit of 86400s on Intel® Xeon® Platinum 8358 running at 2.6GHz, using only one core and with 8GB of reserved memory.
Figure 8 shows, for each tested instance, the quality of the best solution found within the timeout (the lower the better). For each method, the y-axis reports the ratio of objective function of the best found solution with respect to the optimal solution (obtained from the literature), so a value of 1 means that the ASP program was able to obtain the real optimal solution. The program using geometric filtering consistently achieves a superior solution quality, with only one exception. On average, the length of the tour obtained with the geometric reasoning was 75% that obtained with the basic version. This is a notable improvement for real life applications: for a company, saving 25% of the travel time and 25% of the fuel is a significant improvement (not to count the saving in polluting emissions). To better show how the solution quality improves varying the allotted running time, Figure 9 illustrates the average anytime behavior of the two approaches across all 23 tested instances. It is noteworthy that the ASP_GEOMETRIC model ensures better solutions compared to ASP_BASE within the timeout. Moreover, the quality of solutions improves significantly even during the initial stages of the solving procedure.

Comparison of Euclidean TSP ASP encodings on TSPLIB instances. The chart illustrates the ratio between the best solution found within the timeout and the known optimal solution (lower is better).

Performance profile of Euclidean TSP ASP encodings on TSPLIB instances. A higher curve suggests less efficient performance, while a lower curve reflects quicker convergence towards the optimal solution.
In CLP(FD), we adopted the successor representation. In the successor representation, n variables Next i are defined Next = (Next1, Next2, …, Next n ); variable Next i represents the node that follows node i in the circuit, and its initial domain is {1, …, n} \ {i}. For example, if n = 5 and Next = (3, 5, 4, 2, 1) the corresponding tour will be (1, 3, 4, 2, 5, 1).
The basic Euclidean TSP encoding includes an
The CLP_GEOMETRIC program includes the basic CLP(FD) encoding for Euclidean TSP together with constraints for crossing removal and convex hull-based pruning, which in this program also acts as a symmetry breaking constraint. CLP_BASE program, on the other hand, besides the basic encoding, includes only the Next1 < Prev1 symmetry breaking constraint.
A comparison of how filtering based on geometric information performs differently on an ASP solver and a CLP(FD) solver is presented in Figure 10. We decided to compare the speedup obtained through the exploitation of geometric reasoning. In Figure 10a, where each point represents an instance of Euclidean TSP, the speedup obtained in the CLP(FD) solver (x-axis) is compared with the speedup obtained in the ASP solver (y-axis). On average, the use of geometric reasoning shows, on a single instance, a greater speedup in performance on the ASP solver than on the CLP(FD) solver.

Comparison of geometric filtering on an ASP solver (
Considering solving times, those recorded on the CLP(FD) solver still remain lower than those shown by the ASP solver. The cactus plot in Figure 10b shows in the x-axis the number of instances that could be solved (with proof of optimality) within the runtime plotted in the y-axis. It shows that CLP_BASE without geometric constraints even succeeds in solving 191 more instances than the encoding ASP_GEOMETRIC that uses geometric constraints instead. If we further compare CLP_GEOMETRIC using geometric reasoning with ASP_GEOMETRIC the gap becomes even more marked as the higher number of instances solved within the time limit increases from 191 to 321.
One difference between the CLP(FD) and the ASP encodings stands in the propagation they perform. In CLP(FD), we implemented a binary
In the ASP encoding, the crossing avoidance is delegated to the integrity constraint in line 1 of listing 2. Such a constraint ensures that if an edge AB is taken, then all edges CD that cross AB cannot be taken as edges of the TSP; such constraint is only activated when one of the involved
Considering the comparison between the ASP and the CLP(FD) approaches, two aspects must be noticed. Indeed, the CLP(FD) approach is faster, and able to solve more instances. On the other hand, the implementation of the propagators took several development time, was based on some non-trivial theorems that were key to reduce the computational complexity of the propagators [5], and takes about 1500 lines of code. The ASP approach, instead, is completely listed in this article, and is based on declarative considerations, without the need to develop complex propagation algorithms.
For example, in order to remove crossings in ASP, one only needs to define what a crossing is and add an integrity constraint, as seen in Listing 1. A similar approach could also be employed in CLP(FD), and indeed it would be a rapid prototyping approach to quickly implement the idea; on the other hand, in order to make it efficient a significant amount of development time would be required.
So while CLP may offer superior speed, it also entails greater complexity when compared to ASP. While we do not claim that our experience with this application is universally representative, we suggest that the improved readability of ASP encodings could be a reason that sheds light on a pertinent aspect of the evolving landscape of industrial applications, wherein ASP is steadily gaining traction owing to its balance of efficiency and simplicity.
In conclusions, we believe that the geometric reasoning on ASP provided a significant speedup and can help extending the applicability of ASP.
Related work
The encoding of the TSP in ASP is a classic one and can be fond, e.g., in [15], which presents also a variant not following the “guess and check” methodology; it does not provide computational results to compare the approaches.
The TSP was also addressed in extensions of ASP, such as CASP. Lierler [28] compares experimentally several CASP systems on the travelling salesman problem.
CASP was used to solve a Delivery Problem, in which robots have to move items inside a warehouse [30]. The extensive work describes in detail the problem, that can be considered as a problem of multi-agent path finding, and it includes a routing component within the warehouse, which is related to the TSP and in which possible routes are identified within a graph, and it also includes a scheduling component, as the exact timing in which each robot is in each location influences the synchronization of activities. In particular, the robots should not collide, and this is achieved by declaring conflict zones, that can be occupied by at most one robot at the same time. The graphs are very large, so the authors decide to reduce the search space in various ways, possibly excluding the optimal solution but allowing them to obtain good solutions quickly. The graphs they consider are planar, meaning that there are no crossings between edges. They successfully employ clingo[dl] [25].
In future work, we plan to implement our geometric reasoning also in CASP and study the speedup provided also in CASP implementations.
Several works address the TSP or some of its variants in CP. One of the most successful formulation is the so-called successor representation, in which a variable is associated to each node of the graph, and its value represents the following node in the TSP. Such formulation requires the
Conclusion
In this paper we applied reasoning based on geometric constraints to the Euclidean TSP (that was developed in a previous publication [5] in the context of Constraint Logic Programming), a widely used case of the famous Traveling Salesperson Problem, within an ASP-based solving approach. The classical encoding of the TSP in ASP was significantly improved thanks to the geometric reasoning: without sacrificing the simplicity, declarativeness and succinctness of the the approach, speedups between 1 and 3 orders of magnitude were easily obtained. Experiments on real-life instances, such as those in the TSPLIB, have also demonstrated the effectiveness of the proposed approach even when obtaining the optimal solution is not required or feasible.
In future work, we plan to test additional ASP approaches for the Euclidean TSP, particularly by introducing difference logic and using the clingo[dl] CASP solver [25]. Another interesting research direction is the use of machine learning to select only those nocrossing constraints that are most effective; this approach was already studied in the CLP(FD) context [3] and provided a further speedup. Moreover, the use of Constraint ASP approaches could provide further improvements and also the geometric reasoning outlined in this paper could be adapted and applied to other routing problems on the Euclidean plane, such as the Euclidean Vehicle Routing Problem or the Euclidean Generalized TSP.
Finally, we plan to study how geometric constraints presented in this paper can be extended into non-Euclidean spaces such as TSP geographic instances where coordinates are expressed in terms of latitude and longitude.
Conflict of interest
The authors declare none.
Footnotes
Acknowledgements
Alessandro Bertagnon and Marco Gavanelli are members of the Gruppo Nazionale Calcolo Scientifico-Istituto Nazionale di Alta Matematica (GNCS-INdAM).
Research funded by the Italian Ministry of University and Research through PNRR - M4C2 - Investimento 1.3 (Decreto Direttoriale MUR n. 341 del 15/03/2022), Partenariato Esteso PE00000013 - “FAIR - Future Artificial Intelligence Research” - Spoke 8 “Pervasive AI”, funded by the European Union under the NextGeneration EU programme.
