[Anai-Guo]

vector/v.generalize/testsuite/v_generalize_test.py uses math.sqrt in
TestVGeneralize.distance(), but the module never imports math:

from grass.script import core as grass
from grass.gunittest.case import TestCase
from grass.gunittest.main import test
from grass.script import vector_info_topo
import tempfile
import os

test_chaiken_algorithm calls self.distance(midpoint, vertex) (line 256) inside
its midpoint-proximity loop, so the test raises NameError: name 'math' is not defined on the first iteration and never reaches the assertLessEqual /
vertex-count assertions it was written to make.

Fix: add the missing import math.

Verification

Stubbing grass.script / grass.gunittest and calling the method directly
(no GRASS build needed):

BEFORE (upstream main): NameError: name 'math' is not defined
AFTER  (with fix):      distance((0,0),(3,4)) = 5.0

ruff check --preview and ruff format --check (v0.15.17, the pinned
.pre-commit-config.yaml rev, with the repo pyproject.toml) pass on the
patched file. I001 is already disabled for vector/**.py, but the three
standard-library imports are left alphabetically ordered anyway.

---

AI-assisted (bug found by a pyflakes sweep, fix and verification reviewed by
me before submitting); per CONTRIBUTING.md the change is a one-line import,
not generated logic.

🤖 Generated with Claude Code

[echoix]

Can you show me how it was failing in an existing CI run? I can't understand why we wouldn't have caught it yet

[Anai-Guo]

You're right to push back — it is not failing in CI, and it never has. I dug into
the actual test report artifact and the reason is more interesting than the missing
import. Short version: the only code path that reaches math is dead, so the test
passes vacuously.

What CI actually does with this file

vector/v.generalize/testsuite/v_generalize_test.py is collected and executed —
it shows up in the ubuntu / vector job of the latest main run
(34580256028, job
ubuntu (24.04, db display … vector visualization)):

Running ./vector/v.generalize/testsuite/v_generalize_test.py...
…
Executed 298 test files in 0:28:37.
From them 298 files (100.0%) were successful and 0 files (0.0%) failed.

and its test_keyvalue_result.txt in the testreport artifact says:

name=v_generalize_test
status=passed
returncode=0

with Ran 4 tests in 2.810s / OK.

Why it passes despite math being undefined

extract_vertices() calls v.to.points without layer=-1:

grass.run_command(
    "v.to.points",
    input=vector_name,
    output=f"{vector_name}_vertices",
    use="vertex",
    overwrite=True,
)

The test lines are created without categories, so v.to.points skips them. From the
same artifact's stderr.txt, the two extract_vertices() calls inside
test_chaiken_algorithm:

WARNING: 1 features without category in layer <1> skipped. …
v.to.points complete. 0 points written to output vector map.
WARNING: No points found, nothing to be exported
…
v.to.points complete. 0 points written to output vector map.
WARNING: No points found, nothing to be exported

Both return []. So:

for i in range(len(original_vertices) - 1):   # range(-1) -> empty
    …
    dist = self.distance(midpoint, vertex)    # never executed

range(-1) is empty, the body never runs, self.distance() is never called, and the
NameError stays latent. The assertLessEqual(min_distance, tolerance) midpoint
check never executes either.

(The 4 points / 16 points you see right afterwards in the log come from
count_vertices(), which does pass layer=-1 — that's why only the final
assertGreater(output_vertices, input_vertices) is doing real work.)

test_hermite_interpolation has the same shape:

original_vertices = self.extract_vertices("test_hermite")
generalized_vertices = self.extract_vertices("hermite_line")
for vertex in original_vertices:          # empty
    self.assertIn(vertex, generalized_vertices, …)

so the "computed line always passes through the original line" assertion — the thing
the test is named after — is also a no-op today.

So what should this PR be?

The one-line import math on its own is correct but only removes a landmine; it does
not make anything run. The actual fix is layer=-1 in extract_vertices() (matching
count_vertices() right below it), and then import math is required for the test
to get past the first iteration.

I did not push that here because turning on two previously-dead assertions is a
behaviour change I shouldn't make unilaterally — assertLessEqual(min_distance, 0.1)
on the Chaiken output and assertIn(vertex, generalized_vertices) on the Hermite
output may or may not hold with the current implementations, and if they don't the
right answer might be to fix the tolerance/assertion rather than the module.

Happy to go either way:

1. Keep this PR minimal (import math only) and open a separate issue for the
   dead assertions, or
2. Extend this PR to add layer=-1 + import math and let CI tell us whether the
   two assertions actually hold — I can push that immediately if you prefer.

Just say which and I'll do it.

🤖 Generated with Claude Code

[echoix]

@Anai-Guo, that message was for you, the human

[petrasovaa]

Please read our AI policy and keep it clear and short.