ist Dir hinreichend klar, wie typische Mathematiker ticken, also Leute wie Ralf Kannenberg oder ich, insbesondere im Vergleich zu anderen Naturwissenschaftlern? Wieso solche Leute (theoretische) Informatiker auch als eine Art Mathematiker betrachten, hingegen bei Physikern und Ingenieuren vorsichtiger sind?

Nein nicht wirklich hinreichend. Ich glaube es hat etwas mit dem "Bezugspunkt" zu tun. Ingenieure und Physiker sind eher Technikbezogen, denn sie entwickeln technische Geräte, Bauwerke, Prototypen, deren Grundlagen und vorherige Experimente. Also eher Komponenten, Schnittstellen, Abhängigkeiten, Prüfungen und die Frage, ob die ganze Maschinerie konsistent funktioniert. Bei Mathematikern geht es dann wohl eher um die Abstraktion dieser Maschinerie.

ist Dir hinreichend klar, was Du selbst eigentlich willst? Willst Du Mathematiker abholen, weil sie Deine Zielgruppe sind? Oder willst Du sie abholen, weil Du einige der von ihnen gepflegten Werkzeuge benutzt, und Du hoffst, dass sie Dir beim erreichen Deines eigentlichen Ziels helfen können?

Sowohl, als auch aber eigentlich will ich im jetzigen Stadium weder das eine, noch das andere.

Ich habe noch vor all dem ein ganz anderes Problem. Wie strukturiere ich solch ein Projekt mit vielen verschiedenen Informationen, die alle irgendwie wichtig sind aber nicht zwangsläufig einfach nur ausgekippt werden sollten. Ich glaube den Weg der Organisation über den DAG ist schon der richtige aber dann kommen andere Fragen auf:

• Wie strukturiere ich den DAG? Aktuell ist es ein Ableitungs-DAG, der hierarchisch geordnet ist und bei den primitiven Inputs b und L, sowie der leeren Menge anfängt
• Ist der DAG bzw. sind die Knoten des DAG überhaupt geeignet, um daraus eine Doku abzuleiten. Ist es das was ein Mathematiker sehen will?
• Ist es dagegen besser eine Art Übersetzung zwischen DAG und Doku zu implementieren, welche dann z.B. die Knoten nicht als riesige zusammenhängende Ableitung dokumentiert, sondern einzelne verallgemeinerte Sätze/Beweise?

Aktuell habe ich folgende Knotentypen. Alle gehören zur Registry. Der eigentliche Ableitungsgraph wird durch die als hard dependency markierten Kanten gebildet und ist azyklisch. Zusätzlich gibt es nicht-harte Zertifizierungsbeziehungen zwischen Satz-, Beweis- und teilweise Besitzknoten; dadurch muss der vollständige Registry-Graph selbst nicht azyklisch sein (T und P).

So hat jeder Knoten eine eindeutige Funktion. Für mich zum bauen ist das aus technischer Sicht m.E. perfekt, weil ich mich wirklich vom Anfang bis Ende und Knoten für Knoten vorarbeiten kann. Für mich ist das auch logisch aufeinander aufbauend aber ob das eine Ansicht eines Mathematikers ist, das bezweifle ich tatsächlich ein wenig.
Wobei du aber Informatiker ansprichst und da gehört programmieren im Grunde auch mit rein. Ich habe aus meinem technischen Umfeld schon ein wenig Ahnung, wie man z.B. Programme für Maschinensteuerungen usw. schreibt ABER dein Einwand bezüglich des Llama paper "eher für Ingenieure" spricht natürlich schon irgendwie Bände.

Ich bin Techniker und ich mache dies alles eher aus der praktischen und mit Hintergund von im privaten/beruflichen Umfeld gesammelten technischen Erfahrungen. Auch was das Projektmanagment angeht, habe ich im technischen Bereich meines beruflichen Umfelds durchaus etwas vorzuweisen.

Ich glaube zwischen einen Techniker und einem Mathematiker ist der Anspruch an "perfekt" aber ein ganz anderer
Vielleicht ist für den Mathematiker gar nicht so interessant wie die Ableitungskette aufgebaut ist, also wie die Zahnräder der ganzen Maschinerie ineinandergreifen, sondern viel mehr welche Satze der Maschinerie, mit welchen Ausgangsobjekten, mit welchen Ziel und mit welchen Gegenkontrollen, wie genau bewiesen werden? Schließlich geht es eher darum zu zeigen: Welche Objekte existieren, sind sie wohldefiniert, welche Struktur besitzen sie, und was folgt daraus zwingend? Was sind die allgemeinen mathematische Grundpflichten und wie müssen strukturabhängige Eigenschaften aiufbereitet sein?

Dann ist der DAG natürlich weiterhin wichtig als technische Infrastruktur aber nicht als das, was in einem mathematischen Paper als Doku auftauchen sollte aber vielleicht in einem zusäzlichen Supplementary? Vielleicht sollte im Hauptpaper auch nur die mathematische Geschichte stehen aber wie genau sieht diese Prosa aus? Wie ausführlich muss es sein und wann ist es zuviel?

Also weitere Fragen kommen auf:

• Welche Art von Doku braucht es denn? Ein großes paper, in dem alles reingekippt wird? Wahrscheinlich nicht.
• Hauptpaper mit Prosa? Welche Prosa und wie ausführlich muss die Mathematik sein? Beschreibung entlang des DAG, der Theoreme, der Beweise?
• Supplementary mit ausführlicher Mathematik und Beschreibung des codes oder gar je Typ ein supplement?
  Je mehr paper einzelne Aspekte abbilden, je komplexer wird das verweisen zwischen den einzelen paper und umso mehr sind Informationen verstreut.
• Wie ordnet man Theorie, DAG, Mathematik, Python-code, Lean-code, wenn nur alles zusammen das Gesamte abbildet, das Einzelne nur Teilaspekte
• Wie muss der code strukturiert sein? Was ist die Aufgabe von Python und welche von lean? Muss lean den Python-code 1:1 spiegeln und Berechnungen auch dort ausgeführt werden oder reicht es die Numerik von Python Typgleich in lean zu beweisen, sodass beides sich ergänzt?

Das ist wahrscheinlich nur die Spitze des Eispergs meiner größeren Probleme, was das alles angeht.

Nicht nur für Pauli war das knappere Paper geeigneter. Dein Llama-3 Paper mag Ingenieure ansprechen, oder einer Verteidigung Deiner Position in einer Diskussion helfen, aber es ist nicht ansprechend, für einen Mathematiker. Der will zumindest die Illusion haben, er könne das Paper gründlich lesen und verstehen.

Es sollte ausschließlich dem im Beitrag genannten Zweck dienen: das Mapping der Variablen gegen ein "vollständiger beschriebenes" Modell mappen. Mehr nicht. Der Erdös-Beweis wurde ja schließlich mit einem wahrscheinlich noch voel vollständigeren Modell gefunden, als in dem Llama paper beschrieben. Aber ich denke ich habe den Wink im Bezug zum Thema hier verstanden.