Eine ontologische Re-Interpretation offener Quantensysteme?!

antaris

Registriertes Mitglied
Weil Lean nicht den kreativen sondern den pedantischen Teil übernimmt. Und weil der kreative Teil am besten mit einem kreativen Sparringspartner funktioniert.
Ja lean macht das aber excellent und die AI ist höchst schreibfreudig aber natürlich nicht wirklich kreativ, wobei ich das nicht nur schwarz oder weiß sehe. Die Details hat alle die AI -> ChatGPT ausgearbeitet. Das ist das eigentliche und vor allem unermüdliche und Weltbild-agnostische Arbeitstier. Das was tatsächlich fehlt ist vor allem Erfahrung und ja, gleichzeitig auch weitere kreative Köpfe.
Das ist ja nun schon ein "open Project" und es darf sich jeder eingeladen fühlen. Die Möglichkeiten des gesamten Ansatz gehen in meinem Kopf schon viel weiter. Aus meiner Sicht ist das alles nur der Anfang aber ich trage wohlmöglich eine rosarote Brille...klare und kompetente Köpfe sind für die vielen Fragestellungen gefragt.

… was ja der Ausgangspunkt der Diskussion war. Und da ist die Sprache – vermutlich bewusst – schlicht nicht ausdrucksstark genug. Evtl. kann man das mit dem Schritt von TeX zu LaTeX vergleiche, d.h. man könnte eine Macro-Ebene über Lean legen.

Das sähe z.B. so aus:

⟪f, L, f⟫ = ⟪x, L_II, x⟫
Ich habe mal nachgeforst. Das ist im Prinzip möglich.
Lean hat ein eigenes Makro-System. Man kann notation, macro und scoped notation fast exakt in deinem Sinne definieren.


Folgende Beispiele:
Code:
/-!
# Lean 4 Notation-Beispiel: Lesbare Makro-Ebene für REALOQS

Dieses Modul zeigt, wie man mit `notation` und `scoped notation`
eine lesbare Schicht über den bestehenden Code legen kann,
ohne die Funktionalität zu ändern.

Der Compiler sieht intern denselben Code wie vorher.
Ein menschlicher Leser sieht mathematische Symbole.
-/

import Mathlib

-- ═══════════════════════════════════════════════════
-- Schritt 1: Die bestehende Definition (wie sie jetzt im Repo steht)
-- ═══════════════════════════════════════════════════

variable {Ω : Type} [Fintype Ω] [DecidableEq Ω]

/-- Quadratische Form: ⟨f, Lf⟩ = Σᵢ Σⱼ f(i) · L(i,j) · f(j) -/
def quadForm (L : Matrix Ω Ω ℝ) (f : Ω → ℝ) : ℝ :=
  ∑ i : Ω, f i * (∑ j : Ω, L i j * f j)

/-- Bilinearform: ⟨f, Lg⟩ = Σᵢ Σⱼ f(i) · L(i,j) · g(j) -/
def bilinForm (L : Matrix Ω Ω ℝ) (f g : Ω → ℝ) : ℝ :=
  ∑ i : Ω, f i * (∑ j : Ω, L i j * g j)

-- ═══════════════════════════════════════════════════
-- Schritt 2: Notation definieren
-- ═══════════════════════════════════════════════════

-- `scoped notation` bedeutet: die Notation gilt nur,
-- wenn der Namespace geöffnet ist. Das verhindert Konflikte.

namespace REALOQS

-- Bilinearform: ⟪f, L, g⟫
scoped notation "⟪" f ", " L ", " g "⟫" => bilinForm L f g

-- Quadratische Form ist der Spezialfall f = g,
-- braucht keine eigene Notation: man schreibt einfach ⟪f, L, f⟫

end REALOQS

-- ═══════════════════════════════════════════════════
-- Schritt 3: Verwendung — vorher vs. nachher
-- ═══════════════════════════════════════════════════

section Beispiel

variable (L : Matrix Ω Ω ℝ) (f g : Ω → ℝ)

open REALOQS

-- VORHER (schwer lesbar):
-- ∑ i : Ω, f i * (∑ j : Ω, L i j * f j)
--   = ∑ i : Ω, f i * (∑ j : Ω, L_II i j * f j)

-- NACHHER (sofort verständlich):
-- ⟪f, L, f⟫ = ⟪f, L_II, f⟫

-- Beispiel-Lemma mit der neuen Notation:
example (h : ⟪f, L, f⟫ = 0) : bilinForm L f f = 0 := h

-- Lean weiß, dass ⟪f, L, f⟫ und bilinForm L f f dasselbe sind.
-- Die Notation ist rein syntaktischer Zucker.

end Beispiel

-- ═══════════════════════════════════════════════════
-- Schritt 4: Weitere nützliche Notationen für REALOQS
-- ═══════════════════════════════════════════════════

namespace REALOQS

-- Matrixexponential
scoped notation "exp(" z "·" H ")" => NormedSpace.exp (z • H)

-- Spur
scoped notation "Tr(" A ")" => Matrix.trace A

-- Konjugierte Transponierte
scoped notation A "†" => Matrix.conjTranspose A

end REALOQS

-- ═══════════════════════════════════════════════════
-- Zusammenfassung
-- ═══════════════════════════════════════════════════

/-!
## Was passiert hier?

1. `notation` / `scoped notation` definiert ein neues Symbol
2. `=>` sagt Lean, wie es intern übersetzt wird
3. Der Compiler prüft alles wie vorher
4. Nur die Anzeige für Menschen ändert sich

## Aufwand

- Eine Datei `REALOQS/Notation.lean` mit ~20 Zeilen
- Ein `import REALOQS.Notation` in jedem Modul das sie nutzt
- Null Änderung an bestehenden Beweisen (Die Beweise kompilieren identisch, egal ob die alte oder die neue Schreibweise drinsteht.)
- es muss dann nur mit suchen/ersetzen der Name in den lean-Modulen getauscht werden. alles andere bleibt erhalten

## Effekt

- Code wird lesbar wie Mathematik
- Keine Kommentare nötig für das "Was"
- Kommentare nur noch für das "Warum"
-/
 

antaris

Registriertes Mitglied
Kommt es denn darauf an, wie gekoppelt wird?
Ja, das "wie wird gekoppelt" ist zentraler Bestandteil von Pillar A. Der o.g. komplexe Beweis über mehrere Module ist quasi fast schon das Herzstück genau dieses Kopplungs-Beweis-Pfades.
Ist denn diese Kopplung symmetriebrechend?
Ja, ziemlich konkret sogar.
Damit kann ich nichts anfangen. Der Symmetriebruch und der Bruch der Skaleninvarianz findet auf dem ToC statt, bevor Größen wie E, h, c usw. überhaupt sinnvoll definiert werden können.
 

antaris

Registriertes Mitglied
Wenn ich das nun alles Revue passieren lasse, dann bleiben ein paar wenige aber sehr grundlegende Fragestellungen als Ausgangspunkt offen.

1. Das Projekt im jetzigen Stand ist nur als PoC brauchbar. Es zeigt das grundlegende Konzept aber für eine Erweiterung wären die Umbaumaßnahmen zu groß. Dabei geht es vor allem um die fehlende Struktur der Typ III_1-Algebra. Ohne braucht man nicht weitermachen, da unter anderem vN, split-property und nuclearity nicht definiert werden können. Das wäre immer nur eine halbe AQFT. Dazu kommt die Problematik der Dokumentation und der Strukturierung, sowie der benutzerdefinierten Notierungen im code. Der Vorteil ist, dass wesentliche Module funktionieren und ein großer Teil des strikten Pfad übernommen werden kann. Das Konzept der DtN-OQS funktioniert wunderbar, ist aber eben bisher nur für den hellen Sektor, als endliches Subsystem definiert. Die bisherige, zum bloßen "Rest" degradierte Umgebung, muss m.E. als zusätzlicher komplementärer Sektor zum hellen Pfad modelliert und formalisiert werden.

2. Die Idee der Formalisierung des Rests ist zwangsläufig dadurch eingeschränkt, dass das Gesamtsystem - der IDEAL-ToC - unendlich verzweigt ist. Wenn der Approximant ein endlicher Ausschnitt eines unendlichen Systems ist, dann ist das Komplement des Approxiumanten ebenfalls unendlich.

3. Anschaulich ist das wie eine endliche Box, in der unendlich hineingezoomt werden kann, wobei die innere Geometrie der Box dabei skalenunbahängig -> skaleninvariant ist (auf jeder Skala das gleiche Raster). Das Gesamtsystem als Menge ist in diesem Bild als endliche und berandete Box fassbar und es ist kein Problem einen endlichen Approximanten von der Berandung der Box, bis zu einer Verfeinerungsstufe - dem Level L_max - "herauszuschneiden" -> das ist das Skalenfenster des REAL-Approximanten. Dabei werden zwangsläufig alle feineren Skalen/Level > L_max mit abgeschnitten -> der cutoff des sogenannten UV-Tails -> im code von Pillar A ist das als stage 1 benannt. Darauf wird dann die DtN-Abbildung modelliert und das ist, was der aktuelle code im strikten Pfad von Pillar A im wesentlichen macht.

4. Nun kann aber jeder Bereich bzw. jede Region in der Box approximiert werden. Das Modell muss also auf alle möglichen Varianten der Approximation verallgemeinert werden.

Grob:
- der einfachste Fall aus 3.
- alle Varianten einer Approximantion von Level k_min -> k_max -> hat nicht nur einen UV-Tail, sondern auch ein IR-Anteil (alle Elternknoten bis zur leeren Menge, dem Ursprung des ToC -> dem Graph der skaleninvarianten Box), danebeben existieren silblings, also Geschwister neben dem Approximanten, mit eigenen Elternknoten (IR-Anteil), eigenen UV-Tail und eigener Umgebung.
- Fomalisierung der Umgebungen aus allen möglichen Variationen der hellen Approximanten und deren Komplementen als Komplementfamilien zum Erfassen alle unendlichen Kombinationen und damit der gesamten verfeinerten Box
- Formaliserung der unendlichen DtN-Maps aus den Komlementfamilien oder daraus dann die Ableitung einer vN/Typ III_1-Algebra, darauf Nuclearity und split-property, was dann zum bekannten Pfad in 3. führen muss. Nebenbei ist damit dann - neben dem hellen Sektor - ein neuer Sektor eingeführt. Dieser Sektor ist innerhalb der hellen Subsysteme eliminiert aber dennoch wirkt dieser Sektor als "Rest" auf das Subsystem.

5. All das lässt schon gar nicht mehr die Frage zu, ob ein Neuanfang im Projekt sinnvoll ist oder nicht. Ein Neuanfang ist m.E. Pflicht.
-> von allen Kommentaren bereinigte Codebasis Version 0.0605 -> REAL-OQS_v0.0605_full_no_comments.zip

6. Für 5. braucht es ein möglichst präzises Lasten- bzw. Pflichtenheft -> Regelwerke für die Struktur des codes/der Beweise, der Notationen und der Dokumentation. Das ist sozusagen das Gesetz, wonach des Projekt laufend gemessen und auditiert werden kann. Je präziser diese Vorgaben sind, umso weniger Änderungen werden nötig und desto besser wird das Ergebnis.
Ich habe einen ersten Entwurf erstellt, der sämtliche Eindrücke der letzten 2 Wochen widerspiegeln sollte -> lean_doku_regelwerk_v1_8.pdf

7. Es wird ein Projektplan benötigt. Die Frage ist dabei, ob man nur Teilbereiche betrachtet oder auch das große Ganze mit berücksichtigt. Ich denke es muss eine Mischung aus beidem sein -> immer fokussierend auf die nächsten direkt erreichbaren Zwischenziele aber immer mitdenkend bezüglich der in Ferne erkennbaren Hauptziele.
Auch dazu ein erster Entwurf, der ist aber am Anfang der Diskussion entstanden aber formuiliert immer noch ganz gut die aus meiner Sicht nächsten Schritte. Er muss aber diskutiert und sicherlich überarbeitet werden -> Cnna%20Project%20Spec%20V0%201.pdf
 

antaris

Registriertes Mitglied
Es wird ein Projektplan benötigt.
Ich bin am erstellen einer Roadmap.

Why time reversal is antiunitary - the minus sign behind Kramers degeneracy
Danke für das teilen! Nun weiß ich, dass mein vorhandener Zeitumkehr-Formalismus bei weitem noch nicht ausreichend ausmodelliert ist. Das sind bisher nur Vorstufen zu Kramers Theorem. Ich habe das und auch die Arbeit von Feynman bzw. die Konsequenzen daraus mit in den Entwurf der Roadmap aufgenommen.
 

antaris

Registriertes Mitglied
7. Es wird ein Projektplan benötigt. Die Frage ist dabei, ob man nur Teilbereiche betrachtet oder auch das große Ganze mit berücksichtigt. Ich denke es muss eine Mischung aus beidem sein -> immer fokussierend auf die nächsten direkt erreichbaren Zwischenziele aber immer mitdenkend bezüglich der in Ferne erkennbaren Hauptziele.
Ich bin am erstellen einer Roadmap.
Ich habe das aus meiner Sicht als das "große Ganze" und dessen Teilbereiche vorstelle. Formuliert ist das als grobe aber in logischer Abfolge der nötigen/wichtigsten Ableitungen, innerhalb einer partielle Ordnung und nicht als Phasen-/Zeitpläne, in einer Migrations-Roadmap zusammengefasst. Das angestrebte Ziel und welche Hürden auf dem Weg dahin mindestens genommen werden müssen, geht m.E. unmissverständlich aus der Roadmap hervor. Desweiteren ist die Roadmap so konzipiert, dass der code dagegen auditier- und prüfbar wird. Die benutzerdefinierten Notationen im code sind auch klar, wenn auch vielleicht noch nicht für alle lean-Objekte geregelt. Damit ist der Rahmen bewusst sehr eng gesetzt, die Roadmap soll aber dennoch lebendig bleiben bzw. auf kommende Veränderungen reagieren können. Phasenpläne zur Implementierung werden aus der partiellen Ordnung abgeleitet, wenn sie benötigt werden.

CNNA_Roadmap_v1.0_DE.pdf

Das Dokument wurde auf Basis des codes, der Spec (ist nun unterdeterminiert) und des Regelwerks erstellt:
 
Oben