Eine ontologische Re-Interpretation offener Quantensysteme?!

antaris

Registriertes Mitglied
Das verstehe ich nicht. Wenn du mit Matrizen arbeitest, dann ist nur relevant, dass die Indexmenge eine Bijektion auf die natürlichen Zählen erlaubt. Da Omega endlich ist, ist das trivialerweise der Fall. Also kann man (zumindest des hier) Omega einfach weglassen.
Du betrachtest das alles rein aus der abstrakten mathematischen Sicht? Das trivialisieren von Omega im Beweis als beliebige endliche und nicht-leere Indexmenge der Matrix ist doch dann aber der Grund dafür, dass Omega einfach weggelassen werden kann.
 

ralfkannenberg

Registriertes Mitglied
Das steht da auch ganz unten im Beitrag und die beiden Beweise wurden von claude.ai erstellt.
Hallo Antaris,

unten steht:
Allgemein gilt: Ist n keine Quadratzahl, so ist √n irrational.
Das ist aber nicht Teil des Beweises, sondern eine vom Beweis unabhängige "Nebenbemerkung". Der Beweis selber muss aber ebenfalls feststellen, dass wenn n eine Quadratzahl ist, der Beweis nicht funktioniert, d.h. die Beweiskette an (mindestens) einer Stelle unterbrochen ist.

Wie gesagt, ich muss das noch prüfen, möglicherweise enthält Dein Beweis diese Information, aber ich sehe sie momentan (noch) nicht.


Freundliche Grüsse, Ralf
 

antaris

Registriertes Mitglied
Hallo Ralf,
Wie gesagt, ich muss das noch prüfen, möglicherweise enthält Dein Beweis diese Information, aber ich sehe sie momentan (noch) nicht.
du meinst die beiden möglichen Primfaktoren 2 und 3?
Der Trick besteht darin, dass man sich nur einen der Primfaktoren von 6 herausgreift (hier die 2) und das gewohnte Argument durchzieht. Man hätte genauso gut mit dem Faktor 3 arbeiten können — das Ergebnis wäre dasselbe. Allgemein gilt: Ist n keine Quadratzahl, so ist √n irrational.
 

ralfkannenberg

Registriertes Mitglied
Behauptung: √6 ist irrational.

Beweis: Angenommen, √6 wäre rational. Dann existieren teilerfremde ganze Zahlen a und b (b ≠ 0, ggT(a,b) = 1) mit
√6 = a/b

Quadrieren ergibt:
a² = 6b² = 2 · 3 · b²

Schritt 1 — Teilbarkeit durch 2:
Da a² = 2·(3b²), ist a² gerade. Da 2 prim ist, folgt: a ist gerade, also a = 2k. Einsetzen:
(2k)² = 6b², also 4k² = 6b², also 2k² = 3b².

Schritt 2 — Teilbarkeit durch 2 bei b:
Aus 2k² = 3b² folgt, dass 3b² gerade ist. Da 3 ungerade ist, muss b² gerade sein, also ist auch b gerade.
Damit sind sowohl a als auch b durch 2 teilbar — ein Widerspruch zu ggT(a,b) = 1.

Fazit: √6 ist irrational.
Hallo Antaris,

also probieren wir es doch einmal mit der Quadratwurzel aus 4, d.h. ersetzen wir die "3" durch eine "2". Damit wir nicht blättern brauchen habe ich den Beweis zitiert.


Behauptung: √4 ist irrational.
Beweis: Angenommen, √4 wäre rational. Dann existieren teilerfremde ganze Zahlen a und b (b ≠ 0, ggT(a,b) = 1) mit
4 = a/b

Quadrieren ergibt:
a² = 4b² = 2 · 2 · b²

Schritt 1 — Teilbarkeit durch 2:
Da a² = 2·(2b²), ist a² gerade. Da 2 prim ist, folgt: a ist gerade, also a = 2k. Einsetzen:
(2k)² = 4b², also 4k² = 4b², also 2k² = 2b².

Schritt 2 — Teilbarkeit durch 2 bei b:
Aus 2k² = 2b² folgt, dass 2b² gerade ist. Da 2 ungerade ist, muss b² gerade sein, also ist auch b gerade.
Damit sind sowohl a als auch b durch 2 teilbar — ein Widerspruch zu ggT(a,b) = 1.

Fazit: √6 ist irrational.


Die Beweiskette ist also im fettgedruckten Schritt unterbrochen, d.h. dieser Beweis kann nicht auf die Quadratwurzel von 4 angewendet werden.

Vorsicht an dieser Stelle: dass die Beweiskette unterbrochen ist heisst nicht, dass sie falsch ist, man kann zunächst einmal nur sagen, dass der Beweis für die Irrationalität der Quadratwurzel 4 so nicht funktioniert. Aber nun haben wir ja noch das Gegenbeispiel, nämlich 2*2=4, also Quadratwurzel aus 4 = 2, und 2 = 2/1 ist eine rationale Zahl.

Insbesondere stelle ich nun fest, dass der von Dir genannte Beweis zur Irrationalität der Quadratwurzel aus 6 korrekt ist.


Herzlichen Dank für das Teilen dieses schönen - und ich denke auch eleganten - Beweises.


Freundliche Grüsse, Ralf
 

TomS

Registriertes Mitglied
Wenn (0.3) stimmt, dann ist H eine Matrix über R, nicht über C.

(1.2) kann ebenfalls nur richtig sein, wenn H reell ist, dann ist aber der ganze Abschnitt überflüssig. Ist H nicht reell, dann ist auch (1.2) falsch. Außerdem sind da zu viele Symbole wie *, T und der Querstrich an den Matrizen; was bedeuten die?

Da ich nicht weiß, was * bedeutet, muss ich raten, aber das Ende von (1.3) mit (itH)* = itH* sieht irgendwie falsch aus.

Was zu wann zeigen willst, ist mir immer noch nicht klar.
 
Zuletzt bearbeitet:

TomS

Registriertes Mitglied
Weißt du, dass irritiert mich.

Die einfachste zugrunde gelegte Struktur ist der unendliche Tree-of-Cliques als Dirichlet-/Widerstandsnetzwerk mit den beiden freien Parametern ⁡L_max und b. Daraus emergieren ohne weitere ontische Zusatzannahmen zunächst ... daraus die helle AQFT-artige Observable-Struktur mit Zuständen, GNS und KMS/modularer Schicht (Pillar B ...

In Pillar A wird insbesondere für PIllar B folgendes abgeleitet:
  • Ω (die endliche Menge der „Orte“ bzw. effektiven Freiheitsgrade, die nach der A-seitigen Reduktion im aktuellen B-Pfad übrig bleiben)
  • L (Randmatrix)
  • β (inverse Temperatur -> parametrisiert den Gibbs-/KMS-Zustand)
Das hört sich so an, als ob alles schon fertig ist und insbesondere ohne Zusatzannahmen Beweise etc. automatisch folgt.

Nun bastelst du ...
... ich habe zu oft an der tex herumgeschraubt. Ich überprüfe das nochmal alles ...
... an einem Thema herum, das man in der Mathematik seit über hundert Jahren kennt (Hermite, Lie, Schur ...), das danach auf unendliche Räume (Banach, Hilbert), insbs. auch in der Physik (von Neumann ...) angewandt wurde, und das jeder Physikstudent im Rahmen des Bachelor-Studiums kennenlernt. Intellektuell bewegen wir uns bei den zwei Seiten, die wir gerade diskutieren, auf der Ebene von Bruchrechnen (das sieht man nicht sofort, weil du alles viel komplizierter darstellst als notwendig).

Ω ist bijektiv zu einer Indexmenge I = [1, 2, ..., n] als Untermenge von N. Dann haben wir für jedes Indexpaar (i,j) eine reelle oder komplexe Zahl h_ij. Bauen wir daraus eine hermitesche Matrix H, so sind für alle z aus C die Matrizen S(z) = exp(zH) definiert und invertierter; jedes Element s_ij(z) ist eine holomorphe Funktion (Lie). Für reelles t sind die Matrizen U(t) = exp(iHt) unitär. Das entspricht im Kern den ersten Seiten.

Mich interessiert also nicht der Inhalt, sondern mich interessiert, wie du bzw. deine Maschinerie diesen Inhalt generieren (definieren, konstruieren, beweisen ...). Das zerbröselt uns bzw. dir aber unter den Fingern. Entweder generiert der Code alles vollautomatisch und konsistent, dann verstehe ich dein Übersetzungsproblem nicht; oder er generiert das nicht vollautomatisch oder nicht konsistent, d.h. du musst manuell nacharbeiten, dann sehe ich keinen Sinn dahinter.

Nach meinem Dafürhalten ist der Kaiser nackt.
 

antaris

Registriertes Mitglied
Mich interessiert also nicht der Inhalt, sondern mich interessiert, wie du bzw. deine Maschinerie diesen Inhalt generieren (definieren, konstruieren, beweisen ...). Das zerbröselt uns bzw. dir aber unter den Fingern. Entweder generiert der Code alles vollautomatisch und konsistent, dann verstehe ich dein Übersetzungsproblem nicht; oder er generiert das nicht vollautomatisch oder nicht konsistent, d.h. du musst manuell nacharbeiten, dann sehe ich keinen Sinn dahinter.
Der code ist vollständig und läuft fehlerfrei durch. Aber lean generiert daraus ja keine Prosa oder formale Schrift. Da die Funktionsweise von lean eine andere ist, wie bei etablierten formalen Texten, muss halt übersetzt werden.

Die Problematik liegt 1. darin, wie man überhaupt mittels AI zum fehlerfreien code kommt und 2. wie man dann den code in eine formale Form übersetzt. Weder das eine, noch das andere kann die AI ohne irgendwelche Leitplanken wirklich gut, denn die ratet ja nur. Eine lean-AI gibt es (noch) nicht.

Um überhaupt ein Ziel zu haben, wurde mit der AI immer ein relativ grober Implementierungsplan erstellt, wie z.B. das hinzufügen neuer Strukturen KMS/Gibbs/...

Was sehr gut funktioniert ist der Weg vom Implementierungsplan zum code, da lean sofort Fehler und Warnungen ausgibt und die harte Leitplanke stellt. Wenn etwas nicht passt, dann enthalten die Fehler und Warnungen Hinweise um diese zu beseitigen. Ich habe also den code stückweise (in Schichten des Implementierungsplans) iterierend generieren lassen, bis lean nicht mehr meckert und dann auf der sauberen codebasis wieder neue Schichten hinzugefügt, iterieren bis frei von Fehler und Warnungen, nächste Schicht, usw.


Der Weg zurück vom code auf eine formale Schrift ist der schwierigere Teil, da die harte Leitplanke fehlt. Ich kann nur auch wieder die AI über den funktionierenden code iterieren lassen, bis die AI glaubt/meint (es gibt keine Garantie), dass der code nun vollständig in formale Schrift übersetzt ist . Darum hatte ich ja auch schon irgendwo mal hier im Thread geschrieben, dass der eigentliche Formalismus der lean-code ist und jede Übersetzung in formale Schrift oder interpretative Bilder eine mögliche Verzerrung des codes ist.

Das übersetzen vom code in die formale Schrift ist entsprechend schlecht, aber nicht so schlecht, wie einen Formalismus durch die AI ohne lean-Leitplanke aufzusetzen.

Dazu kommt, dass es einen erheblichen Unterschied macht, ob die AI als "writer" oder als "reviewer" eingesetzt wird. Das schreiben von formaler Schrift oder des codes ist für die AI viel schweriger, als das lesen und vergleichen mit einem bestehenden code oder Literatur. Wobei das formulieren mittels code bzw. das lesen des codes für die AI viel einfacher ist, als mittels formaler Schrift. Die AI kann problemlos 500 Zeilen code schreiben aber für die gleiche Anzahl an Zeilen in formaler Schrift, braucht die AI eindeutig länger und das ist auch mehr mit Fehler behaftet.
Das übersetzen com code in formale Schrift ist dagegen aber zumindestens messbar. Ich habe das mit ChatGPT und Claude mehrmals getestet und claude ist dabei schneller und mit weniger Fehler unterwegs als ChatGPT, wenn ein und dieselbe Aufgabe gestellt wird (z.B. schreibe lean-Modul xy als formale Schrift -> die Ergebnisse der verschiedenen AI's sind dann direkt vergleichbar).

Mit dem Beweis habe ich gestern leider nur einmal die Änderung bezüglich der Definitionen einfließen lassen aber danach nicht mehr iterierend überprüfen lassen, ob danach noch alles kohärent zum code ist. Das habe ich schlicht vergessen.



Also was ich sicher sagen kann: Der code läuft fehlerfrei durch, was die Funktion des Formalismus erstmal rein mathematisch bestätigt (nicht aber ob das wirklich korrekt oder gar physikalisch relevant ist).
Das Problem ist nun aber, dass der code zwar als gesamtes Repo einfach bei der AI hochgeladen werden kann aber das Abfragen im Prompt nicht zwangsläufig präzise antworten liefert. Man muss halt wieder iterieren und/oder die zu untersuchenden lean-Objekte sehr klein zu halten. Letzteres führt dazu, dass weniger iteriert werden muss. Zuletzt habe ich das iterieren sogar auf 2 getrennte AI verlagert. ChatGPT hat den hier diskutierten Beweis formuliert und claude hat das gegen den code geprüft. ChatGPT musste dann die durch claude gefundenen Mängel beseitigen.

Ich habe für mich eine Möglichkeit gesucht, wie ich meine Worte/Gedanken/Ideen in einen harten Formalismus übersetzen kann, was ich mit lean eindeutig gefunden habe. Für mich reichte das erstmal vollkommen aus um weitermachen zu können aber ja, die Hoffnung "hier ist der code, überprüft ihn doch" war wohl etwas zu naiv. Das ist eigentlich gar nicht schlimm, da ich mich nun auch selber mit den Details beschäftigen muss und nicht nur mit der groben Richtung wohin die Reise gehen soll. Das fordert mich nun natürlich extrem, da einerseits der fehlerfreie code da ist aber andererseits diesen nur wenige Menschen wirklich lesen können.
 
Zuletzt bearbeitet:

antaris

Registriertes Mitglied
kannst du mal irgendeine einfachen Beweis raussuchen und den Code dafür posten?

Kann ich machen aber wäre es nicht vielleicht sinnvoll den hier diskutierten Gibbs/KMS Beweis zu nehmen? Dann könnte man die formale Schrift und den code nebeneinander legen.

Das Problem ist eher (auch bei kleine Beweise), dass nicht alles innerhalb eines Moduls codiert ist. Es wird ja z.B. auf mathlib zurückgegriffen. Um den lean code voll zu verstehen, müssten alle Abhängigkeiten eines Beweises voll aufgeklappt werden. Das kann schnell unübersichtlich werden.
Ich suche aber mal was raus, das keine oder zumindest nur wenige/überschaubare externe Abhängigkeiten hat. Am ehesten findet sich da was im postulierten ToC, da dieser ja gerade keine Abhängigkeiten voraussetzt.

Ich schaffe das aber erst heute Abend.
 

TomS

Registriertes Mitglied
Der Gibbs/KMS Beweis sollte aber erst mal repariert sein. Und wie zig-fach diskutiert, ich sehe nicht, was du da beweist; mir fehlt die Struktur Definition, Voraussetzung, Behauptung, Beweis, sowie die saubere Ausformulierung innerhalb jedes Abschnitts.

Ein Beweis ist wie ein Weg. Man weiß exakt, wo man ist; man das Ziel exakt beschrieben; und man kann den Weg exakt beschreiben.

Ich sitze hier in X an meinem Schreibtisch, Blick nach Westen in den Garten ... Ich treffe meine Frau heute Abend im Restaurant Y. Um dort hinzugelangen, drehe ich mich um 180°, gehe durch die Türe, dann 90° links, ... dann bin ich bei Y.

Ich komme mir aber ein bisschen vor wie K., du bist Klamm. Wenn du weißt, was mich meine ...
 

ralfkannenberg

Registriertes Mitglied
aber wäre es nicht vielleicht sinnvoll den hier diskutierten Gibbs/KMS Beweis zu nehmen? Dann könnte man die formale Schrift und den code nebeneinander legen.
Hallo Antaris,

debuggen sollte man wenn es geht mit einfachen Tests und nicht mit umfangreichen.

Das Problem ist eher (auch bei kleine Beweise), dass nicht alles innerhalb eines Moduls codiert ist. Es wird ja z.B. auf mathlib zurückgegriffen. Um den lean code voll zu verstehen, müssten alle Abhängigkeiten eines Beweises voll aufgeklappt werden. Das kann schnell unübersichtlich werden.
Dann nimm die für den Moment mal als "black box" und als korrekt an, das wurde ja auch schon von anderen Leuten "getestet", und konzentriere Dich auf einen einfachen Beweis, bei dem Du nichts aufzuklappen brauchst.

Also keep it simple, understandable and maintainable.


Freundliche Grüsse, Ralf
 

antaris

Registriertes Mitglied
Der Gibbs/KMS Beweis sollte aber erst mal repariert sein.
Ich habe die AI (claude), ohne deine Hinweise auf die vorhandenen Fehler, den Beweis gegen den code prüfen lassen und erstaunlicherweise wurden exakt diese Fehler gefunden.

Und wie zig-fach diskutiert, ich sehe nicht, was du da beweist; mir fehlt die Struktur Definition, Voraussetzung, Behauptung, Beweis, sowie die saubere Ausformulierung innerhalb jedes Abschnitts.
Na ja, wenn ich nun schreibe, dass die nicht-Trivialität im Tripel {Ω, L und β} steckt und genau aus diesem Tripel die Matrix für den Gibbs/KMS Beweis gebildet und bewiesen wird, dann ist das definitorisch m.E. am korrektesten aber trifft

Ein Beweis ist wie ein Weg. Man weiß exakt, wo man ist; man das Ziel exakt beschrieben; und man kann den Weg exakt beschreiben.
gerade nicht zu, da die präzise Repräsentation der 3 Größen nicht klar erkennbar ist. Ja man kann Ω beispielsweise als irgendeine endliche und nicht-leere Menge definieren, das ist für den Beweis nicht falsch aber dann eben trivial. Das ist eben genau was der Beweis zeigen soll -> gerade trotz der gegebenen nicht-Trivialität der drei Größen, funktioniert der Beweis aber so wie ich das nun verstanden habe wäre das ja immer noch irgendwie trivial, da die Gültigkeit des Beweises eben nicht von dessen exaten inneren Struktur, sondern nur von seiner Endlichkeit und nicht-Leere abhängt. Im Sinne des im code gegossenen Gedanken steckt in Ω die Physik der reduzierten DtN-Randmatrix, die aus der individuellen Wirkung der Umgebung auf den Approximanten innerhalb von Pillar A folgt. Im code ist das bisher aber nur bis zum UV-Cutoff der kleinsten Freiheitsgrade des Approximanten implementiert. Wird das trivialisiert, so verliert der Beweis jeden Aussagekraft bzw. insgesamt den Sinn, da er eben selbst trivial bzw. "am trivialsten" wird.
Ich sitze hier in X an meinem Schreibtisch, Blick nach Westen in den Garten ... Ich treffe meine Frau heute Abend im Restaurant Y. Um dort hinzugelangen, drehe ich mich um 180°, gehe durch die Türe, dann 90° links, ... dann bin ich bei Y.
Ja aber du kennst die Geschichte -> die Ableitung von X, Y, Türen, 90°, links, rechts, Garten, ... und auch ich kann mir daran ein ganz gutes Bild machen und mir das vorstellen. Frag doch aber mal einen Indigenen im Amazonas, der nie Kontakt mit der Außenwelt hatte, was ein Schreibtisch ist. Um ihm das gleiche Bild wie mir zu vermitteln, müsstest du fast jedes Wort in dem Satz von Anfang an (was ist ein Schreibtisch, wozu dient er, was ist Papier und weiß ich nicht wieviel Folgefragen beantworten oder soagr ausführlich erklären.

Das soll nicht bedeuten, dass ich dir die Einzelheiten irgendwie erklären müsste, sondern dass wir am Anfang der Theorie starten sollten und nicht mittendrin.
Der Anfang der hier diskutierten Theorie ist, gegen den gemeinsamen Anfang von Schreibtische, Restaurant, ..., stark eingegrenzt, denn es ist das einzige Postulat -> der ToC bzw. dessen Konstruktion und das ist eben genau am bzw. der Anfang. Wenn wir dort starten, dann sind wir beide Indigene im Amazonas, starten mit dem gleichen Ausgangspunkt und können uns dann bis zu den Schreibtischen durcharbeiten. Ich glaube es wäre tatsächlich auch besser am Anfang zu starten, denn egal was Ω, L und β irgendwann mitten in der Ableitung repräsentiert, wenn die Theorie davor schon einen defekt hat, dann ist jede Diskussion um Gibbs/KMS Zeitverschwendung. Was wir aber eben jetzt auch schon wissen ist doch auch schon ein Ergebnis, denn unabhängig der exakten Form von Ω fällt bei dessen Trivialisierung der Beweis auf den Standardsatz zurück. Der Ausgangspunkt des einzelnen Beweises ist also erstmal nicht verkehrt oder sehe ich das falsch?
 
Zuletzt bearbeitet:

ralfkannenberg

Registriertes Mitglied
https://huggingface.co/spaces/Sierpinksi-Project/ISIN


ISINproof.lean
lean/mathlib 4.24.0 proved
Code:
import Mathlib.Data.List.Basic
import Mathlib.Data.Nat.Basic
import Mathlib.Tactic

/-!
A small, self-contained formalization of the arithmetic core of the ISIN/Luhn
check-digit rule.

Scope of the proof:
* We work on the already-expanded decimal digit payload.
* The theorem proves that the computed check digit always verifies.

This means: if the ISIN body has already been converted into a list of decimal
Digits (where letters A..Z have been expanded to 10..35 and then split into
individual decimal digits), then `computeCheckDigit` is correct w.r.t. `verify`.

The string/character parsing layer can be added on top later; the mathematically
relevant check-digit core is proved here.
-/

namespace ISIN

/-- Luhn doubling step on a single decimal digit. -/
def dblAdjust (d : Nat) : Nat :=
  let m := 2 * d
  if m < 10 then m else m - 9

/-- Alternating sum from left to right, with `b = true` meaning:
    the current digit is processed by `dblAdjust`. -/
def altSum : Bool → List Nat → Nat
  | _, [] => 0
  | b, x :: xs => (if b then dblAdjust x else x) + altSum (!b) xs

/-- Starting flag for a payload of length `n` so that, after appending the
    future check digit on the right, that check digit is *not* doubled and the
    payload digits have exactly the correct Luhn parity. -/
def payloadStart (xs : List Nat) : Bool :=
  xs.length % 2 = 1

/-- Luhn sum of the payload (already using the parity appropriate for a later
    appended check digit). -/
def payloadSum (xs : List Nat) : Nat :=
  altSum (payloadStart xs) xs

/-- The computed check digit. -/
def computeCheckDigit (xs : List Nat) : Nat :=
  (10 - payloadSum xs % 10) % 10

/-- Verification predicate: append the candidate check digit and test whether
    the total Luhn sum is divisible by 10. -/
def verify (xs : List Nat) (c : Nat) : Bool :=
  decide ((altSum (payloadStart xs) (xs ++ [c])) % 10 = 0)

/-- Flag after toggling `n` times. -/
def afterFlag : Bool → Nat → Bool
  | b, 0 => b
  | b, n + 1 => afterFlag (!b) n

lemma afterFlag_eq_parity (b : Bool) : ∀ n : Nat,
    afterFlag b n = if n % 2 = 0 then b else !b := by
  intro n
  induction n generalizing b with
  | zero =>
      simp [afterFlag]
  | succ n ih =>
      by_cases h : n % 2 = 0
      · have h' : (n + 1) % 2 = 1 := by omega
        simp [afterFlag, ih, h, h']
      · have h1 : n % 2 = 1 := by omega
        have h' : (n + 1) % 2 = 0 := by omega
        simp [afterFlag, ih, h1, h']

lemma altSum_append_singleton (b : Bool) (xs : List Nat) (x : Nat) :
    altSum b (xs ++ [x]) =
      altSum b xs + (if afterFlag b xs.length then dblAdjust x else x) := by
  induction xs generalizing b with
  | nil =>
      simp [altSum, afterFlag]
  | cons y ys ih =>
      simp [altSum, ih, afterFlag, Nat.add_assoc, Nat.add_left_comm, Nat.add_comm]

lemma after_payloadStart_false_len (n : Nat) :
    afterFlag (n % 2 = 1) n = false := by
  rw [afterFlag_eq_parity]
  by_cases h : n % 2 = 0
  · simp [h]
  · have h1 : n % 2 = 1 := by omega
    simp [h1]

lemma after_payloadStart_false (xs : List Nat) :
    afterFlag (payloadStart xs) xs.length = false := by
  unfold payloadStart
  exact after_payloadStart_false_len xs.length

lemma fullSum_eq_payload_plus_check (xs : List Nat) (c : Nat) :
    altSum (payloadStart xs) (xs ++ [c]) = payloadSum xs + c := by
  unfold payloadSum
  rw [altSum_append_singleton]
  simp [after_payloadStart_false]

lemma mod_add_checkDigit (s : Nat) :
    (s + ((10 - s % 10) % 10)) % 10 = 0 := by
  let r := s % 10
  have hr : s % 10 = r := rfl
  have hr_lt : r < 10 := by
    dsimp [r]
    exact Nat.mod_lt _ (by decide)
  rw [Nat.add_mod, hr, Nat.mod_mod]
  by_cases h0 : r = 0
  · simp [h0]
  · have hr_pos : 0 < r := Nat.pos_of_ne_zero h0
    have hsub_lt : 10 - r < 10 := by omega
    rw [Nat.mod_eq_of_lt hsub_lt]
    have hsum : r + (10 - r) = 10 := by omega
    rw [hsum]

theorem fullSum_compute_mod (xs : List Nat) :
    (altSum (payloadStart xs) (xs ++ [computeCheckDigit xs])) % 10 = 0 := by
  rw [fullSum_eq_payload_plus_check, computeCheckDigit]
  exact mod_add_checkDigit (payloadSum xs)

theorem verify_compute_eq_true (xs : List Nat) :
    verify xs (computeCheckDigit xs) = true := by
  unfold verify
  simp [fullSum_compute_mod]

/-!
Regression checks on a well-known example.
US0378331005 (Apple) has body US037833100.
Expanded decimal payload: [3,0,2,8,0,3,7,8,3,3,1,0,0].
-/

example : computeCheckDigit [3, 0, 2, 8, 0, 3, 7, 8, 3, 3, 1, 0, 0] = 5 := by
  decide

example : verify [3, 0, 2, 8, 0, 3, 7, 8, 3, 3, 1, 0, 0] 5 = true := by
  decide

end ISIN


Insgesamt 8 Minuten und 33 Sekunden ChatGPT5.2plus Denkzeit.
Hallo Antaris,

ich habe das vor gut 2 Wochen abschliessen können; das Programm ist ein Dreizeiler.


Freundliche Grüsse, Ralf
 

antaris

Registriertes Mitglied

antaris

Registriertes Mitglied
kannst du mal irgendeine einfachen Beweis raussuchen und den Code dafür posten?
Ein einfacher Beweis in lean wäre z.B. der Hermitizitätsbeweis.

Satz: Ist L eine reelle symmetrische Matrix, so ist ihre Komplexifizierung H hermitesch (d.h. H* = H).
Lean-Code (Datei: BoundaryMatrixFullExp.lean):

-- Definitionen:
-- fullHamiltonian L := fun i j => (L i j : ℂ) -- Komplexifizierung
-- Matrix.IsHermitian H := conjTranspose H = H -- aus Mathlib

theorem fullHamiltonian_isHermitian_of_transpose_eq
(L : Matrix Ω Ω ℝ) (hL : Matrix.transpose L = L) :
Matrix.IsHermitian (fullHamiltonian L) := by
classical
dsimp [Matrix.IsHermitian, fullHamiltonian]
ext i j
have hij : L j i = L i j := by
have h := congrArg (fun M => M i j) hL
simpa [Matrix.transpose_apply] using h
simp [Matrix.conjTranspose_apply, hij]


Was passiert
  • ext i j — es wird komponentenweise gezeigt, also für jedes (i,j)-Paar
  • hij — aus L^T = L wird L(j,i) = L(i,j) extrahiert
  • simp [conjTranspose_apply, hij] — Lean vereinfacht: conj(H(j,i)) = conj(L(j,i)) = L(j,i) = L(i,j) = H(i,j), wobei conj auf reellen Skalaren die Identität ist
 

TomS

Registriertes Mitglied
Ein einfacher Beweis in lean wäre z.B. der Hermitizitätsbeweis.

Satz: Ist L eine reelle symmetrische Matrix, so ist ihre Komplexifizierung H hermitesch (d.h. H* = H).
Das ist falsch.

Eine Komplexifizierung ausgehend von GL(R) liefert lediglich GL(C); das liefert keine Hermitizität, die musst du zusätzlich fordern.
 
Oben