Skip to content

The classification pipeline - #6

Open
roed-math wants to merge 1 commit into
split/04-matchersfrom
split/05-classify
Open

The classification pipeline#6
roed-math wants to merge 1 commit into
split/04-matchersfrom
split/05-classify

Conversation

@roed-math

@roed-math roed-math commented Aug 8, 2026

Copy link
Copy Markdown
Collaborator

The classification pipeline.

classify() parses, splits reducible equations into components, runs the
matchers, and ranks the results by depth in the family DAG, so the most
specific family wins. Classification.explain() is the human report and
as_dict() is the JSON contract for the future website backend.

API notes:

  • Classification separates the problem as submitted (parsed) from the model
    the matchers saw (model, read through working), with the map between them
    in reduction. Reducing (x + y)^2 = 0 to x + y = 0 used to return the
    factor's classification as if it were the input, losing the original text,
    the requested domain, the unknown order and the side conditions; all four now
    survive, and factors of a reducible equation inherit the parent's domain,
    parameters and checkable conditions instead of falling back to classify()'s
    default argument.
  • match_for(slug) / data_for(slug) look up an emitted match, and code()
    fills each family's template from its own match. Filling an ancestor's
    template with the primary match's data produced confident nonsense, because a
    DAG edge says nothing about whose data meets whose input contract.
  • explain() prints one arrow line per genuine lineage path, and as_dict()
    carries lineage_paths/lineage_graph, the structured conditions, and the
    transform — composed from the very objects the solvers use.

tests/test_classify.py starts the classification corpus (famous equation to
expected family); each family PR adds its own rows.

Part of the series that splits #1 into reviewable pieces:

  1. 01-bibliography — packaging, docs, annotated bibliography
  2. 02-parsing — equation strings to a term model
  3. 03-registry — the YAML family registry (3 seed families)
  4. 04-matchers — shape recognizers
  5. 05-classify — the classification pipeline
  6. 06-solvers — solver framework, two seed solvers, and the CLI
  7. 07..09-backbone — the 23 parent families of the DAG, by depth
  8. one PR per remaining family (38 of them, mutually independent)
  9. 99-polish — restore the full doctests and tighten the invariants

The classification pipeline.

`classify()` parses, splits reducible equations into components, runs the
matchers, and ranks the results by depth in the family DAG, so the most
specific family wins.  `Classification.explain()` is the human report and
`as_dict()` is the JSON contract for the future website backend.

**API notes:**

- `Classification` separates the problem as submitted (`parsed`) from the model
  the matchers saw (`model`, read through `working`), with the map between them
  in `reduction`.  Reducing `(x + y)^2 = 0` to `x + y = 0` used to return the
  factor's classification as if it were the input, losing the original text,
  the requested domain, the unknown order and the side conditions; all four now
  survive, and factors of a reducible equation inherit the parent's domain,
  parameters and checkable conditions instead of falling back to `classify()`'s
  default argument.
- `match_for(slug)` / `data_for(slug)` look up an emitted match, and `code()`
  fills each family's template from *its own* match.  Filling an ancestor's
  template with the primary match's data produced confident nonsense, because a
  DAG edge says nothing about whose data meets whose input contract.
- `explain()` prints one arrow line per genuine lineage path, and `as_dict()`
  carries `lineage_paths`/`lineage_graph`, the structured `conditions`, and the
  `transform` — composed from the very objects the solvers use.

`tests/test_classify.py` starts the classification corpus (famous equation to
expected family); each family PR adds its own rows.

Part of the series that splits #1 into reviewable pieces:

1. `01-bibliography` — packaging, docs, annotated bibliography
2. `02-parsing` — equation strings to a term model
3. `03-registry` — the YAML family registry (3 seed families)
4. `04-matchers` — shape recognizers
5. `05-classify` — the classification pipeline
6. `06-solvers` — solver framework, two seed solvers, and the CLI
7. `07..09-backbone` — the 23 parent families of the DAG, by depth
8. one PR per remaining family (38 of them, mutually independent)
9. `99-polish` — restore the full doctests and tighten the invariants
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants