craft: fourth module — semiring-basics (recipe-template anchor)#206
craft: fourth module — semiring-basics (recipe-template anchor)#206
Conversation
…ed + theoretical) Fourth Craft module. Builds on zset-basics + operator- composition prerequisites. Anchor: recipe template where "combine" means different things (mix / blend / add / take-minimum / OR). A semiring IS a recipe template for "arithmetics." Applied track: - When different semirings fit (counting / Boolean / tropical / max-plus / probabilistic / provenance) - Real-world examples table (counting pages / tracking returns / group membership / cheapest route / fastest project / source attribution) - F# signature sketch (SemiringSet<'K, 'S>) - Alternative comparison (separate libraries / case- matching / pin-one-forever) - Self-check gate (semiring formalism / query-over- reinterpretations / IVM guarantees) Theoretical track: - Formal semiring definition (R, +, ×, 0, 1 + distributivity) - Ring-vs-semiring (additive inverses = retraction) - Canonical semirings table (ℤ / ℕ / 𝔹 / Tropical / Max-plus / Fuzzy / Lineage / Provenance) with retraction availability - K-relations framework (Green-Karvounarakis-Tannen PODS 2007) - Zeta regime-change framing (one-algebra-maps-others) - What requires care (non-ring loses retraction; idempotence/convergence requirements; F# type-system shape) Module-level bidirectional-alignment audit: passes both directions. Preemptive MD032 '+'-at-line-start scan clean. Attribution: Otto (loop-agent PM hat). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…idates split-attention PR #206 armed: Craft semiring-basics (recipe-template anchor; 310 lines; applied + theoretical tracks). Aaron validation: 'love it Split-attention model working. that's amazing'. Filed validation memory: feedback_split_attention_model_validated_phase_1_drain_ background_new_substrate_foreground_2026_04_24.md. #205 (Zora-UX research) MERGED at 21:54:51Z. Craft now at N=4: zset-basics → retraction-intuition → operator-composition → semiring-basics. 7 consecutive substrate-producing ticks (Otto-39..46 minus Otto-45 which was background-focused). Split-attention model validated as discipline: - Background: tool-drain on Phase 1 queue - Foreground: new-substrate production Aaron's endorsement makes this a structural rule, not incidental. Attribution: Otto (loop-agent PM hat). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0b2347045e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - `subjects/zeta/zset-basics/` (ℤ-with-retraction is the | ||
| signed-integer case; this module shows why it's just | ||
| one of many) | ||
| - `subjects/zeta/operator-composition/` (operators |
There was a problem hiding this comment.
The new module declares subjects/zeta/zset-basics/ and subjects/zeta/operator-composition/ as prerequisites, but those modules are not present in this commit’s tree (the only Zeta craft modules are retraction-intuition and semiring-basics). That makes the onboarding path non-actionable for readers and breaks the “prerequisites” contract; either add the missing modules in the same change or mark these references as forthcoming/non-existent explicitly.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
Adds the fourth Zeta Craft learning module on semirings, framing semirings as the “recipe template” that Zeta’s operator algebra can plug different arithmetics into (applied track + theoretical deep dive).
Changes:
- Introduces a new Craft module: semiring definition, applied examples, and Zeta-specific framing.
- Adds semiring comparison tables + K-relations (GKT 2007) discussion + “regime-change” narrative.
- Adds module self-check gate + cross-links to related Zeta docs/code.
| # Semirings — the recipe template Zeta plugs different | ||
| "arithmetics" into |
There was a problem hiding this comment.
P2: The H1 heading is split across two lines, so only the first line is part of the heading and the second line becomes a separate paragraph. Consider making it a single heading line (or use an explicit <br> if a line break is intentional).
| # Semirings — the recipe template Zeta plugs different | |
| "arithmetics" into | |
| # Semirings — the recipe template Zeta plugs different "arithmetics" into |
| Otto (loop-agent PM hat) authored v0. Fourth Craft | ||
| module (after zset-basics / retraction-intuition / | ||
| operator-composition). Content accuracy: future Soraya | ||
| (formal-verification) review on formal definitions; | ||
| Hiroshi (complexity-theory) on shortest-path / | ||
| idempotence / Kleene-star claims; Kira (harsh-critic) | ||
| normal pass. |
There was a problem hiding this comment.
P1: The ## Attribution section includes direct contributor/agent name attribution (and review assignments). Repo standing rule is to avoid names in code/docs/skills and use role references instead; names belong only under memory/persona/<name>/ and optionally docs/BACKLOG.md when capturing a request (see docs/AGENT-BEST-PRACTICES.md:284-292). Please rewrite this section to be role-based (or remove it) to comply.
| Otto (loop-agent PM hat) authored v0. Fourth Craft | |
| module (after zset-basics / retraction-intuition / | |
| operator-composition). Content accuracy: future Soraya | |
| (formal-verification) review on formal definitions; | |
| Hiroshi (complexity-theory) on shortest-path / | |
| idempotence / Kleene-star claims; Kira (harsh-critic) | |
| normal pass. | |
| Initial draft produced via a loop-agent project- | |
| management pass. Fourth Craft module (after zset- | |
| basics / retraction-intuition / operator-composition). | |
| Content accuracy follow-up: formal-verification review | |
| on formal definitions; complexity-theory review on | |
| shortest-path / idempotence / Kleene-star claims; and | |
| a standard harsh-critic pass. |
| ```fsharp | ||
| // Instead of hard-coding ℤ: | ||
| type ZSet<'K> = ... | ||
|
|
||
| // Parameterise over semiring S: | ||
| type SemiringSet<'K, 'S when 'S :> ISemiring> = ... | ||
|
|
||
| // Same operators, different arithmetic: | ||
| count : SemiringSet<'K, ℤ> -> int64 // retractable count | ||
| count : SemiringSet<'K, ℕ> -> uint64 // plain count | ||
| count : SemiringSet<'K, 𝔹> -> bool // is-any-present | ||
| count : SemiringSet<'K, Tropical> -> float // minimum cost | ||
| ``` |
There was a problem hiding this comment.
P2: The fenced block is tagged as fsharp, but it’s not valid F# as written (placeholders like ..., and type identifiers like ℤ/ℕ/𝔹). If this is meant to be copy/pasteable, consider making the snippet syntactically valid (e.g., use int64/uint64/bool weight types or type aliases) or change the fence to text/pseudo to avoid implying it compiles.
| - `subjects/zeta/zset-basics/` (ℤ-with-retraction is the | ||
| signed-integer case; this module shows why it's just | ||
| one of many) | ||
| - `subjects/zeta/operator-composition/` (operators | ||
| compose the same way across different arithmetics) |
There was a problem hiding this comment.
P1: The prerequisite links subjects/zeta/zset-basics/ and subjects/zeta/operator-composition/ don’t resolve in-tree (under docs/craft/subjects/zeta/ there are only retraction-intuition/ and semiring-basics/). Update these links to existing modules, add the missing modules in this PR, or mark them as forthcoming to avoid sending readers to dead paths.
| - `subjects/zeta/zset-basics/` (ℤ-with-retraction is the | |
| signed-integer case; this module shows why it's just | |
| one of many) | |
| - `subjects/zeta/operator-composition/` (operators | |
| compose the same way across different arithmetics) | |
| - `subjects/zeta/retraction-intuition/` (the signed-update | |
| intuition first; this module generalises that one case | |
| into a broader arithmetic template) | |
| - Operator composition across arithmetics (forthcoming; | |
| operators compose the same way across different | |
| arithmetics) |
| | Semiring | "Combine" means | "Multiply" means | What it computes | | ||
| |---|---|---|---| | ||
| | **ℤ (signed integers)** — Zeta default | Add (with negatives for retraction) | Multiply | Retractable counts | | ||
| | **ℕ (counting)** | Add (no negatives) | Multiply | Plain multisets; no retraction | | ||
| | **𝔹 (Boolean)** | OR (either-or) | AND (both-and) | Plain sets; presence/absence only | |
There was a problem hiding this comment.
P1: The markdown tables here use || at the start of each row, which will render as an extra empty first column (and misalign the table) in standard GFM. Use a single leading | (or no leading pipe) consistently for the header and each row.
…rrect date Codex P2 findings on this PR (2026-04-23 review of commit 1fd3edb): 1. BACKLOG row cited `memory/feedback_*_2026_04_24.md` as source-of-truth, but that file lives in per-user memory (~/.claude/projects/...), not in-repo `memory/`. Per-user memory is not reachable from the repo. 2. The row listed onboarding modules (zset-basics, operator-composition, semiring-basics) as if they exist in-tree, but only retraction-intuition lives on main (the others are still open PRs #200/#203/#206). 3. The row referenced "README section" for `docs/craft/README.md` but that file doesn't exist. 4. Date was wrong — today is 2026-04-23, not 2026-04-24. Fixes: - BACKLOG row now cites the per-user memory explicitly (flagged as Overlay-A migration candidate) + `src/Core/ZSet.fs:227-230` + the just-merged PR #209 bench harness as concrete in-repo artifacts. - Module-list made honest: names retraction-intuition as merged + the others as in-flight PRs by number. - docs/craft/README.md authoring broken out as a third BACKLOG row (S-effort hygiene follow-up; currently non-existent). - Tick-history Otto-47 timestamp corrected to `2026-04-23T21:15:00Z` + memory filename reference dated _2026_04_23. Per-user memory file renamed in place (not a repo change): _2026_04_24.md -> _2026_04_23.md + dates corrected inside. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6ff16cf7f9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | Tropical | ℝ ∪ {+∞} | min | + | +∞ | 0 | No (min has no additive inverse) | | ||
| | Max-plus | ℝ ∪ {-∞} | max | + | -∞ | 0 | No | | ||
| | Fuzzy | [0, 1] | max | × | 0 | 1 | No | | ||
| | Lineage | 2^X (subsets of source tuples) | ∪ | ∩ | ∅ | X | N/A | |
There was a problem hiding this comment.
The canonical-semirings table defines lineage as (2^X, ∪, ∩, ∅, X), but for tuple-lineage/witness tracking the multiplicative step for a join must combine evidence from both sides (set union of witnesses), not set intersection. With × = ∩, joining tuples with disjoint provenance sets collapses to ∅, which loses provenance and contradicts the K-relation interpretation described later in the module. This will teach contributors the wrong algebra for provenance-style joins.
Useful? React with 👍 / 👎.
…ft + Zeta audit) (#207) * backlog: Otto-47 — checked/unchecked arithmetic discipline (production-tier Craft + Zeta audit) Aaron 2026-04-24 directive: "make sure we are using uncheck and check arithmatic approperatily, unchecked is much faster when its safe to use it, this is production code training level not onboarding materials, and make sure our production code does this backlog itmes". Two BACKLOG rows filed under new `P2 — Production-code performance discipline` section: 1. Zeta hot-path checked-vs-unchecked audit (~30 sites across src/Core/{ZSet, Operators, Aggregate, TimeSeries, Crdt, CountMin, NovelMath, IndexedZSet}.fs). Per-site bound classification (bounded-by-construction / bounded-by-workload / bounded-by-pre-check / unbounded / user-controlled / SIMD-candidate), FsCheck property tests for proved bounds, BenchmarkDotNet deltas required per demotion (>=5%). Naledi runs perf; Soraya validates bounds; Kenji integrates; Kira reviews. L effort. 2. Craft production-tier ladder with checked-vs-unchecked as first module. Distinct from onboarding tier (which lives at docs/craft/subjects/zeta/*); new structural concept = production-tier anchored on runnable BenchmarkDotNet harness + decision tree + bound-proving techniques. Naledi authorial; M effort. Memory capture: feedback_checked_unchecked_arithmetic_production_tier_ craft_and_zeta_audit_2026_04_24.md (per-user). MEMORY.md index updated newest-first. Otto-47 tick-history row appended. Canonical "keep Checked" rationale at src/Core/ZSet.fs:227-230 (unbounded stream-weight sum sign-flip risk) stays intact — directive is about demoting over-applied Checked sites, not removing all safety. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(#207): address Codex findings — verify source-of-truth paths + correct date Codex P2 findings on this PR (2026-04-23 review of commit 1fd3edb): 1. BACKLOG row cited `memory/feedback_*_2026_04_24.md` as source-of-truth, but that file lives in per-user memory (~/.claude/projects/...), not in-repo `memory/`. Per-user memory is not reachable from the repo. 2. The row listed onboarding modules (zset-basics, operator-composition, semiring-basics) as if they exist in-tree, but only retraction-intuition lives on main (the others are still open PRs #200/#203/#206). 3. The row referenced "README section" for `docs/craft/README.md` but that file doesn't exist. 4. Date was wrong — today is 2026-04-23, not 2026-04-24. Fixes: - BACKLOG row now cites the per-user memory explicitly (flagged as Overlay-A migration candidate) + `src/Core/ZSet.fs:227-230` + the just-merged PR #209 bench harness as concrete in-repo artifacts. - Module-list made honest: names retraction-intuition as merged + the others as in-flight PRs by number. - docs/craft/README.md authoring broken out as a third BACKLOG row (S-effort hygiene follow-up; currently non-existent). - Tick-history Otto-47 timestamp corrected to `2026-04-23T21:15:00Z` + memory filename reference dated _2026_04_23. Per-user memory file renamed in place (not a repo change): _2026_04_24.md -> _2026_04_23.md + dates corrected inside. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(#207): address 7 Codex/Copilot findings honestly Aaron Otto-52 directive on resolution register: "take the advice and give good response on what you fix or didn't fix and why". Findings addressed (all 7 are real): CODEX P2 (line 6626) — date inconsistency: Fixed. Directive row said 2026-04-24; audit artifacts dated 2026-04-23. Today is 2026-04-23 UTC; the -24 was a cross-tick date-drift error. Now consistent with the artifacts. CODEX P2 (line 6664) — "PR #209, merged" cited on files absent from reviewed tree: The branch HEAD now contains the bench file (after merge of origin/main where #209 landed as 3e1b97f). Reworded to cite the specific merge commit (3e1b97f) rather than just the PR number, so auditors can resolve the claim. CODEX P2 (line 6681) — Craft module cited as landed in #208 but file not in reviewed tree: Accepted — "landed" was wrong for an open PR. Reworded to "proposed in PR #208 — open; path does not yet exist on main". COPILOT P1 (line 139) — tick numbering inconsistency (`auto-loop-49` appears twice; `auto-loop-47` appended after `auto-loop-48..50`): Accepted the intent of the finding; renumbering ~50 rows across a shared history file is high-risk and erases session boundaries. Instead: added a schema clarification at file top stating that `auto-loop-N` is a per-session counter (session compaction resets it), and UTC timestamp is the canonical ordering key. This documents the actual invariant rather than faking one we can't hold. COPILOT P1 (line 6661) — per-user memory citation looks like a dead in-repo reference: Accepted the suggestion verbatim in spirit — added explicit "**out-of-repo** (per-user memory, not yet in-repo)" marker so readers don't chase a path that won't exist in-repo. COPILOT P1 (line 6630) — PR description says "Two BACKLOG rows" but section adds 3: PR description will be updated separately (same tick). Section text unchanged. COPILOT P1 (line 6697) — production-dotnet paths cited as current references, but directory not on main: Accepted. Added "**proposed in PR #208 — open; the directory itself is not yet on main**" marker where the paths appear. Findings intentionally not applied (and why): none. All 7 landed honestly; none were false positives on this review pass. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 00d4c0ba29
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | Max-plus | ℝ ∪ {-∞} | max | + | -∞ | 0 | No | | ||
| | Fuzzy | [0, 1] | max | × | 0 | 1 | No | | ||
| | Lineage | 2^X (subsets of source tuples) | ∪ | ∩ | ∅ | X | N/A | | ||
| | Provenance | N[X] (polynomials) | + | × | 0 | 1 | Depends on coefficient ring | |
There was a problem hiding this comment.
The table currently lists N[X] for provenance but says retraction “Depends on coefficient ring,” which is inconsistent with the type shown: N[X] is fixed to natural-number coefficients and therefore has no additive inverses. In this module’s own ring-vs-semiring framing, that means retractions cannot be represented losslessly, so this row teaches the wrong tradeoff when readers choose a semiring.
Useful? React with 👍 / 👎.
| | Semiring | R | + | × | 0 | 1 | Retraction? | | ||
| |---|---|---|---|---|---|---| |
There was a problem hiding this comment.
P2: The canonical semirings table header begins with ||, which will render as a blank leading column in many Markdown parsers. Prefer a single leading | for these rows to avoid the extra empty column.
| - Per-user memory | ||
| `project_semiring_parameterized_zeta_regime_change_one_algebra_to_map_others_2026_04_22.md` |
There was a problem hiding this comment.
P1 (xref): This references a "Per-user memory" file, but the semiring regime-change document appears to live in-repo under memory/project_semiring_parameterized_zeta_regime_change_one_algebra_to_map_others_2026_04_22.md. Consider updating the label (it’s not per-user) and the path so the cross-reference resolves.
| - Per-user memory | |
| `project_semiring_parameterized_zeta_regime_change_one_algebra_to_map_others_2026_04_22.md` | |
| - Project memory | |
| `memory/project_semiring_parameterized_zeta_regime_change_one_algebra_to_map_others_2026_04_22.md` |
| | Alternative | Problem | | ||
| |---|---| | ||
| | Separate library per arithmetic (e.g., graph library for shortest-path; OLAP engine for counts; vote tally for sets) | Can't share operator semantics; re-derive IVM properties per library; no composition across | | ||
| | One library, case-matching on what-arithmetic internally | Operators grow with-every-new-arithmetic; no formal guarantee of correctness | | ||
| | One library, pick-one-arithmetic forever | Misses the generalisation Zeta's algebra actually supports | |
There was a problem hiding this comment.
P2: This table header uses || at the start of rows, which creates an unintended empty first column in Markdown rendering. Switching to a single leading | on the header/separator rows will keep the table shape consistent.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 58a71dd3ab
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| just a semiring. Pure-semiring-based K-relations (per | ||
| Green-Karvounarakis-Tannen PODS 2007) support | ||
| lineage / provenance / counting but not retraction. |
There was a problem hiding this comment.
The statement that “pure-semiring-based K-relations … support lineage/provenance/counting but not retraction” is too broad and contradicts the module’s own semiring table where ℤ supports retraction. K-relations instantiated with semirings/rings that have additive inverses (e.g., ℤ) can encode retractions via negative annotations; the limitation is specific to non-invertible semirings like ℕ, 𝔹, or tropical. As written, this teaches readers that retraction is outside K-relations entirely, which misstates the framework boundary.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: becc213989
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| GKT proved that every relational-algebra result over | ||
| K-relations is **semiring-homomorphic** — changing the | ||
| semiring gives a systematic reinterpretation of the |
There was a problem hiding this comment.
The text currently states this result for "every relational-algebra result," but the GKT semiring-homomorphism theorem applies to positive relational algebra (SPJU), not arbitrary RA with non-monotone operators like difference/negation. As written, readers can infer that semiring-swapping preserves semantics for queries outside that fragment, which is incorrect and can lead to wrong expectations about what operators are validly semiring-parameterised.
Useful? React with 👍 / 👎.
| | **𝔹 (Boolean)** | OR (either-or) | AND (both-and) | Plain sets; presence/absence only | | ||
| | **Tropical (min-plus)** | Take minimum | Add | Shortest paths between nodes | | ||
| | **Max-plus** | Take maximum | Add | Longest / critical-path times | | ||
| | **Probabilistic ([0,1] fuzzy)** | Take maximum | Multiply | Possibility distributions | |
There was a problem hiding this comment.
This row is labeled probabilistic but defines combination as max, which is possibilistic/Viterbi-style behavior rather than probability accumulation. If contributors apply this as a probability semiring, alternative derivations will be collapsed instead of accumulated, yielding systematically wrong results for probabilistic interpretation; either the operation should reflect probabilistic addition semantics or the row should be renamed to fuzzy/possibilistic.
Useful? React with 👍 / 👎.
| just a semiring. Pure-semiring-based K-relations (per | ||
| Green-Karvounarakis-Tannen PODS 2007) support | ||
| lineage / provenance / counting but not retraction. |
There was a problem hiding this comment.
P1: The statement that K-relations are "pure-semiring-based" and therefore "support ... but not retraction" is misleading: rings (like ℤ) are semirings, and K-relations over ℤ do support retraction via additive inverses. Suggest rephrasing to explicitly scope the limitation to semirings without additive inverses (i.e., non-rings).
| just a semiring. Pure-semiring-based K-relations (per | |
| Green-Karvounarakis-Tannen PODS 2007) support | |
| lineage / provenance / counting but not retraction. | |
| just a semiring. K-relations over semirings without | |
| additive inverses (per Green-Karvounarakis-Tannen | |
| PODS 2007) support lineage / provenance / counting, | |
| but not retraction; K-relations over rings such as ℤ | |
| do support retraction. |
| requires ring-structure, not just semiring | ||
| - `subjects/zeta/operator-composition/` — same operators | ||
| compose across different semirings | ||
| - `docs/TECH-RADAR.md` — Tropical semiring Adopt (ring |
There was a problem hiding this comment.
P2: In docs/TECH-RADAR.md, the "11" for Tropical semiring is the Round column, not a "ring" number. Updating this wording will keep the cross-reference accurate (Tech Radar table columns are Technique | Ring | Round | Notes).
| - `docs/TECH-RADAR.md` — Tropical semiring Adopt (ring | |
| - `docs/TECH-RADAR.md` — Tropical semiring Adopt (round |
| | Semiring | R | + | × | 0 | 1 | Retraction? | | ||
| |---|---|---|---|---|---|---| | ||
| | Signed integers | ℤ | + | × | 0 | 1 | Yes (ring) | | ||
| | Counting | ℕ | + | × | 0 | 1 | No (no negatives) | | ||
| | Boolean | {T, F} | ∨ | ∧ | F | T | N/A (can't "retract") | | ||
| | Tropical | ℝ ∪ {+∞} | min | + | +∞ | 0 | No (min has no additive inverse) | | ||
| | Max-plus | ℝ ∪ {-∞} | max | + | -∞ | 0 | No | | ||
| | Fuzzy | [0, 1] | max | × | 0 | 1 | No | | ||
| | Lineage | 2^X (subsets of source tuples) | ∪ | ∩ | ∅ | X | N/A | | ||
| | Provenance | N[X] (polynomials) | + | × | 0 | 1 | Depends on coefficient ring | | ||
|
|
There was a problem hiding this comment.
The canonical semirings table also uses || at line starts, which will render as an extra empty column. Use a single leading | for the header/separator/rows to avoid a spurious blank column.
| - `subjects/zeta/zset-basics/` (ℤ-with-retraction is the | ||
| signed-integer case; this module shows why it's just | ||
| one of many) | ||
| - `subjects/zeta/operator-composition/` (operators | ||
| compose the same way across different arithmetics) | ||
|
|
||
| **Next suggested:** `subjects/cs/databases/` (forthcoming | ||
| — where Zeta fits among database paradigms) |
There was a problem hiding this comment.
The prerequisite/next-suggested links point at subjects/zeta/zset-basics/, subjects/zeta/operator-composition/, and subjects/cs/databases/, but those modules/directories don't exist under docs/craft/subjects/ in this repo right now. Either add the missing modules, or mark these references as forthcoming and avoid presenting them as resolvable links until they land.
| - `subjects/zeta/zset-basics/` (ℤ-with-retraction is the | |
| signed-integer case; this module shows why it's just | |
| one of many) | |
| - `subjects/zeta/operator-composition/` (operators | |
| compose the same way across different arithmetics) | |
| **Next suggested:** `subjects/cs/databases/` (forthcoming | |
| — where Zeta fits among database paradigms) | |
| - Z-set basics *(forthcoming)* (ℤ-with-retraction is the | |
| signed-integer case; this module shows why it's just | |
| one of many) | |
| - Operator composition *(forthcoming)* (operators | |
| compose the same way across different arithmetics) | |
| **Next suggested:** Databases *(forthcoming)* (where | |
| Zeta fits among database paradigms) |
| F# signature (sketch — actual APIs are an active- | ||
| development surface): | ||
|
|
||
| ```fsharp | ||
| // Instead of hard-coding ℤ: | ||
| type ZSet<'K> = ... | ||
|
|
||
| // Parameterise over semiring S: | ||
| type SemiringSet<'K, 'S when 'S :> ISemiring> = ... | ||
|
|
||
| // Same operators, different arithmetic: | ||
| count : SemiringSet<'K, ℤ> -> int64 // retractable count | ||
| count : SemiringSet<'K, ℕ> -> uint64 // plain count | ||
| count : SemiringSet<'K, 𝔹> -> bool // is-any-present | ||
| count : SemiringSet<'K, Tropical> -> float // minimum cost |
There was a problem hiding this comment.
The F# signature block is presented as a sketch, but as written it won’t typecheck: it uses non-F# type identifiers (ℤ/ℕ/𝔹), references an ISemiring interface that doesn’t exist in src/, and suggests Tropical results as float while the current implementation uses TropicalWeight backed by int64 (src/Core/NovelMath.fs). Consider making this explicitly pseudocode (no F#-looking types), or update it to use real types from the codebase (Weight, TropicalWeight, etc.) so readers don’t copy a non-compiling pattern.
| F# signature (sketch — actual APIs are an active- | |
| development surface): | |
| ```fsharp | |
| // Instead of hard-coding ℤ: | |
| type ZSet<'K> = ... | |
| // Parameterise over semiring S: | |
| type SemiringSet<'K, 'S when 'S :> ISemiring> = ... | |
| // Same operators, different arithmetic: | |
| count : SemiringSet<'K, ℤ> -> int64 // retractable count | |
| count : SemiringSet<'K, ℕ> -> uint64 // plain count | |
| count : SemiringSet<'K, 𝔹> -> bool // is-any-present | |
| count : SemiringSet<'K, Tropical> -> float // minimum cost | |
| Pseudocode sketch (illustrative only — not current F# | |
| API surface): | |
| ```text | |
| // Instead of hard-coding integer weights: | |
| ZSet<Key> = ... | |
| // Parameterise the collection by a chosen semiring: | |
| SemiringSet<Key, Semiring> = ... | |
| // Same operator shape, different arithmetic: | |
| count : SemiringSet<Key, Integers> -> int64 // retractable count | |
| count : SemiringSet<Key, Naturals> -> uint64 // plain count | |
| count : SemiringSet<Key, Booleans> -> bool // is-any-present | |
| count : SemiringSet<Key, TropicalWeight> -> TropicalWeight // minimum cost |
| | Semiring | R | + | × | 0 | 1 | Retraction? | | ||
| |---|---|---|---|---|---|---| | ||
| | Signed integers | ℤ | + | × | 0 | 1 | Yes (ring) | | ||
| | Counting | ℕ | + | × | 0 | 1 | No (no negatives) | | ||
| | Boolean | {T, F} | ∨ | ∧ | F | T | N/A (can't "retract") | | ||
| | Tropical | ℝ ∪ {+∞} | min | + | +∞ | 0 | No (min has no additive inverse) | | ||
| | Max-plus | ℝ ∪ {-∞} | max | + | -∞ | 0 | No | |
There was a problem hiding this comment.
The Tropical row states R = ℝ ∪ {+∞}, but Zeta’s current tropical implementation is explicitly (ℤ ∪ {∞}, min, +) with TropicalWeight.Value : int64 and Int64.MaxValue as +∞ (src/Core/NovelMath.fs:13-34). Since this module links to NovelMath.fs as the implementation, aligning the table with the code (or calling out that the table is the general definition vs Zeta’s discrete instantiation) would avoid confusion.
| | Semiring | R | + | × | 0 | 1 | Retraction? | | |
| |---|---|---|---|---|---|---| | |
| | Signed integers | ℤ | + | × | 0 | 1 | Yes (ring) | | |
| | Counting | ℕ | + | × | 0 | 1 | No (no negatives) | | |
| | Boolean | {T, F} | ∨ | ∧ | F | T | N/A (can't "retract") | | |
| | Tropical | ℝ ∪ {+∞} | min | + | +∞ | 0 | No (min has no additive inverse) | | |
| | Max-plus | ℝ ∪ {-∞} | max | + | -∞ | 0 | No | | |
| These rows give the **canonical mathematical** | |
| definitions. Zeta's current `NovelMath.fs` tropical | |
| implementation is the discrete instantiation | |
| `(ℤ ∪ {∞}, min, +)` backed by `int64`, not the full | |
| real-valued tropical semiring. | |
| | Semiring | R | + | × | 0 | 1 | Retraction? | | |
| |---|---|---|---|---|---|---| | |
| | Signed integers | ℤ | + | × | 0 | 1 | Yes (ring) | | |
| | Counting | ℕ | + | × | 0 | 1 | No (no negatives) | | |
| | Boolean | {T, F} | ∨ | ∧ | F | T | N/A (can't "retract") | | |
| | Tropical (general) | ℝ ∪ {+∞} | min | + | +∞ | 0 | No (min has no additive inverse) | | |
| | Max-plus (general) | ℝ ∪ {-∞} | max | + | -∞ | 0 | No | |
| - `subjects/zeta/operator-composition/` — same operators | ||
| compose across different semirings | ||
| - `docs/TECH-RADAR.md` — Tropical semiring Adopt (ring | ||
| 11); residuated lattices Adopt; provenance deferred |
There was a problem hiding this comment.
This docs/TECH-RADAR.md reference claims “provenance deferred”, but docs/TECH-RADAR.md currently has rows for Tropical semiring and Residuated lattices and no provenance entry. Either add a provenance row to TECH-RADAR (so this bullet is grounded), or drop/soften the provenance claim here to match the radar source of truth.
| 11); residuated lattices Adopt; provenance deferred | |
| 11); residuated lattices Adopt |
| | Semiring | "Combine" means | "Multiply" means | What it computes | | ||
| |---|---|---|---| | ||
| | **ℤ (signed integers)** — Zeta default | Add (with negatives for retraction) | Multiply | Retractable counts | | ||
| | **ℕ (counting)** | Add (no negatives) | Multiply | Plain multisets; no retraction | | ||
| | **𝔹 (Boolean)** | OR (either-or) | AND (both-and) | Plain sets; presence/absence only | | ||
| | **Tropical (min-plus)** | Take minimum | Add | Shortest paths between nodes | | ||
| | **Max-plus** | Take maximum | Add | Longest / critical-path times | | ||
| | **Probabilistic ([0,1] fuzzy)** | Take maximum | Multiply | Possibility distributions | | ||
| | **Provenance** | Join witnesses | Combine witnesses | Which source contributed | | ||
|
|
There was a problem hiding this comment.
The semiring comparison table rows start with ||, which creates an empty first column in Markdown tables. If the intent is a 4-column table, switch the leading || to a single | on the header/separator/rows so the table renders correctly.
Summary\n\nFourth Craft module. Recipe-template anchor: combine means different things in different arithmetics.\n\nApplied: semirings table (ℤ/ℕ/𝔹/Tropical/Max-plus/Fuzzy) + real-world examples + F# signature sketch + self-check gate.\n\nTheoretical: formal semiring def + ring-vs-semiring for retraction + canonical semirings table + K-relations (GKT 2007) + Zeta regime-change framing.\n\nBidirectional-alignment audit passes. Preemptive MD032 clean.\n\nOtto (loop-agent PM hat).