[Model] EulerianPath

[zhangjieqingithub]

Motivation

The repository currently has path and walk-cover relatives such as Hamiltonian Path and Chinese Postman variants, but it does not have the classical Eulerian path feasibility problem itself.

This model is useful because it is:

• a standard directed-graph path problem in its own right,
• polynomial-time solvable, so it broadens the catalog beyond NP-hard problems,
• distinct from postman problems, which allow repeated traversals and optimize length rather than asking for an exact once-per-arc traversal.

Associated rule:

• [Rule] EulerianPath to ILP #1025: EulerianPath -> ILP

Definition

Name: EulerianPath
Reference:

• J?rgen Bang-Jensen, Gregory Z. Gutin, Digraphs: Theory, Algorithms and Applications, 2nd ed., Springer, 2009. https://doi.org/10.1007/978-1-84800-998-1
• J?rgen Ebert, ?Computing Eulerian trails,? Information Processing Letters 28(2):93-97, 1988. https://doi.org/10.1016/0020-0190(88)90170-6

Given a finite directed multigraph
D = (V, A),
with loops and parallel arcs allowed, determine whether there exists a directed trail that uses every arc in A exactly once.

Important conventions for this proposal:

• repeated arc occurrences are distinguished,
• loops are allowed,
• isolated vertices are allowed and ignored,
• a closed trail is accepted,
• the empty-arc instance is accepted, witnessed by the empty trail.

So EulerianPath is a satisfaction problem.

Variables

Let m = |A|.

• Count: m position variables
• Per-variable domain: {0,1,...,m-1}
• Meaning: the variable at position t specifies which arc occurrence is used as the t-th arc of the trail

Thus a configuration represents an ordering of the individual arc occurrences, not merely a sequence of visited vertices.

Schema (data type)

Type name: EulerianPath
Variants: none initially

Field	Type	Description
graph	DirectedGraph	The input directed multigraph D = (V, A), with repeated arcs and loops allowed

No start or end vertex is part of the input; they are existential.

Complexity

EulerianPath on directed multigraphs is solvable in linear time.

A standard algorithm:

1. ignores isolated vertices,
2. checks weak connectivity of the support,
3. checks the in-degree / out-degree balance condition,
4. constructs a witness by a Hierholzer-style traversal.

This gives complexity
O(num_vertices + num_arcs).

References:

• https://doi.org/10.1007/978-1-84800-998-1
• https://doi.org/10.1016/0020-0190(88)90170-6

Extra Remark

Let S be the set of vertices incident to at least one arc. Then the instance is a yes-instance iff either:

• A is empty, or
• the underlying undirected graph on S is connected and:
  • either every vertex satisfies outdeg(v) = indeg(v),
  • or there exist vertices s != t such that
    outdeg(s) = indeg(s) + 1,
    indeg(t) = outdeg(t) + 1,
    and every other vertex is balanced.

Loops contribute 1 to both indegree and outdegree of their incident vertex.

Reduction Rule Crossref

• [Rule] EulerianPath to ILP #1025

How to solve

• It can be solved directly in O(num_vertices + num_arcs) by the standard degree/connectivity test plus Hierholzer-style witness construction.
• It can be reduced to ILP via [Rule] EulerianPath to ILP #1025 ([Rule] EulerianPath to ILP).
• Other, refer to ...

Example Instance

Let

• V = {0,1,2}
• A = {a_0, a_1, a_2, a_3}

with arc occurrences

• a_0 = (0,1)
• a_1 = (0,1) (parallel to a_0)
• a_2 = (1,2)
• a_3 = (2,0)

This is a directed multigraph with a repeated arc.

Expected Outcome

This is a yes-instance.

One valid witness is the arc ordering
(a_0, a_2, a_3, a_1),
which traces the directed trail
0 -> 1 -> 2 -> 0 -> 1.

It uses every arc occurrence exactly once, including both copies of the arc (0,1).

A small no-instance for contrast is:

• V = {0,1}
• A = {(0,1), (0,1), (0,1), (1,0)}

Here the support is connected, but

• outdeg(0) - indeg(0) = 2
• indeg(1) - outdeg(1) = 2

so the directed balance criterion fails and no Eulerian path exists.

BibTeX

@book{BangJensenGutin2009Digraphs,
  author    = {J?rgen Bang-Jensen and Gregory Z. Gutin},
  title     = {Digraphs: Theory, Algorithms and Applications},
  edition   = {2},
  publisher = {Springer London},
  year      = {2009},
  doi       = {10.1007/978-1-84800-998-1},
  url       = {https://doi.org/10.1007/978-1-84800-998-1}
}

@article{Ebert1988ComputingEulerianTrails,
  author  = {J?rgen Ebert},
  title   = {Computing Eulerian trails},
  journal = {Information Processing Letters},
  volume  = {28},
  number  = {2},
  pages   = {93--97},
  year    = {1988},
  doi     = {10.1016/0020-0190(88)90170-6},
  url     = {https://doi.org/10.1016/0020-0190(88)90170-6}
}

[isPANN]

Issue Quality Check — Model

Check	Result	Details
Usefulness	Pass	Novel problem; planned reduction [Rule] EulerianPath to ILP (#1025) is linked
Non-trivial	Pass	Distinct feasibility from Hamiltonian/Postman families; arc-ordering semantics on directed multigraphs
Correctness	Pass	Polynomial-time claim and degree/connectivity criterion are standard and correct
Well-written	Warn	Mechanical: BibTeX author encoding (J?rgen should be Jürgen); variable-domain encoding deserves a sentence on the implied search space

Overall: 4 passed, 1 warning

---

Usefulness

• pred show EulerianPath returns "Unknown problem", confirming the model is novel in the catalog.
• The companion [Rule] EulerianPath to ILP issue [Rule] EulerianPath to ILP #1025 is referenced both under "Associated rule" and in "Reduction Rule Crossref", giving the new node at least one planned connection to the existing reduction graph (avoids the orphan-node failure).
• Motivation is concrete and grounded: explicitly contrasted with HamiltonianPath/HamiltonianCircuit (vertex-once, NP-hard) and MixedChinesePostman/RuralPostman (arc-cover with repetition allowed, optimization). The polynomial-time decision flavor genuinely broadens the catalog — it gives the reduction graph a natural polynomial-time gateway that downstream Eulerian-style reductions (e.g., the postman-family lower bounds discussed in reductions.typ) can plug into. Useful even though it is in P.
• "How to solve" lists both the direct linear-time algorithm and the ILP path via [Rule] EulerianPath to ILP #1025.

Non-trivial

• Feasibility constraint (use every arc exactly once on a directed multigraph, with loops + parallel arcs) is structurally different from:
  • HamiltonianPath/DirectedHamiltonianPath (every vertex once, NP-hard),
  • MixedChinesePostman/RuralPostman (cover required edges, repeats allowed, minimize length).
• The arc-occurrence ordering encoding (m position variables, each picking which arc occurrence sits at that position) is a genuine distinct configuration space — it preserves the multiplicity information of parallel arcs, which a pure vertex-sequence encoding would lose.
• Not a renaming / variant / subtype coercion of any existing problem.

Correctness

Definition / complexity. EulerianPath on directed multigraphs is a textbook polynomial-time problem. The cited criterion — weak connectivity of the support plus the in/out-degree balance (either all balanced, or exactly one +1 source and one +1 sink) — is the standard Euler theorem for directed multigraphs (see Bang-Jensen & Gutin §1.6). Hierholzer-style construction is linear in |V| + |A|, so the O(num_vertices + num_arcs) claim is correct. The handling of loops (+1 to both in- and out-degree), isolated vertices (ignored), and the empty-arc instance (vacuously a yes-instance) are the standard conventions.

References. Both citations are real and authoritative:

• Bang-Jensen & Gutin, Digraphs: Theory, Algorithms and Applications, 2nd ed., Springer 2009 — the canonical digraphs reference. DOI matches Springer's standard pattern. Chapter 1 (Basic Terminology, Notation and Results) covers Euler trails / circuits on digraphs.
• Ebert, "Computing Eulerian trails", Information Processing Letters 28(2):93-97, 1988 — well-known linear-time construction. DOI matches Elsevier's IPL pattern.

Neither is currently in docs/paper/references.bib; both should be added during implementation. The BibTeX block in the issue body has a minor encoding glitch (J?rgen instead of Jürgen) but is otherwise complete.

Schema feasibility. The Schema uses DirectedGraph, which already exists in src/topology/directed_graph.rs and (per its rustdoc) supports self-loops; parallel arcs are also representable since arcs() returns a Vec<(usize, usize)> and other models (e.g., MixedChinesePostman, DirectedTwoCommodityIntegralFlow) treat repeated arcs as multigraph edges. So the schema is implementable as written.

Well-written

Template completeness. All required sections are present and substantive: Motivation, Name, Reference (two cites with DOIs), Definition (formal input + feasibility constraint + conventions), Variables (count + domain + meaning), Schema (one field with type), Complexity (with citations), How to solve (both linear-time and ILP boxes ticked, with #1025 linked), Example Instance (4 arcs including a parallel pair), Expected Outcome (yes-instance witness + contrasting no-instance with degree analysis), BibTeX.

Definition. Conventions on loops, parallel arcs, isolated vertices, closed trails, and the empty-arc case are all stated explicitly — this is exactly the kind of edge-case documentation the model needs before downstream rules are written.

Example quality. The yes-instance has 4 arcs with a parallel pair (0,1) (a_0 and a_1) and traces a non-trivial directed trail 0→1→2→0→1 using arc ordering (a_0, a_2, a_3, a_1). The contrasting no-instance shows a connected support that fails the balance criterion — this is a good "almost yes" case that would catch a buggy implementation that only checks connectivity. Both feasibility paths (satisfying and not) are exercised, satisfying the round-trip rule of thumb.

Warnings (mechanical):

• BibTeX entries have author-name encoding artifacts: J?rgen should be J{\"u}rgen (or Jürgen). Same issue in the Reference list at the top.
• The Variables section says m position variables, each with domain {0, ..., m-1}. This implies dims = [m; m] and a configuration space of m^m, of which only m! are valid arc permutations and far fewer are valid trails. This is a legitimate encoding choice (it matches how other ordering problems are encoded), but the issue should add a sentence stating that most configurations are infeasible and the feasibility check enforces the trail constraint — this helps the implementer pick the right evaluate() semantics.

Recommendations

• When adding the model, add both citations to docs/paper/references.bib (fix the J?rgen → Jürgen encoding at that point).
• Consider whether a thin EulerianCircuit (closed-trail) sibling is worth filing later, or whether closed trails should remain implicit yes-cases of EulerianPath (the current proposal already accepts closed trails — keep this explicit in the implementation tests).
• For the ILP rule ([Rule] EulerianPath to ILP #1025), the example here is too small to stress-test the formulation; expect to add a richer example there.

[isPANN]

/review-structural — commit fde5036 (post-impl, code-quality + bug sweep)

Verdict: pass — model is structurally complete, semantics match the issue, and all registration sites are wired correctly.

Issue compliance

• Mathematical definition matches issue: yes — directed multigraph D=(V,A), every arc used once, parallel arcs distinguished, isolated vertices ignored, closed trails accepted, empty-arc instance trivially yes.
• Schema fields match: yes — single field graph: DirectedGraph; no variants; satisfaction framing via type Value = Or.
• Canonical example: ok — issue's 3-vertex / 4-arc YES instance with parallel arcs (0,1)(0,1)(1,2)(2,0) and witness [0,2,3,1] registered via inventory; the matching 2-vertex NO instance is exercised in the unit tests.

Findings

• Blockers (correctness): none.
• Nits (quality/HCI): none material.
  • Minor: dims() = vec![m; m] makes the brute-force search space m^m rather than m!; harmless at canonical size (m=4 → 256 configs) and matches the standard pattern of letting evaluate filter non-permutations, but flagging as a future tightening opportunity if someone tries to brute-force m≥10 instances.
  • Minor: test_eulerian_path_brute_force_yes_instance asserts find_all_witnesses is non-empty without pinning the count; for this instance both parallel arcs are interchangeable so at least 2 witnesses exist. Strictly accurate test, just not tight.

Structural checklist (model)

• Model file src/models/graph/eulerian_path.rs: PASS
• inventory::submit! ProblemSchemaEntry + ProblemSizeFieldEntry: PASS
• Serialize/Deserialize derives: PASS
• Problem impl with NAME = "EulerianPath", Value = Or: PASS
• #[cfg(test)] #[path] test link: PASS
• Test file with 11 tests (creation, evaluate_valid_witness, evaluate_not_permutation, evaluate_bad_trail, evaluate_out_of_range, evaluate_wrong_length, brute_force_yes_instance, no_instance, empty_arcs_instance, serialization_roundtrip, variant_and_name): PASS
• Registered in src/models/graph/mod.rs (mod, pub use, and canonical_model_example_specs): PASS
• declare_variants! with complexity "num_vertices + num_arcs" — getters validated at compile time: PASS
• CLI schema-driven create wired via --arcs / --num-vertices plus example entry in schema_support.rs (line 1798): PASS
• Paper display-name entry (line 212), problem-def block with YES/NO examples and CeTZ figure (lines 1141-1217): PASS
• References.bib: both BangJensenGutin2009Digraphs and Ebert1988ComputingEulerianTrails added with correctly-encoded names (J{\o}rgen, J{"u}rgen) — fixed mojibake from issue body.
• No blacklisted auto-generated files in diff (no reduction_graph.json, problem_schemas.json, or examples.json).

Semantic review

• evaluate() correctness: OK — is_valid_eulerian_trail checks (1) length matches m, (2) permutation of 0..m, (3) consecutive arcs chain head-to-tail. Empty-arc base case (m=0) handled explicitly. Weak-connectivity of the support is enforced implicitly by the chaining condition.
• dims() correctness: OK — vec![m; m] is consistent with config semantics (position t picks an arc index in 0..m-1).
• Size getter consistency: OK — num_vertices() and num_arcs() match both the complexity expression and ProblemSizeFieldEntry::fields.
• Scope discipline: PR correctly excludes the EulerianPath -> ILP rule (deferred to [Rule] EulerianPath to ILP #1025); paper entry at commit fde5036 contains no reduction-rule block for EulerianPath (added later in [Rule] EulerianPath to ILP #1025 / 27a5c7c). Consistent with the one-item-per-PR convention.