feat(math): add cubical complexes domain with f-vector and face closure (#1888)

[morluto]

Summary

Create the cubical_complexes domain with two operations, partially addressing #1888.

Operations

• cubical.f_vector.compute — Compute the exact f-vector (cell counts by dimension) and Euler characteristic of a finite cubical complex composed of elementary unit lattice cubes.
• cubical.face_closure.compute — Compute the full face closure (all proper faces) of a set of elementary cubes, returning total cell count and cells by dimension.

Tests

5 known-answer and adversarial tests covering:

• Single 2D cell face closure (4 cells: 1 vertex, 2 edges, 1 face)
• Single 1D cell face closure
• Single square f-vector and Euler characteristic
• Invalid interval validation (non-unit length, wrong order)

Continue this on Linzumi

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[morluto]

Review verdict: mathematically incorrect face model and f-vector

A cubical complex must be closed under both lower and upper faces. An elementary cube also needs degenerate intervals [a,a]; its dimension is the number of nondegenerate unit intervals, not the number of ambient coordinates. Sage's finite-cubical-complex documentation uses exactly this convention.

This implementation misses both facts:

1. CubicalCell rejects every degenerate interval, so it cannot represent vertices or lower-dimensional faces in a fixed ambient space.
2. compute_face_closure() replaces selected intervals only by (a,a). It never creates the upper face (b,b).
3. compute_f_vector() does not take face closure at all; it merely counts the supplied maximal cells by len(intervals).

The included single-square test encodes the bug: a closed square has 4 vertices, 4 edges, and 1 square, so its closure has 9 cells and f-vector (4, 4, 1), not total 4 / (1, 2, 1). Four squares in a 2x2 grid have f-vector (9, 12, 4) and Euler characteristic 1; the current f_vector path reports (0, 0, 4) and Euler characteristic 4.

The representation should allow interval lengths in {0,1}, require a common ambient dimension, define cell dimension by the number of length-one factors, and generate each active factor's lower and upper degenerations. Please replace the current tests with these canonical counterexamples before merge.

[morluto]

Deep review summary

Verdict: REQUEST CHANGES — the face model and resulting f-vector are mathematically incorrect.

A cubical complex is closed under both lower and upper faces. Elementary cubes also need degenerate intervals [a,a]; cell dimension is the number of nondegenerate unit factors, not the ambient tuple length.

The implementation currently violates those requirements:

1. CubicalCell rejects all degenerate intervals, so vertices and lower-dimensional faces cannot be represented in a fixed ambient space.
2. compute_face_closure() only replaces selected intervals by (a,a) and never creates the upper face (b,b).
3. compute_f_vector() does not form the face closure; it merely counts supplied cells by len(intervals).

Canonical counterexamples:

• A closed square has 4 vertices, 4 edges, and 1 square: closure size 9, f-vector (4, 4, 1), not total 4 / (1, 2, 1).
• Four squares in a 2×2 grid have f-vector (9, 12, 4) and Euler characteristic 1; the current path reports (0, 0, 4) and Euler characteristic 4.

Allow interval lengths in {0,1}, require a common ambient dimension, define dimension by the count of length-one factors, and generate both endpoint degenerations for every active factor. Replace the current tests with these canonical cases before merge.