planimeter

What it is

An agent edits a drawing and reports the edit. “I added a wall that splits the room in two.” The person who asked wants to know one thing: did the number of enclosed rooms change? planimeter answers that question for any SVG line drawing an agent writes. It reads the lines out of the file, never draws a picture, and returns three integers: pieces, the number of connected parts of the line work; faces, the number of enclosed regions; and χ, the Euler characteristic, which for planar line work is pieces minus faces.

Getting those three integers from a correct graph is easy. Euler’s identity gives all three from the vertex count, the edge count and the number of connected pieces, and the code that does it is one union-find pass. The README says it plainly: “This is 18th-century arithmetic and it is not where the risk is.” The risk sits one step earlier. A drawing is a list of segments with floating-point endpoints, and two endpoints written $10^{-7}$ apart may be one corner drawn twice or two corners that happen to be close. Merge them and a wall closes a room. Keep them apart and the wall is a dangle. So the hard part, in the README’s words, is “deciding which endpoints are the same endpoint”.

planimeter makes that decision from the data. It lists every separation the answer could turn on (corner to corner, and corner to a wall it does not touch), sorts them, and looks for a wide empty stretch: two consecutive values whose ratio is at least $\rho = 10$. Below that stretch is the drawing’s wobble. Above it is real geometry. Endpoints closer than the bottom of the stretch are one vertex. The grouping cannot change anywhere inside the stretch, so it survives a tenfold change in tolerance, and the tool prints the stretch on every answer.

When there is no such stretch, or when a line end sits inside the doubtful range beside a wall it does not quite touch, planimeter does not pick one of the two integers. It refuses. The refusal gives the reason, the coordinate in the file’s own units, the id of the element that owns it, and one action. A refusal is falsy in Python, and asking for its integer raises TypeError. The README puts the rule in five words: “A refusal is never a number.”

The case that motivates all of this is small. Take a 10-unit square and a crosswall from the top edge down to a point $2.2\times10^{-6}$ above the floor. If the gap is closed, the wall divides the room and there are 2 faces. If it is left open, the wall is a dangle and there is 1 face. “Nothing in the file says which.” A rounding snap, a GEOS polygonizer or a rasteriser will each return one of the two integers, because returning an integer is what they do. planimeter returns the coordinate (5, 2.2e-06) and the band (0, 5) the end sits in.

The intended user is an agent, not a person at a CAD station. planimeter init installs the tool as a PostToolUse hook in the agent’s harness. After every write to an .svg file, the hook stamps one line into the agent’s context, for example planimeter walls.svg pieces 1 faces 4 -> 5, and stays silent on every other write. The agent never has to look at the picture to know what it drew.

The README credits my project tangle as the template for the shape of the tool: an exact integer, a one-directional certificate, a typed refusal that names what to re-observe, and a benchmark with controls.

What it can do

The headline is on a constructed stratum, where the truth is known because the drawings were built. There are 44 figure families: segments, triangles, squares, a T-junction, an H, a noded pentagram, trees, grids from 2×2 to 12×12, and theta, chain, comb and ladder graphs. Each family is jittered at six levels of $\sigma/g$ from $10^{-7}$ to $10^{-2}$, where $g$ is the figure’s own smallest feature gap, with two seeds each. That gives 528 drawings. A test parses corpus.py and asserts that it imports nothing from the package’s counting, snapping or arrangement code, so the answer key cannot borrow the arithmetic it grades.

The same 528 files, through the arms the repo ran against it:

Two controls make these rows readable. The refuse-on-anything control also scores zero wrong, which is why the README never prints planimeter’s zero without its 495. The oracle control was built to show that the counting layer adds nothing. It hands shapely planimeter’s own certified radius and lets GEOS do the rest. If it had scored zero, the whole contribution would have been the printed tolerance. It scored 22 wrong. RESULTS.md describes them as chain(k) and similar figures, where the shared-edge structure survives snapping but not GEOS’s noding, and notes that the 22 rows were not individually inspected.

The raster arm is the third method: rasterise the strokes and take skimage.measure.euler_number. On every eighth draw (66 of the 528) it gets 2 wrong at 512 px and 7 wrong at 4096 px, so the higher resolution does worse. euler_number is exact and linear, and the repo makes no speed claim against it. The point is that it needs a resolution, and its answer moves with that resolution.

Running it on your own drawing is the plainest way to see what it does. The next figure runs a browser port of the pipeline on straight line work you draw or paste. You get planimeter’s full report (integers, snap window, ratio, radius, number of candidate windows tried) or its refusal block, and next to it the round-6 strawman’s integer for the same input. The presets include the README’s 2×2 grid. Its window there is $[1.819\times10^{-12},\,1)$, with ratio $5.498\times10^{11}$ and radius $1.349\times10^{-6}$, and the line printing it is the one the README calls “the line no other tool prints”.

The tool also checks claims. planimeter check plan.svg --faces 5 returns HELD (exit 0), BROKEN (exit 1) or REFUSED (exit 2). Three states, not two, so that “the tool could not answer” never reads as “your prediction was wrong”. init adds two lines to CLAUDE.md asking the agent to state its predicted count before an edit. The README calls that “a nudge, not a result”, and whether agents follow it is unmeasured.

The hook is built to stay installed, and the README lists four contract clauses: silence is the default; bounded work or a budget refusal, never a stalled turn; any exception exits 0 with empty stdout; and it never writes to a geometry file. A refusal stamps a line only when its reason changes, because “Thirty identical refusal lines in a session train an agent to ignore the tool.” The suffix test runs before any package import, so a write to notes.py costs about one interpreter start and prints zero bytes.

What these rows support is a range: the silent path costs “under about 15 ms” over a bare interpreter, and the suffix check saves 84 to 105 ms per non-geometry write across seven runs. The stamp body is 7 cl100k_base tokens, plus 5 for the path.

On files nobody in the repo drew, there is no answer key. The repo therefore reports refusal rates and agreement between methods, never accuracy. On 13,681 npm icon files (tabler, feather, bootstrap), planimeter answers 10,862 (79.4%) with a median of 37 ms. On 30 icons committed to the repo, it answers all 30. The round-6 snap gives a different integer on 7 of those 30, and skimage.euler_number at 4096 px, a different library working on a different representation, agrees with planimeter’s integer on all 7.

How it was made

The pipeline is a fixed sequence, and no step creates a coordinate:

exact dedup → Euclidean minimum spanning tree → candidate windows → cluster → subdivide at existing vertices only → dedup edges → check no remaining crossing → count.

The counting layer

For a graph drawn in the plane, where $F$ counts every face including the single unbounded one, Euler’s identity is

Write $\mathrm{faces} = F - 1$ for the enclosed faces. The three printed integers then follow in two lines of algebra:

A triangle has $V = 3$, $E = 3$, $C = 1$, so faces $= 1$ and $\chi = 0$. In code it is the end of count() (planimeter/count.py:106-111 @ 564427f):

    v = n_vertices
    e = len(edges)
    pieces = dsu.n_sets
    faces = e - v + pieces
    return Counts(v=v, e=e, pieces=pieces, faces=faces, chi=v - e,
                  dangles=sum(1 for d in degree if d == 1))

The docstring says what this layer can and cannot claim: “Given a correct edge list this file cannot be wrong, and nothing in it is evidence that the edge list is correct.” The rest of the package exists to make the edge list trustworthy.

The merge spectrum

Exact duplicates come first. Bitwise-equal coordinates are one point, with -0.0 normalised to +0.0. This is an identification, not a tolerance. Without it, a clean file with every corner written exactly would have no cluster structure, and the gap search would reach into the drawing’s own length distribution.

Write $\pi(r)$ for the partition of the remaining endpoints into groups at tolerance $r$, meaning the connected components of the graph with an edge wherever $d(p,q) \le r$.

The whole spectrum of radii worth considering is therefore $n-1$ numbers, computed once:

The tree is built by all-pairs Prim, vectorised, $O(n^2)$ and exact. The design first specified GEOS’s Delaunay triangulation plus Kruskal, relying on the fact that the EMST is a subgraph of a Delaunay triangulation. Measured on 793 point sets, shapely.delaunay_triangles under GEOS 3.13.1 left out a true EMST edge on one of them. That set was in the clustered stratum, which is exactly the kind of input this tool exists for, and the resulting tree was 25.7% heavier. A spectrum from a wrong tree certifies a scale the drawing does not have, so Delaunay was dropped, and shapely and GEOS left the runtime dependencies with it.

The spectrum is more than the merge heights, and snap.py records that both of the following were bugs it once had. First, it includes every vertex-to-non-incident-segment distance. For segment $AB$ and vertex $p$,

$t = \operatorname{clip}\!\big((p-A)\cdot(B-A)/|B-A|^2,\,0,\,1\big)$, $c = A + t(B-A)$, $d = |p - c|$,

with incident pairs masked out. The face count turns on vertex-to-edge incidence, so a gap search over vertex pairs alone cannot see a wall that misses its floor by $2.2\times10^{-6}$. It also invents a doubt that is not there: in a triangle with sides of 10, the smallest vertex-pair separation is a side, so the apex, 8.66 from its own base, would read as ambiguous. Second, the spectrum starts at a representability floor $\delta = 4096 \cdot 2^{-52} \cdot m$, where $m$ is the largest absolute coordinate. Separations below $\delta$ are float noise and merge unconditionally.

The window

A candidate window is a pair of consecutive spectrum values, and it is certified when

By the cut property, the closest two groups are exactly $t_{\text{above}}$ apart, so the grouping cannot change until the tolerance reaches the top of the window. Because the window is at least $\rho$ wide, “the grouping survives a tenfold change in the tolerance.” The README is precise about what that does not mean: “That is strictly weaker than “the grouping is right”, and saying which of the two is claimed is the entire point of the tool.” snap.py also gives the reason no separation check is run: “a predicate that cannot fail is not evidence.”

The candidate list is short, and its order matters (planimeter/snap.py:307-312 @ 564427f):

    lo, hi = s[:-1], s[1:]
    ratio = hi / lo
    ok = np.nonzero(ratio[1:] >= rho)[0] + 1            # genuine gaps only
    order = list(ok[np.argsort(-ratio[ok], kind="stable")])
    if ratio[0] >= rho:
        order.append(0)                                  # merge nothing, last

Genuine gaps are tried widest ratio first. The gap between the floor and the smallest real separation, which I call the merge-nothing window, is offered last. Its ratio is huge for a purely arithmetic reason: the floor is a few thousand ulps of the drawing’s magnitude. Ranked with the others it would always win, and “every jittered endpoint is its own vertex” would become the preferred reading of every file. At most CAND_MAX = 4 windows are kept. A window that would put more than CLUSTER_MAX = 16 endpoints into one vertex is dropped. The radius printed with an answer is the geometric mean $\sqrt{t_{\text{below}}\,t_{\text{above}}}$, the point furthest from both edges of the window on a log scale.

The preconditions, and the refusal policy

A window that passes the ratio test still has to survive the arrangement. _try_window checks, in this order:

• Margin. $t_{\text{above}} \gt 64 \cdot 2^{-52} \cdot M$, where $M$ bounds the coordinates. Above this margin, every float64 orientation and incidence sign the pipeline computes is correct, so no rational arithmetic is needed.
• P1, every edge survives. No input segment may have both endpoints in one cluster.
• P2, robustness. Every (vertex, non-incident edge) pair must sit at distance exactly zero or at least $t_{\text{above}}$:

• P3, plane embedding. After subdivision and edge deduplication, no two segments may intersect except at a shared vertex.

P2 is the check the tool turns on. A distance of exactly zero means the vertex already lies on the edge, so the edge is subdivided there. No coordinate is created, because the point already exists in the file. A distance strictly between zero and $t_{\text{above}}$ is the ambiguous band, and it refuses (planimeter/arrange.py:407-421 @ 564427f):

    band = np.nonzero(d > 0.0)[0]
    if len(band):
        rows = [{"xy": [float(R[vi[k], 0]), float(R[vi[k], 1])],
                 "element": _vertex_owner(vi[k], ends, labels, ids),
                 "edge": owner[ei[k]], "d": float(d[k])} for k in band]
        rows.sort(key=lambda r: r["d"])
        sites, more = _sites(rows)
        return Refused(REASON.VERTEX_NEAR_EDGE,
                       detail="%d vertex%s inside the ambiguous band (0, %g)"
                              % (len(band), " sits" if len(band) == 1 else "es sit",
                                 w.t_above),
                       look_at=sites, n_more=more,
                       action="move this end onto the wall, or away from it by more than %g"
                              % w.t_above,
                       source=src)

P3 is a strict four-sign orientation test. P2 has already removed endpoints lying on edges and collinear overlaps, so whatever is left is a proper crossing, and by the margin lemma its signs are correct in float64. planimeter never computes an intersection point. When two segments cross at a point the file does not contain, the answer is EDGES_CROSS plus the crossing’s location, given for information only, never inserted into the graph.

What happens after a failure is a policy, and the code states it. EDGE_COLLAPSED and MARGIN_TOO_SMALL mean the window is wrong for this drawing, so the next window is tried. VERTEX_NEAR_EDGE and EDGES_CROSS mean the drawing is ambiguous or unnoded. A finer window would find a reading where the near miss counts as a clean miss, and the comment in arrange.py says what returning that would be: “choosing the reading that happens to certify”. Those refusals end the run.

Curves have no vertex set, so flattening them invents one. A file with curves is run twice, at $N = 16$ and $N = 32$ samples per curve, and the verdict stands only if (status, pieces, faces, χ) agree; otherwise it refuses CURVE_UNSTABLE. read.py calls this “Evidence, not a theorem”. A budget refusal on the second pass is reported as a budget refusal, not as an unstable curve. Every refusal carries a kind: geometry means re-observe the drawing, budget means this machine ran out of room. The default ceiling is BRUTE_MAX = 2000 distinct vertices, and --max-vertices raises it.

There is no Lean in this repository. The guarantees above are a cited theorem (Gower and Ross, with Kruskal’s cut property), two lemmas stated in arrange.py (the float64 margin, and that deduplication is exact under P3), and measurements against independent implementations, listed in RESULTS.md §7. Each of the seven working modules (snap, arrange, count, read, result, hook, cli) has a runnable self-check, for example python -m planimeter.snap.

What’s new in it

The usual way to decide which endpoints are the same is to choose a tolerance and apply it: round coordinates to six decimals and hash them, or hand GEOS a grid through shapely.set_precision. The tolerance is the caller’s guess, it is not printed with the answer, and the answer always comes back as an integer. On the stratum above, that approach gives 350 and 299 wrong integers out of 528. planimeter derives the tolerance from the drawing, prints the window $[t_{\text{below}}, t_{\text{above}})$, its ratio and whether it was derived or supplied by the user, and refuses when the drawing does not support one.

The usual way to count faces is shapely.polygonize_full. It is faster and more general, and, as the README says against an earlier draft of its own claims, it has a real diagnostic: it returns polygons, cut edges, dangles and invalid rings. What it does not return is which identification of endpoints produced the count. On the jitter stratum it gets 336 wrong, and its first wrong answer is the T-junction at $\sigma/g = 10^{-7}$: truth 2, answer 0.

The usual way to avoid choosing a tolerance is to rasterise and count holes. That swaps the tolerance for a resolution, and the answer moves with the resolution: 2 wrong at 512 px and 7 at 4096 px on the same 66 draws. On the clean families, planar K4 disagrees with the arrangement at both resolutions, because 8-connected ink closes a background pocket at each shallow junction (5 holes against 3 bounded faces), and theta(4) disagrees only at 512 px.

The usual way to make geometry exact is exact predicates, as in CGAL. The README credits CGAL with doing that “properly, for decades”. Exact arithmetic answers the exact question, though. It makes two nearly coincident vertices genuinely distinct and returns the exact face count of a graph nobody intended to draw. planimeter is asking the intended question, and its answer is either a scale with stated stability or a refusal.

The free parameter in all of this is $\rho$, and the repo published what moving it does rather than asserting that a higher $\rho$ is safer.

Raising $\rho$ does not make the tool stricter. It removes the genuine merge window, whose ratio the drawing limits, and leaves the merge-nothing window, whose ratio is drawing scale over machine epsilon. The repo’s conclusion is “Zero-wrong is a claim about rho <= 10”, and bench.py prints that paragraph under its table on every run.

What no one else built

Each ingredient here has a close relative in earlier work, so I will name them before saying what differs.

• Single-linkage clustering over a minimum spanning tree. Gower and Ross (1969) showed that the MST carries all the information in a single-linkage analysis, which is the theorem the window rests on. Zahn (1971) clustered point sets by deleting “inconsistent” MST edges, ones much longer than their neighbours. Mojena (1977) evaluated stopping rules that choose where to cut a dendrogram from its fusion levels. All three are about where to cut and which clusters result. Whether the cut is stable under a stated factor, and a check that the resulting graph is a valid plane embedding, are not what these titles address.
• Snap rounding. CGAL’s 2D Snap Rounding turns an arbitrary-precision arrangement of segments into a fixed-precision one by rounding to the centres of a pixel grid. Iterated snap rounding (Packer and Halperin, 2002) additionally guarantees that every vertex is at least half a pixel from every non-incident edge. That guarantee is the closest relative of P2. The difference is in the direction of the work. Snap rounding moves geometry to the grid until the separation holds, so it creates coordinates and always returns an arrangement. planimeter never moves a point. It checks whether the drawing already satisfies the separation at a scale read from the drawing itself, and refuses with the offending coordinate when it does not.
• GEOS noding and snapping. GEOS’s SnappingNoder snaps vertices and intersection points together within a tolerance. OverlayNGRobust retries a failing overlay with a heuristic tolerance and then larger ones, up to a limit. That is the opposite of planimeter’s fall-through policy. GEOS escalates the tolerance until something certifies. planimeter refuses on VERTEX_NEAR_EDGE precisely because trying another scale would be “choosing the reading that happens to certify”. shapely.set_precision rounds to a caller-given grid, and polygonize_full returns the faces plus diagnostics, but not the identification behind them.
• Robust predicates. Shewchuk’s adaptive-precision predicates get exact orientation signs from float inputs by escalating precision only when the cheap estimate is uncertain. CGAL’s 2D Arrangements build exact arrangements on exact kernels. Both make the signs of predicates correct for the coordinates as given. planimeter needs correct signs too, but it gets them from a margin lemma: every predicate it evaluates is at least $t_{\text{above}}$ from degeneracy, and $t_{\text{above}}$ must exceed 64 ulps of the drawing’s magnitude. Its real question comes before the predicates. Which coordinates did the author mean to be equal?
• Floor-plan vectorisation and parsing. Raster-to-Vector (Liu, Wu, Kohli and Furukawa, ICCV 2017) predicts junctions with a network and assembles wall primitives by integer programming. CubiCasa5K (Kalervo et al., 2019) provides a 5,000-plan dataset and a multi-task parsing model. These start from images and learn which junctions exist. planimeter starts from a vector file that already states its coordinates, uses no training data, and returns either an exact count with its scale or a refusal. It does not return a learned reconstruction.

What I can say is mine is the combination, and specifically two choices. First, the merge scale is read off a gap of ratio at least $\rho$ in a spectrum that contains vertex-to-edge distances as well as vertex-to-vertex merge heights, and that spectrum is what makes a near miss visible at all. Second, when no gap exists, or a vertex sits strictly inside $(0, t_{\text{above}})$ of an edge, the output is a typed refusal carrying the coordinate, the owning element and one action. It is never an integer, and it is never a coordinate the tool made up. I have not found this combination in the work above. Absence from a search is not evidence of absence, and I do not claim it is the first. The README is also explicit that the clustering rule is about ten lines of numpy that any agent could write: “The guarantee is a policy, refuse rather than guess, not a barrier.” The README credits two of my other repositories, cleave and sigmoid, as where the widest-representable-gap rule transplants from.

The two figures below check the claim as far as a browser can.

Limitations

The advertised use case is a floor plan, and on real floor plans the tool almost never answers.

At the default ceiling, 88 of the 96 plans refuse on budget (TOO_MANY_VERTICES), 4 refuse VERTEX_NEAR_EDGE and 4 refuse EDGES_CROSS. Raising the ceiling to 6,000 admits 31 more files: 30 of them arrive at a geometry refusal and 1 at an answer. “Raising the ceiling does not buy answers on this set, it buys coordinates.” On four files checked at --max-vertices 25000, where the budget cannot bind, it is 0 of 4. The median plan has 6,398 distinct endpoints. The one plan that certifies, Akori_church_plan.svg, gives pieces 13, faces 13, χ 0 at radius $7.03\times10^{-8}$ with a window ratio of 20,218. The repo’s own diagnosis is “A published floor plan is drawn, not built”: walls end near walls, and walls cross where no corner is recorded. Those are exactly the two conditions the tool refuses.

The repo withdraws its own claims in the same voice it uses for the results:

Cost. The comfortable range is under roughly 600 segments: 43.3 ms at 544 segments, 97.2 ms at 840, and 1,880.1 ms at 3,784. The cost is the all-pairs (vertex, edge) pass. A k-d tree does not remove it, because the certificate quantifies over every such pair. On one real 22,261-vertex plan, the spanning tree took 4.50 s and the vertex-edge spectrum took 40.01 s. A sweep line is on the roadmap, with the all-pairs pass kept as its test control.

Baselines that have not run. The strongest comparison arm is a hand-written round-6 script that the benchmark itself labels STRAWMAN. RESULTS.md says it “is not the baseline the headline may be quoted against”. That baseline is G1: twenty unprompted, first-attempt agent scripts with the whole distribution published. It has not been collected, and if its median clears roughly 20 of 24 on the stratum, “the accuracy headline is dead”. The agent-written corpus with independently established truth (G5 and G6) has not been collected either. corpus/found/ is empty. No agent-written file has been measured.

The contested row. Two clean 10-unit squares 1.00 apart certify as one piece. At 1.01 apart they certify as two. There is no jitter in either file. The boundary is gap $=$ feature$/\rho$. This is inside the stated convention and outside what anyone looking at the picture would say. The repo also does not establish that the certified scale is unique. At most four windows are tried, the first one that passes wins, and a later one might have passed with a different answer.

What the count is not. faces is arrangement-theoretic and will not match what a renderer fills. Refinement stability across $N$ and $2N$ is evidence, not a theorem: two nearly tangent curves can gain or lose an intersection at any positive flattening tolerance. The tool reads SVG line work only. The hook relies on someone else’s PostToolUse payload schema, and a change there silences it. The 60 ms silent-path gate sits 8 ms above the bare-interpreter floor and failed on 3 of 11 runs, which RESULTS.md calls “a coin flip on process startup”. All results come from one machine, one OS and one Python (Windows 11, 3.11.9, numpy 2.4.6).

Chosen numbers. The README and RESULTS.md describe three constants the package chose: $\rho$, CAND_MAX and FLOOR_ULPS. snap.py also labels CLUSTER_MAX = 16 as policy, which makes four, next to the budgets BRUTE_MAX = 2000 and VE_BUDGET. The README also says the derived window involves “no tolerance you invented”, while listing $\rho$ as a choice. All of these are scale-free, printed on every answer and movable by flag, and choosing them is still choosing.

Inconsistencies between the repo’s documents. A comment in corpus.py says that at $\sigma/g = 5\times10^{-2}$ “six draws of 108” come back with a different integer. RESULTS.md measures 4 wrong of 132 at that level (44 families × 3 seeds). A comment in read.py gives the curve-relabel count as 5 of 96 plans, where RESULTS.md gives 11. RESULTS.md §2 says refusals sit at 3 to 10 of 88 per jitter level, and §11 restates it as 5 to 10. I report these as they stand and quote the tables’ numbers.

Provenance. The commits RESULTS.md cites as its machine of record are not in the depth-1 clone this essay was written from, so every number here is the repo’s reported result, and none was reproduced. The “500 passed” test count was not re-run. The live figures in this essay run their own port of the package with their own random draws, so they will not reproduce the repo’s exact counts, and their captions say so.

Read more

• Repository: github.com/teerthsharma/planimeter. There is no project site; the button above goes to the repo.
• Short link on teerth.dev: teerth.dev/planimeter.
• README.md: the exact statement, the refusal codes, the hook contract, prior art and “What we got wrong”.
• RESULTS.md: every table with its control, the arms that lost, NOT EARNED and NOT RUN, and the real-file runs.
• planimeter/snap.py: the window, the theorem it rests on, and the policy constants. Its docstring calls it “THE FILE A REVIEWER OPENS FIRST”.
• planimeter/arrange.py: P1–P3, the margin lemma and the fall-through policy.
• Related essays: tangle and separatrix, the other tools here that certify an integer or refuse; topological-ml-toolkit, for single-linkage clustering and H0 in another setting; sigmoid, named in the README as one source of the widest-gap rule.

@misc{sharma2026planimeter,
  author = {Teerth Sharma},
  title = {planimeter},
  howpublished = {\url{https://teerth.blog/planimeter}},
  year = {2026},
  note = {CC BY 4.0}
}