The traveling salesman problem starts with a deceptively simple question: in what order should you visit a set of places to keep the total distance short? A Paris route study gives that question a concrete shape. One visiting order measured about 13.374 km; a different order measured 12.118 km under the same geographic-distance model.
What changed between those routes? You can follow the analysis in AIPOCH Open-Science, an open-source, local-first, model-agnostic AI research workbench. The public .science package preserves the conversation, coordinate records, saved route, Notebook work, report, and map. It gives you a way to explore how the study developed and follow the parts that interest you.
This walkthrough of the Paris route case explains the methods and shows where to find their evidence, even if you have never written a route solver.
Key Takeaways
- The Paris example fixes its start and finish, making it an open-path relative of the classic traveling salesman problem.
- The archived analysis compares a saved route, nearest neighbor, 2-opt, and all 40,320 orders of the eight intermediate stops.
- Its
.sciencepackage lets you explore the inputs, decisions, recorded computation, and outputs behind the result.
What Is the Traveling Salesman Problem?
The classic traveling salesman problem asks for the shortest tour that visits every specified location once and returns to the starting location. Each possible order has a total cost, usually distance, and the task is to find the least costly tour. NIST's definition describes it as an optimization problem on a weighted graph.
The challenge is the number of possible visiting orders. Adding locations creates many more combinations, so trying every order becomes impractical as a problem grows. A quick method can find a useful route without establishing that no shorter route exists. Google's routing documentation explains this distinction between good solutions and optimal ones.
The Paris case uses a related setup: start at the Eiffel Tower, finish at Sacré-Cœur, and visit eight other landmarks exactly once. There is no return leg to the Eiffel Tower. This is a fixed-endpoint open-path problem, so its result should be read under those conditions.
The small size makes the example especially useful for learning. With both endpoints fixed, the eight intermediate stops have 8! = 40,320 possible orders. The archived code can compare every one, giving the quicker methods a clear reference result.
What Was the Paris Route Study Trying to Find?
The study asked how one plausible visiting order compared with simple optimization methods using exactly the same locations and distance definition.
The first order was saved before the optimization calculation:
Eiffel Tower → Arc de Triomphe → Place de la Concorde → Palais Garnier → Louvre Museum → Sainte-Chapelle → Notre-Dame de Paris → Panthéon → Luxembourg Gardens → Sacré-Cœur.
Saving that order matters. It leaves a visible starting point to compare against the later results. When you open the research record, you can look for the saved route and then follow the computation that evaluates it.
The coordinate table identifies representative landmark points and links to their source records. The archived script uses a great-circle distance calculation between these coordinates. Buildings are represented by landmark points rather than selected entrances; gardens and squares also use representative points. These choices are documented in the case materials.
The model measures geographic separation. It does not include streets, pedestrian access, opening hours, queues, or traffic. A shorter line on this map does not establish a shorter real-world sightseeing day.
How Were the Four Routes Compared?
The comparison holds the points, start, finish, and distance calculation constant. What changes is the order of the intermediate stops.
Redrawn from the archived coordinates and route orders. Lines represent great-circle connections between landmark points, not walking directions.
A Saved Route and a Nearest-Neighbor Route
The saved route is the initial geography-based proposal. Nearest neighbor constructs an order by repeatedly choosing the closest unvisited intermediate point, then adding the fixed destination at the end.
For this particular set of landmarks, the two approaches produced the same order and the same recorded distance: 13.374 km. That coincidence belongs to this example; it is not a general rule about intuitive choices or nearest-neighbor methods.
A 2-Opt Improvement
The 2-opt procedure starts with the saved route and tests changes to its interior order. The archived implementation tests reversals of intermediate-stop sequences, applies the best improving reversal, and repeats until no tested reversal shortens the route.
Here, that changed the middle of the journey. Luxembourg Gardens and the Panthéon moved ahead of Notre-Dame and Sainte-Chapelle; the Louvre and Palais Garnier came later. The resulting geographic distance was 12.118 km.
This is a local improvement method. Finding a route with no improving single reversal does not, by itself, establish the best route among all possible orders.
An Exhaustive Reference
The archived script also checks every permutation of the eight intermediate stops. It records 40,320 comparisons and checks the endpoint and one-visit constraints. Its shortest result matches the 2-opt order in this instance.
The shared shorter visiting order was:
Eiffel Tower → Arc de Triomphe → Place de la Concorde → Luxembourg Gardens → Panthéon → Notre-Dame de Paris → Sainte-Chapelle → Louvre Museum → Palais Garnier → Sacré-Cœur.
| Method | Recorded geographic distance | Gap above the exact shortest result |
|---|---|---|
| Saved geography-based route | 13.374 km | 10.359% |
| Nearest neighbor | 13.374 km | 10.359% |
| 2-opt from the saved route | 12.118 km | 0.000% |
| Exhaustive search | 12.118 km | 0.000% |
The gap is calculated as (route distance / exact distance - 1) × 100, using unrounded distances. 10.359% describes how much longer the original route is relative to the shortest result; it is not the percentage reduction measured from the original route.
Using the report's six-decimal values, 13.373781 km and 12.118469 km, the difference is approximately 1.255 km, or 9.39% of the original route. These figures are arithmetic comparisons of the recorded results. The published case provides access to the underlying record.
Recorded results, redrawn for this article. Exhaustive search establishes the reference within this small fixed-endpoint model; 2-opt is not guaranteed to match it on another problem.
What Can You Explore in the AIPOCH Open-Science .science Package?
The appeal of opening the package is that you can move beyond the final distance and follow the choices that produced it. AIPOCH Open-Science brings selected research records into a readable workspace through .science packages. A package can carry selected conversation branches, file versions, Notebook records, and verification evidence; what you can explore depends on what its creator included. The package guide explains this scope.
The public Paris package contains materials that answer different questions:
| Your question | What to look for in the package |
|---|---|
| What was the original task? | The conversation and its fixed-start, fixed-finish requirements. |
| What order was proposed first? | paris_committed_route.md: the saved visiting order and its explanation. |
| Where did the locations come from? | paris_landmark_coordinates.md: the coordinate table and linked landmark records. |
| How were distances calculated? | The Notebook code defining the geographic-distance function and route totals. |
| What did each method return? | paris_route_comparison.md: the comparison report, read alongside the saved Notebook execution output. |
| What does the difference look like? | paris_route_map.png: the archived route map, read alongside the numerical results. |
You can start wherever your curiosity leads. If you enjoy algorithms, inspect how nearest neighbor chooses its next stop. If the visual change interests you, compare the route orders and map. If you want to understand the claim of a shortest route, find the loop that enumerates the intermediate-stop permutations.
The code also contains useful small checks: every route must retain its endpoints and visit the same ten locations, and the recorded methods must not be shorter than the exhaustive reference. Those checks make the intended comparison easier to understand. They do not establish the suitability of the route for an actual walk through Paris.
This is a practical way to learn from somebody else's AI-assisted research. The conversation shows the task, the files preserve the chosen inputs and proposal, and the Notebook records expose the computation. You can connect a statement in the report with the work behind it.
Conceptual reading guide based on the inspected Paris package, not a screenshot of the application.
How Can You Follow the Paris Research Yourself?
Choose one question to investigate, then download the public .science file and import it into AIPOCH Open-Science to explore the retained history. The steps below follow the current package guide.
1. Download the Public Package
Use Download research package on the Paris case page. If you need the application, use the official download page. Follow the current package guide for instructions matching your installed version.
2. Import the Research History
On a project's empty new-conversation page, choose Import previous research, select the .science file, review the destination and contents, and complete the import. The official guide also describes supported project-menu and drag-and-drop routes.
The imported history is read-only. Opening it does not run the archived calculations or restore the sender's credentials. You can examine what was recorded before deciding whether to undertake any new work.
3. Follow One Question Through the Record
Try this small exploration: why did moving Luxembourg Gardens earlier change the route?
Find paris_committed_route.md, compare it with the shorter order in paris_route_comparison.md, and locate the relevant points in paris_route_map.png. Then look at the Notebook code's distance calculation and how it sums consecutive legs. You do not need to understand every line to see how the inputs, method, and result fit together.
A second question goes deeper: what makes the final reference exhaustive? Find the permutation search and the count of checked orders. Read that beside the fixed endpoints. The small number of intermediate stops is what makes checking all orders practical here.
4. Continue Only If You Want to Ask a New Question
You might eventually want to change a stop or use a road-distance matrix. A writable continuation requires a separate step, such as Fork, plus the files, runtime, model configuration, and permissions needed for the new task. Browsing the imported record does not perform that experiment. The official guide distinguishes these actions.
Package contents depend on export selection. Side Chat conversations and private reading bookmarks are excluded. Any verification records you receive describe the sender's checks; they do not mean your computer has repeated them.
Open the Package and See How the Route Was Found
With AIPOCH Open-Science .science packages, a familiar question can lead you into somebody else's research, from the original task to the code behind a result. The Use Case Gallery provides other public examples to explore.
Open the Paris route case and explore its .science package in AIPOCH Open-Science. Start with the two route orders. Follow the change that makes you curious.
Frequently Asked Questions
Is the Paris Example the Classic Traveling Salesman Problem?
It is a related fixed-endpoint open-path problem. Classic TSP returns to its starting location; this example starts at the Eiffel Tower and ends at Sacré-Cœur. Both involve optimizing visiting order, but their constraints differ.
Does 2-Opt Always Find the Shortest Route?
No. It matches the exhaustive result in this archived example. Local improvement alone does not establish that a route is globally shortest on another set of points.
Can I Use the 12.118 km Route as Walking Directions?
Use it to understand the recorded geographic-distance comparison. It does not include the street network, entrances, opening hours, queues, or transport conditions needed for a practical itinerary.
Does Opening a .science Package Rerun the Research?
No. Imported history is read-only, and opening it does not execute code or restore credentials. New calculations require a writable session and the necessary environment and access; see the package guide.
About This Article
Prepared by AIPOCH Editorial from the public Paris case and its archived package. The recorded computation is dated September 29, 2026. On October 22, 2026, the package retrieved through the case page's Download research package link matched the inspected archive byte-for-byte.
The inspected file's SHA-256 is 90ae5a655e26894d9ec4c96f10de042e2b5f26798a3d6f3565f4c8f89cdcad7c. This identifies the package used for the article if the online case changes later.
The package's report, Notebook code, and recorded outputs were inspected; the route analysis was not rerun. New graphics redraw the archived results or illustrate the reading process. Import instructions follow the current official guide; this editorial check did not test an application import or continuation.
Disclaimer
This article explains a bounded computational example for learning and exploration. Its results apply to the recorded coordinates and distance model, and do not provide live travel advice or establish general AI performance. AIPOCH Open-Science supports research workflows; researchers remain responsible for evaluating methods, evidence, and outputs.