← Session 33 — ii′-3b/3c crux + F-D finding; Lagarias letter package
thinking (6030 chars)
All three PASS — `rcases h with h1` on `s.re = 5+2`, `s.re = ((5:ℝ):ℂ).re`, `s.re = 5` all fine. So rcases does NOT cases these Eqs (it substitutes? or keeps them?). Then why does the border case fail?
The failing equation: `Real.add✝ (↑(2 * √↑n)).re (↑T * I).re = s.1` — note `s.1`!! In my passing tests the Eq is `s.re = ...` — but the failing one is `... = s.1`. s.1 vs s.re — for ℂ, s.1 = s.re via structure eta?? Hmm — `s.1` where s : ℂ — ℂ = { re, im : ℝ } — structure with two fields: s.1 = s.re ✓ same thing. The failing Eq is oriented `... = s.1` — the singleton membership `s.re ∈ {w.re}` gives `s.re = w.re` — the displayed failing equation has w.re-ish on the LEFT and s.1 on the RIGHT. And `Real.add✝ (↑(2√n)).re (↑T·I).re` — hmm, this is re(↑(2√n)) + re(↑T·I)? or re(↑(2√n) + ↑T·I)? — if w.re = re(↑(2√n) + ↑T·I), then the Eq is s.re = (↑(2√n) + ↑T·I).re — and `cases` UNIFIES: s.re vs (↑(2√n) + ↑T·I).re — but wait — maybe the cases isn't on the singleton Eq but on the ×ℂ PAIR — destructuring `s` itself?? "Failed to solve equation ... = s.1 at case Eq.refl" — s.1 suggests `s` was destructed into (s.1, s.2) — the ×ℂ membership `s ∈ A ×ℂ B` — reProdIm might be defined via equivRealProd: s ∈ A ×ℂ B ↔ (s.re, s.im) ∈ A ×ˢ B ↔ s.re ∈ A ∧ s.im ∈ B — and rcases destructures s into ⟨s.1, s.2⟩?? — if it destructures the complex number s itself into its re/im components, then the singleton Eq becomes (↑(2√n) + ↑T·I).re = s.1 — and cases on that Eq with s.1 a PROJECTION (not a variable)...
Hmm wait — actually if rcases destructured s into (s.1, s.2), then s.1 is a NEW VARIABLE (the re component)! Then the Eq (↑(2√n)+↑T·I).re = s.1 has a variable RHS — subst should work! Unless (↑(2√n)+↑T·I).re is not in normal form and the unification... "Failed to solve equation ... at case Eq.refl" — hmm, if s.1 is a variable, subst s.1 := (↑(2√n)+↑T·I).re works — no failure. So s.1 is NOT a fresh variable — it's s.re (projection, non-variable).
OK — I've spent enough on the mechanism. PRAGMATIC SOLUTION: avoid the union-rcases entirely. Handle the border via a chain of Set.mem_union.mp and take .1/.2 projections (which my isolated test showed works fine: `rcases hs with ⟨h1, h2⟩` on a single ×ℂ piece PASSED). The union decomposition via mem_union.mp as haves:
```lean
have hs4 := hs
rw [RectangleBorder, Set.mem_union, Set.mem_union, Set.mem_union] at hs4
rcases hs4 with hb | hb | hb | hb -- FAILS here
```
→ replace with nested mem_union.mp:
```lean
rw [RectangleBorder] at hs
have hb := hs
rcases Set.mem_union _ _ hb with hb | hb234
· -- bottom piece: hb : s ∈ [[z.re, w.re]] ×ℂ {z.im}
...
· rcases Set.mem_union _ _ hb234 with hb | hb34
...
```
But `rcases Set.mem_union _ _ hb with hb | hb234` — rcases on the Or — the pieces: does rcases recurse into the piece's singleton-Eq? The Or-elim gives hb : s ∈ piece — rcases' pattern `hb | hb234` is flat — does rcases then ALSO destructure hb (the ×ℂ + singleton) automatically? From the isolated right-piece test (`rcases hs with ⟨h1, h2⟩` passed), destructuring a piece with an explicit ⟨h1, h2⟩ pattern works. The question is whether a flat `hb` pattern on the Or leaves hb untouched. I believe YES — rcases only destructures what the pattern asks. The failing border rcases had pattern `hb | hb | hb | hb` — flat names! Yet it failed... because rcases on the UNION sees the pieces as setOf memberships and destructures the And/Eq STRUCTURE automatically??
Hmm — no wait. Let me re-examine: maybe the failure is because the union's pieces are setOf-comprehensions whose membership is conjunctive+Eq, and rcases — when eliminating `s ∈ A ∪ B` (which is `s ∈ A ∨ s ∈ B` — an Or) — produces hb : s ∈ piece — and since the pattern `hb` just names it, rcases STOPS. The recursion into And/Eq happens only with ⟨·⟩ patterns. So `rcases hs with hb | hb | hb | hb` should be fine... but it FAILED at the rcases line in BOTH tests (with and without the rw).
Unless — AH. I bet the issue: `RectangleBorder` is a `def`, and `rcases` whnf-unfolds it to the union — and the union's pieces involve `×ℂ` — and here's the thing: `×ℂ` is notation for `Set.reProdIm`?? — and `s ∈ A ×ℂ B` — reProdIm might be defined as `equivRealProd ⁻¹' (A ×ˢ B)` or via `{z | z.re ∈ A ∧ z.im ∈ t}` — if it's the PREIMAGE form, then s ∈ A ×ℂ B ↔ (s.re, s.im) ∈ A ×ˢ B — a Set.prod membership — and rcases destructures Set.prod membership via Set.mem_prod : (a, b) ∈ s ×ˢ t ↔ a ∈ s ∧ b ∈ t — and HERE's the catch: Set.prod membership for a PAIR (s.re, s.im): rcases might destructure (s.re, s.im) as a pair — and then Set.mem_prod gives s.re ∈ A ∧ s.im ∈ B — and then the singleton: s.re ∈ {w.re} — Eq — cases: w.re = re(↑(2√n) + ↑T·I) — the Eq `(↑(2√n) + ↑T·I).re = s.re` — displayed as `Real.add✝ (↑(2√n)).re (↑T·I).re = s.1` — wait, with Real.add: so re(↑(2√n)) + re(↑T·I)?? — the elaborator DID apply add_re (defeq) during whnf. So the Eq is `re(↑(2√n)) + re(↑T·I) = s.re`?? hmm — still the same Eq-cases problem: `Real.add (re 2√n) (re (T·I)) = s.1` — with s.1 = s.re — hmm — cases on Eq: unify re(2√n) + re(T·I) with s.re: not defeq → fail.
BUT — in my PASSING isolated test of the right piece (rcases hs with ⟨h1, h2⟩ on {w.re} ×ℂ uIcc), the same Eq appeared (s.re = w.re) and it PASSED. So the difference: ⟨h1, h2⟩ pattern vs flat hb pattern. With ⟨h1, h2⟩, rcases destructures the And but NOT the Eq (h1 : s.re ∈ {w.re} kept as membership? or destructured to the Eq but NOT cases'd?). With flat hb on the union... rcases destructures MORE?
Hmm — actually maybe the answer is simpler: `rcases hs with hb | hb | hb | hb` — this pattern is interpreted as ⟨hb | hb | hb | hb⟩ — four-way Or — and rcases fully destructures each case: piece → And → ⟨h1, h2⟩ automatically?? No — rcases doesn't destructure without patterns...
FORGET the mechanism. Empirical path: the isolated test `rcases hs with ⟨h1, h2⟩` on a single ×ℂ piece WORKED. So: decompose the union via mem_union.mp chains, then ⟨h1, h2⟩ per piece. Let me test that pattern for the full border.
The union-rcases sees through to the Eq and cases it. Testing the mem_union.mp + shallow-pattern alternative.
tool: Bash
input
{
"command": "cd D:/Python/Quantum/research/lean/NguyenRH1 && cat > Scratch.lean << 'EOF'\nimport Mathlib\nimport NguyenRH1.LiSides\nopen Zeta23 Complex Filter Topology\nnoncomputable section\nnamespace NguyenRH1\nexample {n : \u2115} {T : \u211d} (s : \u2102)\n (hs : s \u2208 RectangleBorder (((-5/2 : \u211d) : \u2102) - (T : \u211d) * Complex.I)\n (((2 * Real.sqrt n : \u211d) : \u2102) + (T : \u211d) * Complex.I)) : True := by\n rw [RectangleBorder, Set.mem_union, Set.mem_union, Set.mem_union] at hs\n rcases hs with hb | hb | hb | hb\n \u00b7 have h2 := hb.2\n trivial\n \u00b7 have h1 := hb.1\n trivial\n \u00b7 have h2 := hb.2\n trivial\n \u00b7 have h1 := hb.1\n trivial\nend NguyenRH1\nEOF\nexport PATH=\"$HOME/.elan/bin:$PATH\" && lake env lean Scratch.lean 2>&1 | head -12",
"description": "Test border via mem_union rewrites + projections",
"timeout": 300000
}
raw content_json (database row)
[{"type":"thinking","thinking":"All three PASS — `rcases h with h1` on `s.re = 5+2`, `s.re = ((5:ℝ):ℂ).re`, `s.re = 5` all fine. So rcases does NOT cases these Eqs (it substitutes? or keeps them?). Then why does the border case fail?\n\nThe failing equation: `Real.add✝ (↑(2 * √↑n)).re (↑T * I).re = s.1` — note `s.1`!! In my passing tests the Eq is `s.re = ...` — but the failing one is `... = s.1`. s.1 vs s.re — for ℂ, s.1 = s.re via structure eta?? Hmm — `s.1` where s : ℂ — ℂ = { re, im : ℝ } — structure with two fields: s.1 = s.re ✓ same thing. The failing Eq is oriented `... = s.1` — the singleton membership `s.re ∈ {w.re}` gives `s.re = w.re` — the displayed failing equation has w.re-ish on the LEFT and s.1 on the RIGHT. And `Real.add✝ (↑(2√n)).re (↑T·I).re` — hmm, this is re(↑(2√n)) + re(↑T·I)? or re(↑(2√n) + ↑T·I)? — if w.re = re(↑(2√n) + ↑T·I), then the Eq is s.re = (↑(2√n) + ↑T·I).re — and `cases` UNIFIES: s.re vs (↑(2√n) + ↑T·I).re — but wait — maybe the cases isn't on the singleton Eq but on the ×ℂ PAIR — destructuring `s` itself?? \"Failed to solve equation ... = s.1 at case Eq.refl\" — s.1 suggests `s` was destructed into (s.1, s.2) — the ×ℂ membership `s ∈ A ×ℂ B` — reProdIm might be defined via equivRealProd: s ∈ A ×ℂ B ↔ (s.re, s.im) ∈ A ×ˢ B ↔ s.re ∈ A ∧ s.im ∈ B — and rcases destructures s into ⟨s.1, s.2⟩?? — if it destructures the complex number s itself into its re/im components, then the singleton Eq becomes (↑(2√n) + ↑T·I).re = s.1 — and cases on that Eq with s.1 a PROJECTION (not a variable)... \n\nHmm wait — actually if rcases destructured s into (s.1, s.2), then s.1 is a NEW VARIABLE (the re component)! Then the Eq (↑(2√n)+↑T·I).re = s.1 has a variable RHS — subst should work! Unless (↑(2√n)+↑T·I).re is not in normal form and the unification... \"Failed to solve equation ... at case Eq.refl\" — hmm, if s.1 is a variable, subst s.1 := (↑(2√n)+↑T·I).re works — no failure. So s.1 is NOT a fresh variable — it's s.re (projection, non-variable).\n\nOK — I've spent enough on the mechanism. PRAGMATIC SOLUTION: avoid the union-rcases entirely. Handle the border via a chain of Set.mem_union.mp and take .1/.2 projections (which my isolated test showed works fine: `rcases hs with ⟨h1, h2⟩` on a single ×ℂ piece PASSED). The union decomposition via mem_union.mp as haves:\n\n```lean\n have hs4 := hs\n rw [RectangleBorder, Set.mem_union, Set.mem_union, Set.mem_union] at hs4\n rcases hs4 with hb | hb | hb | hb -- FAILS here\n```\n→ replace with nested mem_union.mp:\n```lean\n rw [RectangleBorder] at hs\n have hb := hs\n rcases Set.mem_union _ _ hb with hb | hb234\n · -- bottom piece: hb : s ∈ [[z.re, w.re]] ×ℂ {z.im}\n ...\n · rcases Set.mem_union _ _ hb234 with hb | hb34\n ...\n```\nBut `rcases Set.mem_union _ _ hb with hb | hb234` — rcases on the Or — the pieces: does rcases recurse into the piece's singleton-Eq? The Or-elim gives hb : s ∈ piece — rcases' pattern `hb | hb234` is flat — does rcases then ALSO destructure hb (the ×ℂ + singleton) automatically? From the isolated right-piece test (`rcases hs with ⟨h1, h2⟩` passed), destructuring a piece with an explicit ⟨h1, h2⟩ pattern works. The question is whether a flat `hb` pattern on the Or leaves hb untouched. I believe YES — rcases only destructures what the pattern asks. The failing border rcases had pattern `hb | hb | hb | hb` — flat names! Yet it failed... because rcases on the UNION sees the pieces as setOf memberships and destructures the And/Eq STRUCTURE automatically?? \n\nHmm — no wait. Let me re-examine: maybe the failure is because the union's pieces are setOf-comprehensions whose membership is conjunctive+Eq, and rcases — when eliminating `s ∈ A ∪ B` (which is `s ∈ A ∨ s ∈ B` — an Or) — produces hb : s ∈ piece — and since the pattern `hb` just names it, rcases STOPS. The recursion into And/Eq happens only with ⟨·⟩ patterns. So `rcases hs with hb | hb | hb | hb` should be fine... but it FAILED at the rcases line in BOTH tests (with and without the rw).\n\nUnless — AH. I bet the issue: `RectangleBorder` is a `def`, and `rcases` whnf-unfolds it to the union — and the union's pieces involve `×ℂ` — and here's the thing: `×ℂ` is notation for `Set.reProdIm`?? — and `s ∈ A ×ℂ B` — reProdIm might be defined as `equivRealProd ⁻¹' (A ×ˢ B)` or via `{z | z.re ∈ A ∧ z.im ∈ t}` — if it's the PREIMAGE form, then s ∈ A ×ℂ B ↔ (s.re, s.im) ∈ A ×ˢ B — a Set.prod membership — and rcases destructures Set.prod membership via Set.mem_prod : (a, b) ∈ s ×ˢ t ↔ a ∈ s ∧ b ∈ t — and HERE's the catch: Set.prod membership for a PAIR (s.re, s.im): rcases might destructure (s.re, s.im) as a pair — and then Set.mem_prod gives s.re ∈ A ∧ s.im ∈ B — and then the singleton: s.re ∈ {w.re} — Eq — cases: w.re = re(↑(2√n) + ↑T·I) — the Eq `(↑(2√n) + ↑T·I).re = s.re` — displayed as `Real.add✝ (↑(2√n)).re (↑T·I).re = s.1` — wait, with Real.add: so re(↑(2√n)) + re(↑T·I)?? — the elaborator DID apply add_re (defeq) during whnf. So the Eq is `re(↑(2√n)) + re(↑T·I) = s.re`?? hmm — still the same Eq-cases problem: `Real.add (re 2√n) (re (T·I)) = s.1` — with s.1 = s.re — hmm — cases on Eq: unify re(2√n) + re(T·I) with s.re: not defeq → fail.\n\nBUT — in my PASSING isolated test of the right piece (rcases hs with ⟨h1, h2⟩ on {w.re} ×ℂ uIcc), the same Eq appeared (s.re = w.re) and it PASSED. So the difference: ⟨h1, h2⟩ pattern vs flat hb pattern. With ⟨h1, h2⟩, rcases destructures the And but NOT the Eq (h1 : s.re ∈ {w.re} kept as membership? or destructured to the Eq but NOT cases'd?). With flat hb on the union... rcases destructures MORE?\n\nHmm — actually maybe the answer is simpler: `rcases hs with hb | hb | hb | hb` — this pattern is interpreted as ⟨hb | hb | hb | hb⟩ — four-way Or — and rcases fully destructures each case: piece → And → ⟨h1, h2⟩ automatically?? No — rcases doesn't destructure without patterns...\n\nFORGET the mechanism. Empirical path: the isolated test `rcases hs with ⟨h1, h2⟩` on a single ×ℂ piece WORKED. So: decompose the union via mem_union.mp chains, then ⟨h1, h2⟩ per piece. Let me test that pattern for the full border.","signature":""},{"type":"text","text":"The union-rcases sees through to the Eq and cases it. Testing the mem_union.mp + shallow-pattern alternative."},{"type":"tool_use","id":"Bash_277","name":"Bash","input":{"command":"cd D:/Python/Quantum/research/lean/NguyenRH1 && cat > Scratch.lean << 'EOF'\nimport Mathlib\nimport NguyenRH1.LiSides\nopen Zeta23 Complex Filter Topology\nnoncomputable section\nnamespace NguyenRH1\nexample {n : ℕ} {T : ℝ} (s : ℂ)\n (hs : s ∈ RectangleBorder (((-5/2 : ℝ) : ℂ) - (T : ℝ) * Complex.I)\n (((2 * Real.sqrt n : ℝ) : ℂ) + (T : ℝ) * Complex.I)) : True := by\n rw [RectangleBorder, Set.mem_union, Set.mem_union, Set.mem_union] at hs\n rcases hs with hb | hb | hb | hb\n · have h2 := hb.2\n trivial\n · have h1 := hb.1\n trivial\n · have h2 := hb.2\n trivial\n · have h1 := hb.1\n trivial\nend NguyenRH1\nEOF\nexport PATH=\"$HOME/.elan/bin:$PATH\" && lake env lean Scratch.lean 2>&1 | head -12","description":"Test border via mem_union rewrites + projections","timeout":300000},"extra_content":null}]