Julia: Jeff Bezanson PhD

cc @fperez , der sich ebenfalls für dieses herausragende Thema interessiert

Begleitende Informationen beigefügt.

Aus verfahrenstechnischen Gründen erfordert das Schließen dieser möglicherweise Arbeit in einem separaten Repository. Die Abschlussarbeit sollte vielleicht in Base aufgenommen werden, um anderen das Mitarbeiten zu erleichtern.

Auch die Reihenfolge der letzten Aufgabe ist irreführend; es wird tatsächlich während des gesamten Prozesses häufig wiederkehren.

+1 für die Aufnahme in Base oder zumindest in julia/doc/thesis . Oder vielleicht theses für zukünftige Anforderungen.

(Bitte machen Sie weiter und eröffnen Sie einen Dissertationszweig, Jeff.)

Auch die Reihenfolge der letzten Aufgabe ist irreführend; es wird tatsächlich während des gesamten Prozesses häufig wiederkehren.

*ist auch schon wieder aufgetreten

Ich freue mich darauf, bei der _Close Issue_-Zeremonie dabei zu sein.

Ich kann dieses Problem nicht lokal reproduzieren; ist es MIT-spezifisch?

Einer der Hauptautoren von Julia, @JeffBezanson , hat sich zu einem problematischen Entwicklerakademiker entwickelt

Ist das die Github-Version einer Doktorarbeit? Jeff muss mit seinem Vorschlag eine PR eröffnen und das Komitee wird entscheiden, ob es fusioniert oder nicht ...

+Inf für eine schnelle Lösung dieses Problems!

Ich hatte vor ein paar Monaten das gleiche Problem auf IPython Repo, hoffentlich wurde es vor 32 Tagen behoben.
Ich bin mir ziemlich sicher, dass es um Kaffee, lästigen Papierkram und eine Planänderung in letzter Minute wegen Presslufthämmern ging.

Viel Glück !

Aktualisiert: Jeff traf sich mit seinem Thesis Committee und gab uns einen groben Überblick.

Schön zu hören, dass Fortschritte gemacht werden!

Aber git log --date=short --all --since=22.days.ago --author="Jeff Bezanson" fragt man sich immer noch, woher er die Zeit hat, eine Abschlussarbeit zu schreiben. Entweder das, oder er ist ein Superheld. Eigentlich, streich das: Wir alle wissen, dass er ein Superheld _ist_, also egal.

Die Commits mit juliatypes.jl zeichnen unsere Versuche auf, Julias Typensystem zu beschreiben, was eine direkt relevante Diplomarbeit ist.

Die Typensystemarbeit scheint schon einige Nerven zu treffen: https://twitter.com/plt_hulk/status/535045242920378369

Ich bezweifle, dass das eine direkte Antwort auf Jeffs Arbeit ist, obwohl ich mich irren könnte. Komischer Tweet so oder so.

@jiahao , mein Kommentar war meistens ironisch – ich habe mich genau darüber gewundert. Ich für meinen Teil neige dazu, viele Commits zu haben, wenn ich etwas für die Präsentation aufpoliere.

@timholy Humor bemerkt. :)

Es wäre nachlässig, die schöne Magritte-Hommage nicht zu erwähnen, die unser lokaler Theorie-Mitarbeiter @jeanqasaur gemacht und auf Twitter gepostet hat:

"The Treachery of Types" hat einen netten Klang, oder?

Das ist ziemlich lustig.

Liebe es!

Hilferuf: Jeff sucht nach netten Beispielen, die mehrere Dispatches (und vielleicht gestufte Funktionen) zeigen, Dinge, die in Sprachen ohne diese Features viel schwieriger/langsamer wären.

ist, show ?

(und vielleicht inszenierte Funktionen)

subarray.jl und subarray2.jl sollten ziemlich gut funktionieren. Das Designdokument befindet sich unter http://docs.julialang.org/en/latest/devdocs/subarrays/

Ich denke, das Distributionspaket lässt den Mehrfachversand wirklich nützlich erscheinen. Dinge wie rand(Gamma(1, 1), 5, 5) im Vergleich zu rand(Normal(0, 1), 3) zu haben, ist ein enormer Gewinn an Expressivität ohne Leistungseinbußen aufgrund des mehrfachen Versands.

Ich sehe nicht, wie das das beste Beispiel ist, da es wirklich angibt
Einzelversand. Wie unterscheidet es sich von Gamma(1,1).rand(5,5) , das Sie
in einer traditionelleren OO-Sprache wie Python oder Java tun würde?

Am Fr, 19. Dezember 2014 um 13:39 Uhr, John Myles White [email protected]
schrieb:

Ich denke, das Distributionspaket lässt wirklich mehrere Versandvorgänge erscheinen
sinnvoll. Dinge wie rand(Gamma(1, 1), 5, 5) vs rand(Normal(0, 1),
3) ist ein enormer Zugewinn an Ausdruckskraft ohne Leistungseinbußen wegen
Mehrfachversand.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67678367.

OK. Ersetzen Sie dies durch Beispiele für die Berechnung von KL-Divergenzen unter Verwendung von Analyseergebnissen: kl(Normal(0, 1), Normal(0, 1)) vs kl(Normal(0, 1), Gamma(1, 1)) .

Ich hätte auch hinzufügen sollen, dass es in meinem ersten Beitrag in #8235 einige potenziell nützliche Statistiken darüber gab, wie das Leben _ohne_ gestufte Funktionen gewesen wäre. Die Take-Home-Nachricht: Das Generieren aller Methoden durch Dimension 8 führte zu > 5000 separaten Methoden und erforderte über 4 Minuten Parsing- und Senkzeit (dh eine 4-Minuten-Verzögerung beim Kompilieren von Julia). Im Vergleich dazu lädt die Stagedfunction-Implementierung im Handumdrehen und kann natürlich sogar über 8 Dimensionen hinausgehen.

Im Gegensatz zu Single-Dispatch demonstriert es immer noch die Vereinheitlichung dessen, was andere OO-Sprachen als beschreiben: Funktionen vs. Methoden. Sie könnten Pythons sorted(a) vs a.sort() gegenüberstellen. Im Vergleich zu "traditionellen" OO-Sprachen ändert es dramatisch, was es bedeutet, wenn eine Funktion einer Klasse "zugehörig" ist.

Sie könnten darauf hinweisen, wie es die Notwendigkeit statischer vs. Instanzvariablen ersetzt, da Sie auf die Instanz oder den Typ verteilen können. Vielleicht habe ich noch ein paar Ideen aus einigen kürzlichen IRC-Gesprächen, wenn ich an einen Computer komme.

Ich habe eine Implementierung von fmap . Dies durchläuft mehrere Arrays und
wendet eine Funktion auf jeden Satz von Elementen an. Diese Implementierung ist tatsächlich
sehr langsam, da die Anzahl der Arrays beliebig sein kann. Um dies nützlich zu machen,
Ich habe diese Spezialisierung für verschiedene Anzahlen manuell erstellt
Argumente yss . Ich wollte schon immer eine gestufte Funktion dafür schreiben,
habe es aber noch nicht gemacht.

Die gestufte Funktion müsste insbesondere den map -Aufruf auswerten
das erzeugt die Argumente für f .

-erik

function fmap{T,D}(f::Function, xs::Array{T,D}, yss::Array...;
                   R::Type=eltype(f))
    [<strong i="18">@assert</strong> size(ys) == size(xs) for ys in yss]
    rs = similar(xs, R)
    <strong i="19">@simd</strong> for i in 1:length(xs)
        <strong i="20">@inbounds</strong> rs[i] = f(xs[i], map(ys->ys[i], yss)...)
    end
    rs::Array{R,D}
end

Am Freitag, 19. Dezember 2014 um 12:46 Uhr, Steven G. Johnson <
[email protected]> schrieb:

Hilferuf: Jeff sucht nach netten Beispielen, die mehrfach auftrumpfen
Versand (und vielleicht inszenierte Funktionen), Dinge, die viel wären
schwieriger/langsamer in Sprachen ohne diese Merkmale.

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

Erik Schnetter [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

Entschuldigung, ignorieren Sie den Aufruf von eltype(f) in der Funktionssignatur in meinem Code,
das ist nicht genormt.

-erik

Am Freitag, 19. Dezember 2014 um 15:08 Uhr, Erik Schnetter [email protected]
schrieb:

Ich habe eine Implementierung von fmap . Dies durchläuft mehrere Arrays und
wendet eine Funktion auf jeden Satz von Elementen an. Diese Implementierung ist tatsächlich
sehr langsam, da die Anzahl der Arrays beliebig sein kann. Um dies nützlich zu machen,
Ich habe diese Spezialisierung für verschiedene Anzahlen manuell erstellt
Argumente yss . Ich wollte schon immer eine gestufte Funktion dafür schreiben,
habe es aber noch nicht gemacht.

Die gestufte Funktion müsste insbesondere den map -Aufruf auswerten
das erzeugt die Argumente für f .

-erik

function fmap{T,D}(f::Function, xs::Array{T,D}, yss::Array...;
                   R::Type=eltype(f))
    [<strong i="26">@assert</strong> size(ys) == size(xs) for ys in yss]
    rs = similar(xs, R)
    <strong i="27">@simd</strong> for i in 1:length(xs)
        <strong i="28">@inbounds</strong> rs[i] = f(xs[i], map(ys->ys[i], yss)...)
    end
    rs::Array{R,D}
end

Am Freitag, 19. Dezember 2014 um 12:46 Uhr, Steven G. Johnson <
[email protected]> schrieb:

Hilferuf: Jeff sucht nach netten Beispielen, die mehrfach auftrumpfen
Versand (und vielleicht inszenierte Funktionen), Dinge, die viel wären
schwieriger/langsamer in Sprachen ohne diese Merkmale.

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

Erik Schnetter [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

Erik Schnetter [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

@timholy , da Matlab und NumPy auch Subarrays/Slices haben, warum können wir argumentieren, dass hier mehrfacher Versand unerlässlich ist?

Leichtigkeit der Durchsetzung? Soweit ich das beurteilen kann, können Sie den Mehrfachversand in jeder Sprache simulieren, daher ist dies für nichts erforderlich.

Vielleicht nicht gut, um etwas vorzuschlagen, von dem wir noch nicht entschieden haben, was wir wollen. In https://github.com/JuliaLang/julia/issues/9297 gibt es einen Vorschlag, der es uns ermöglicht, sowohl effiziente UTF-8-Pufferpositionen als auch eine bequeme Indizierung ohne Löcher zu haben, sodass Sie bequem rechnen können, wenn Sie dies wünschen. Regex und Suche geben den umschlossenen internen Index zurück, aber s[2] kann das zweite Zeichen geben, unabhängig davon, wie viele Bytes verwendet wurden, um das erste zu codieren.

Können sie effiziente Subarrays/Slices von AbstractArrays erstellen oder funktioniert ihre Implementierung nur für zusammenhängende Speicherblöcke? Dies ist kein allzu schwer zu lösendes Problem, wenn Sie davon ausgehen können, dass Ihr übergeordnetes Array über zusammenhängenden Speicher verfügt. Es wird interessanter, wenn Sie diese Annahme nicht treffen.

Ja, das ist die Schlüsselfunktion, nach der wir suchen: Nicht nur, dass etwas mit mehreren Dispatch- und/oder Staging-Funktionen gut gemacht werden kann, sondern dass das Fehlen dieser Funktionen in anderen Sprachen die Implementierung der Funktion viel schwieriger gemacht hat (idealerweise so sehr schwieriger, dass es noch niemand versucht hat).

@timholy , ein NumPy-Array ist durch einen festen Schritt für jede Dimension gekennzeichnet, nicht unbedingt durch Kontiguität (im Wesentlichen äquivalent zu unserem DenseArray ). Diese Eigenschaft bleibt beim Slicen erhalten, sodass Slices selbst geschnitten werden können usw.

aberrant hatte einige gute Fragen zum IRC in dieser Richtung. Ich habe versucht, nur die relevanten Kommentare (aus den nicht verwandten Konversationen und Benachrichtigungen) unten zu extrahieren:

2014-12-10 (EST)
11:41 aberrant: “Organizing methods into function objects rather than having named bags of methods “inside” each object ends up being a highly beneficial aspect of the language design.”
11:41 aberrant: why?
12:20 Travisty: aberrant: I can’t speak for them, but I imagine that the argument is that it’s a nice separation of concerns. I have data (which I will represent with types) and routines for operating on that data (which I will represent as functions), and rather than having some routines belong to specific types, they are kept separate
12:21 aberrant: Travisty: I sort of understand the argument, but I’m not sure I agree with it :)
12:22 Travisty: aberrant: Yeah, sure. This is the sort of thing that may be hard to argue about from first principles, and it may be useful to look at examples. I think one place where this design simplified things was in impementing the standard mathematical functions on all of the numeric types, and dealing with conversion
12:22 Travisty: I’m not sure, but I think the solution in julia is quite elegant because of this design and it would be a bit trickier to do it in the traditional OOP setting
12:23 aberrant: Travisty: perhaps. I need to think about it some more. I really like pure OO, and this is a bit of a change that I need to wrap my head around.
...
12:54 vtjnash: julia has a convention that a method name will end in a ! to signify that the method will mutate one of it's arguments
12:56 aberrant: that’s one thing I sorely miss in python. foo.sort() vs foo.sorted() always confused me.
12:57 vtjnash: except that in python, isn't it sort(foo) vs sorted(foo) ?
12:57 aberrant: it might be :)
12:58 aberrant: no
12:58 aberrant: it’s foo.sort vs sorted(foo)
12:58 vtjnash: ah
12:58 aberrant: foo.sort modifies foo in place.
12:58 aberrant: see?
12:58 aberrant: that’s what I mean.
12:58 vtjnash: well, anyways, that's an unintentional example of why . oriented programming is a pain
12:58 aberrant: sort(foo) vs sort!(foo) makes much more sense.
12:59 vtjnash: python made a reasonable choice there
12:59 vtjnash: and tries to help you remember
12:59 vtjnash: but it still was forced to make some decision

2014-12-14 (EST)
15:25 aberrant: there’s no way to do type constants, I guess?
15:25 aberrant: http://dpaste.com/18AEHBG
15:25 aberrant: like that
15:27 vtjnash: no. that declares a local variable inside the type (can be seen by the constructors and other methods in there)
15:27 vtjnash: instead, define `y(::Foo) = 6`
15:28 aberrant: is that mutable?
15:29 aberrant: hm, yeah, that’s not what I want though.
15:29 aberrant: but I guess I can use it.
15:30 vtjnash: not what you want, or not what other languages do?
15:31 vtjnash: multiple dispatch in julia allows you to collapse 4 or 5 or more different constructs needed by other OO languages into one abstraction
15:33 aberrant: oh, I see how it works.
15:33 aberrant: well, it’s a function and therefore more overhead
15:33 aberrant: basically, I want to set the “bitwidth” of an IPv4 address to be 32, and the “bitwidth” of an IPv6 address to be 128, and then be able to write a function that takes ::IPAddr and uses the appropriate bitwidth.
15:34 aberrant: I can do this with the function, but it seems like overhead to have a function return a constant.
15:35 aberrant: e.g., http://dpaste.com/3RXRCAG
15:36 vtjnash: don't assume that a function has more overhead
15:36 vtjnash: in this case, it would actually have less overhead
15:54 aberrant: wow, ok
15:54 aberrant: I don’t see how, but I’ll take your word for it :)
15:59 vtjnash: inlining
...
18:04 aberrant: there’s no way to associate a constant inside a type?
18:04 aberrant: it would make my life a whole lot easier.
18:04 mlubin: aberrant: t.constant or constant(t) is just a syntax difference
18:04 mlubin: julia uses the latter
18:05 aberrant: mlubin: the issue is that you have to instantiate the type first.
18:05 aberrant: mlubin: I need the equivalent of a class property.
18:05 mlubin: constant(::Type{Int32}) = 10
18:05 mlubin: constant(Int32)
18:05 aberrant: oh. wow.
18:06 Travisty: The only member of Type{T} is T, which is why this works
18:06 mlubin: mind=blown? ;)
18:06 aberrant: yeah
18:06 aberrant: that’s jacked up
18:07 aberrant: there’s NO WAY I would have ever thought of that on my own :(
18:07 mlubin: once you see it for the first time it becomes a lot more intuitive
18:07 aberrant: ipaddrwidth(::Type{IPv4}) = uint8(32)
18:08 aberrant: w00t
18:10 aberrant: can I do a const in front of that?
18:11 Travisty: I don’t think so, but usually when julia generates code, it should be inlined so that just the constant uint8(32) appears, instead of a function call

wenn Sie nach weiteren Beispielen suchen: https://github.com/JuliaLang/julia/pull/7291

Die Netto-Code-Reduktion ist schön von 6K C++ auf etwa 1K Julia. Erste Leistungsbenchmarks zeigen, dass es knapp das Doppelte des nativen C++ ist.

Wie viele Sprachen kennen Sie, die die Implementierung von printf beanspruchen können, von den Operatoren (+-*/, Int, Float) bis hin zur numerischen Ausgabeformatierung, in der Sprache selbst und Benchmarks mit einem kleinen Rand der libc-Versionen? Vielleicht C++? C kann dies nicht einmal behaupten (es gibt keine Operatorüberladung).

Python/MATLAB/etc. Vielleicht können Sie Teile davon für sich beanspruchen, aber haben Sie jemals versucht, die Zeichenfolgenoperatoren in MATLAB zu verwenden?

Dies ist eine sehr interessante Diskussion, und ich möchte einige Punkte hinzufügen:

• Was anscheinend nicht wirklich beantwortet wird, ist, wie sich Julia in Bezug auf die Geschwindigkeit mit Polymorphismus in C++ vergleicht. In C++ kann man statischen Polymorphismus durch Templates oder dynamischen Polymorphismus durch OO haben. Letzteres erfordert jedoch eine Vtable und ist immer etwas langsamer, insbesondere wenn solche Dinge in einer engen Schleife aufgerufen werden. Aus diesem Grund würde man den Array-Zugriffsoperator niemals überladen, da dies nicht schnell wäre. Eigen verwendet zum Beispiel statischen Polymorphismus.
• In Julia gibt es kein Ziel zwischen einer virtuellen und einer nicht virtuellen Funktion, und wir haben immer noch keine Leistungseinbußen. Mein Verständnis ist, dass der große Vorteil darin besteht, dass Julia Code "on the fly" generieren kann und somit immer noch schnellen Code generiert, wo in der C++-Laufzeit bedeutet, dass man den generierten Code nicht mehr ändern kann. Zusätzlich können wir in Julia Inlining zur Laufzeit durchführen. Also kein Overhead für Funktionsaufrufe. Und bei Julia müssen wir an all das nicht denken, weil es automatisch gemacht wird
• Eine große Sache (wieder) ist: Generika ohne Overhead und ohne all die Schmerzen, die C++ hat (siehe Kompilierzeiten). Es gibt verschiedene Methoden, wie man Generika implementiert, und IMHO verwendet Julia dasselbe Modell wie C#, daher ist dies möglicherweise nicht ganz neu (z Jeffs These). Aber dennoch denke ich, dass dies etwas sein könnte, was in der Abschlussarbeit diskutiert werden könnte.

Wie schwer es ist, zu erklären, wie effektiv der Mehrfachversand ist, ist an sich schon interessant.

Ich bin froh, dass wir jetzt auf derselben Seite sind. Ja, unsere neuen SubArrays sind nicht darauf angewiesen, Fortschritte zu haben, noch erfordern sie eine lineare Indizierung (obwohl sie sie verwenden können und standardmäßig tun, wenn sie effizient ist). Sie arbeiten also effizient für jedes AbstractArray und unterstützen auch Ansichten ohne Schrittweite ( Vector{Int} -Indizes).

Zur Verdeutlichung habe ich unsere neuen SubArrays in erster Linie als Beispiel für gestufte Funktionen vorgestellt, nicht für mehrfachen Versand. Allerdings würde das aktuelle Schema ohne mehrfachen Versand im Konstruktionsschritt auseinanderfallen: Wir rufen völlig unterschiedliche Konstruktormethoden für slice(::AbstractArray, ::UnitRange{Int}, ::Int, ::Vector{Int}) und slice(::AbstractArray, ::Int, ::UnitRange{Int}, ::UnitRange{Int}) auf usw. Diese Konstruktoren werden von gestuften Funktionen generiert, aber wir müssen mehrfach gesendet werden, damit das System funktioniert.

Ohne separate Funktionen muss sich ein varargs-Konstruktor der Tatsache stellen, dass das Schleifen über die Einträge im Indizes-Tupel nicht typstabil ist: Um einzelne Indizes in einer Schleife zu verarbeiten, müssen Sie sie einer benannten skalaren Variablen zuweisen, und diese Variable ist es garantiert nicht gut typisiert, obwohl das Eingabetupel es sein kann. Natürlich macht die gestufte Funktion so viel mehr: Fast alle „harten“ Entscheidungen – lassen wir dies als geteilte Dimension fallen oder behalten wir sie bei, und was sind die Konsequenzen für die interne Repräsentation des Objekts? --- kann zur Kompilierzeit erstellt werden, wodurch der Laufzeitkonstruktor auf eine bemerkenswert triviale Operation reduziert wird. Es kommt einfach vor, dass die jeweilige triviale Operation für jede Kombination von Eingabetypen unterschiedlich ist. Um diese Trivialität auszunutzen und die Konstruktion schnell zu machen, müssen Sie verschiedene Methoden aufrufen, die für jede Kombination von Eingabetypen angepasst sind. Aus diesem Grund benötigen Sie sowohl gestaffelte Funktionen als auch Mehrfachversand.

Persönlich bezweifle ich, dass es möglich wäre, das zu tun, was wir ohne die Kombination aus gestuften Funktionen und mehrfachem Versand getan haben, und dass es wahrscheinlich ist, dass julia jetzt die flexibelsten und effizientesten Array-Ansichten aller Sprachen hat. Aber ich behaupte nicht, irgendeine tatsächliche Untersuchung dieses Problems unternommen zu haben.

Deshalb frage ich mich, ob ich unsere SubArrays zur Veröffentlichung aufschreiben sollte – es scheint, als hätten wir hier etwas Neues.

@StefanKarpinski : Seien wir mal selbstkritisch: Vielleicht haben wir es einfach noch nicht aufgeschrieben?

@timholy Ich sehe hier eigentlich zwei Dinge, die inszenierten Funktionen (die ich zugeben muss, nicht vollständig verstanden) und wie Julia in das Universum der virtuellen C++-Funktionen im Vergleich zum Vorlagenuniversum passt (C# und Java sind hier ähnlich).

Für den C++-Vergleich wäre es sehr interessant, Timings durchzuführen und experimentell zu beweisen, dass wir Polymorphismus zur Kompilierzeit erreichen können (was wir sicher tun).

Eine andere Sache, die ich seit einiger Zeit formulieren wollte, ist, wie Julia im Vergleich zu C++ in Bezug auf C++ Concepts (lite) abschneidet. Die Subtypisierung, die wir haben, ist ein großer Teil von C++-Konzepten.

Muss man überhaupt eine Menge C++-Code schreiben und Timings ausführen, um dies zu überprüfen?

A = rand(3,5)
<strong i="6">@code_llvm</strong> slice(A, 2, :)
<strong i="7">@code_llvm</strong> slice(A, :, 2)

Da ist im Grunde nichts als Lade- und Speicheroperationen (dh Speicherzugriffe) drin.

@timholy Ich denke, es lohnt sich, dies aufzuschreiben. Ich glaube (habe es aber nicht verifiziert), dass viele Systeme, die Nd-Arrays implementieren, spezielle Implementierungen für die ersten paar Dimensionen haben und dann im Allgemeinen auf etwas Langsames zurückgreifen, und das sollte für die neue Implementierung nicht der Fall sein.

Ein weiterer verwandter Fall ist das Schreiben eines effizienten Sparse-Nd-Speichers (Arrays sind der übliche Spezialfall).

Timo,

Ja, in der Tat ist das Betrachten des resultierenden Assemblercodes ein großartiges Werkzeug. Aber dennoch denke ich, dass dies in einem größeren Kontext verglichen werden muss, wo (in der C++-Implementierung) virtuelle Funktionen berücksichtigt werden müssten.

Meine Vermutung ist wirklich, dass es nicht multiple dispatch ist, das so schnell ist, sondern dass wir zur Laufzeit inline können und so virtuelle Funktionen (die unsere generischen Funktionen sind) in effiziente Anweisungen ohne Funktionsaufrufindirektion umwandeln können.

Wenn das stimmt (korrigieren Sie mich bitte, wenn ich falsch liege @JeffBezanson @vtjnash @stevengj @timholy ), ist das Vielfache in multiple dispatch nicht der Grund dafür, dass Julia so schnell ist, sondern ein netter Nebeneffekt, dass bestimmter Code formuliert werden kann schöner (wo Einzelversand begrenzt ist)

Ich verstehe wahrscheinlich nur nicht, aber ich bin mir der Unterscheidung, die Sie treffen, nicht sicher. Bei Julia scheinen „inline“ und „runtime“ nicht wirklich zusammenzupassen; Inlining wird während der Typinferenz durchgeführt, dh zur Kompilierzeit. Mehrfachversand wird verwendet, um das geeignete Verfahren für die abgeleiteten Typen auszuwählen.

Die Verwirrung besteht hier darin, dass "Kompilierzeit" und "Laufzeit" von C++ nicht mit denen von Julia verglichen werden können. Codegen kann während der "Laufzeit" passieren, also ja, ich denke, wenn ich include("myscript.jl") mache, wird Inlining durchgeführt. Und auch wenn „Laufzeit“ nicht das richtige Wort dafür ist, aus C++-Sicht ist es „Laufzeit“.

Und das Dispatching auf verschiedene Typen ist wie eine Vtable, aber allgemeiner, oder?

Deshalb frage ich mich, ob ich unsere SubArrays zur Veröffentlichung aufschreiben sollte – es scheint, als hätten wir hier etwas Neues.

Es ist ein bisschen weit von Standardthemen entfernt, aber Sie könnten erwägen, sich bei JSS einzureichen. Wir brauchen mehr Julia-Artikel.

Ich würde es lieben, wenn Tim einen Blogbeitrag schreibt, um diese Arbeit zu Beginn zu beschreiben, da es viele Leute auf den neuesten Stand bringen wird. JSS ist eine großartige Idee, und vielleicht lohnt es sich, auch einige der grundlegenden Arbeiten, die in Datenrahmen und Distributionen geleistet wurden, aufzuschreiben? Ich würde es auf jeden Fall gerne lesen.

Was mich auf die Idee gebracht hat, ist, dass vieles davon aufgeschrieben wurde: http://docs.julialang.org/en/latest/devdocs/subarrays/. Für eine Veröffentlichung möchten Sie viel mehr ins Detail gehen, aber dies trifft eine ganze Reihe der wichtigsten Punkte des Gesamtbildes.

Zu der Frage, die @stevengj zum Mehrfachversand gestellt hat, würde ich sagen, dass es ohne Mehrfachversand ziemlich schwierig ist, unsere Basisbibliothek in Julia zu schreiben. Ich sage, was hier bereits jedem bekannt ist, und frage mich, ob dies nicht ein überzeugendes Beispiel für die hier genannten Gründe ist.

Details wie Nummernoperationen und die Conversion/Promotion sind eng mit dem Mehrfachversand verknüpft. Da der Mehrfachversand im Wesentlichen den Typrückschluss im Compiler der Art und Weise aussetzt, wie Typen im Code verwendet werden, sind wir in der Lage, eine generische und schnelle numerische Basisbibliothek zu schreiben. Um eine Aussage zu zitieren, die Sie gemacht haben - es hilft, die Richtlinienerstellung vom Compiler und in Bibliotheken zu trennen. Zum Beispiel hat mir @JeffBezanson einmal gezeigt, wie die Scheme-Spezifikation 1/3 ihres Platzes für numerische Details ausgibt.

Viele interpretierte Systeme haben oft allgemeine Typen und untersuchen die Typen ihrer Objekte zur Laufzeit, um Entscheidungen darüber zu treffen, welcher Code ausgeführt werden soll. Sie haben dann oft eine separate Implementierung in C/C++/Fortran in der Basisbibliothek für jeden Typ, was zu einer großen und schwer zu debuggenden Codebasis führt. Oft werden diese durch ein externes Makrosystem generiert, aber die Verwendung von C++-Vorlagen hat dieses spezifische Problem zunehmend vermieden. Das Problem der zwei Sprachen und der Typinferenz bleibt in diesen Fällen bestehen.

Auf einer gewissen Ebene bedeutet Vektorisierung, wie viele wissenschaftliche Sprachen die Kosten für die Bestimmung von Typen zur Laufzeit und die Durchführung der entsprechenden Codeauswahl amortisieren. In Julia sind unsere Kosten für beides mit der Kombination aus Typinferenz, Multiple Dispatch und generischer Programmierung deutlich niedriger, sodass wir generischen devektorisierten Code – C ohne Typen – schreiben können.

Ein Beispiel ist der Ungleichheitsvergleich mit MathConst (repräsentiert irrationale Zahlen) in PR #9198:

https://github.com/JuliaLang/julia/pull/9198/files#diff -e247e18c426659d185379c7c96c1899dR29

• FloatingPoint vs MathConst vergleicht den Float mit dem Float über/unter der Konstante
• Rational{T} vs MathConst (für gebundene Integer-Typen T ) findet die nächste rationale Darstellung durch den Typ; dann basierend darauf, ob es über oder unter dem wahren irrationalen Typ liegt.

Was dies möglich macht, ist der einfache Zugriff auf die Rational - und BigFloat -Funktionalität zur Kompilierzeit. Obwohl es möglich wäre, so etwas wie einen Makro-Präprozessor zu verwenden, wären im Wesentlichen zwei Implementierungen der gesamten Funktionalität erforderlich.

Ich habe ein kleines Update zu diesem Thema. Das Dokument ist jetzt öffentlich zugänglich: https://github.com/JeffBezanson/phdthesis

Heute veröffentliche ich eine Art Entwurf zu einer selbst gesetzten Frist. Es ist nicht viel von einem Entwurf; Viele Teile fehlen komplett. Ich übernehme auch keine Verantwortung für irgendetwas, das sich in TeX-Kommentaren befindet oder nur in der Geschichte der vergangenen Version vorhanden ist :)

Alle Rückmeldungen willkommen! Insbesondere, wenn Sie schöne Beispiele für Julia-Code haben, die die Sprache gut zur Geltung bringen, insbesondere alles, was ohne sie nur schwer möglich wäre. Immer auf der Suche nach guten, nicht trivialen Beispielen für Mehrfachversand.

Danke, dass du das öffentlich gemacht hast. Ich war überrascht, als ich versuchte, einem Link zu folgen, den SGJ benutzte, und einen 404 traf.

Vielleicht könnte die Dreiecksmatrix-Arithmetik ein Beispiel für die Nützlichkeit von Julias Mehrfachversand sein. Hier UpperTriangular+UpperTriangular=UpperTriangular , aber UpperTriangular+LowerTriangular=Matrix .

Wir haben auch über die Förderung von Elementtypen gesprochen. Mir gefällt, dass Sie Werbung vermeiden können, wenn es nicht notwendig ist, z

julia> Base.LinAlg.UnitLowerTriangular(ones(Int, 3, 3))\[1,2,3]
3-element Array{Int64,1}:
 1
 1
 1

julia> Base.LinAlg.UnitLowerTriangular(ones(Int, 3, 3))\[1,2,3.0]
3-element Array{Float64,1}:
 1.0
 1.0
 1.0

Ich kann nicht sagen, wie spezifisch das für Julia ist, aber wie wir gesehen haben, hat es den Anschein, dass zumindest Eigen die Beförderung nicht verwalten wird, sondern verlangt, dass die Elementtypen unter der Operation der linearen Algebra stabil sind.

Jeff geht jetzt hoffentlich in die Endspurt, daher wären Rückmeldungen und Korrekturen zu seiner These (siehe oben genanntes Github-Repository) jetzt besonders willkommen.

Fühlen Sie sich frei, PRs für Tippfehler, fehlende Referenzen usw. einzureichen.

@stevengj Müssen wir hier mit einer Ankündigung des Verteidigungsplans rechnen?

Jawohl.

Ich hoffe, er hat bereits einen Job am MIT in Aussicht... (oder irgendwo, wo er die großartige Julia-Arbeit fortsetzen wird)... und liest jetzt seine Doktorarbeit... großartige Sachen, IMO!

@andreasnoack Ein bisschen esoterisch, aber trotzdem lustig: Definiere einen Pfeilmatrix-Ringtyp und wende die Cholesky-Faktorisierung von der Basis an, um zu sehen, wie die Struktur einer Cholesky-Faktorisierung einer Pfeilmatrix von Pfeilmatrizen aussieht. https://gist.github.com/mschauer/c325ff89cd378fe7ecd6 ("A" Pfeilmatrix, "F" Vollmatrix, "L" Unterer Halbpfeil").

@ScottPJones danke!!

Verteidigung angesetzt: Mittwoch, 13. Mai, 13 Uhr Stata D-463.

@JeffBezanson planst du, es über replay.csail.mit.edu aufnehmen zu lassen?

...vielleicht vergesse ich es lieber... :)

Ist das nicht das letzte Kontrollkästchen?

Sind Sie _wirklich_ sicher, dass Sie die Adresse angeben sollten? Du könntest von Fanboys überrannt werden, die unterschriebene Kopien deiner Abschlussarbeit haben wollen! :grins:

Ich habe meine Karten schon. Ich habe gehört, dass der Preis auf dem Schwarzmarkt bereits bei 800 $ liegt.

Stata D-463 war zu meiner Zeit noch nicht da ... (Ich war nur dort, um Freunde zu besuchen und für den NE-Datenbanktag) ... Wird es groß genug sein? Sicherlich wird er 10-250 brauchen!

Offiziell passen in D-463 48 Stühle. Wenn wir der Meinung sind, dass das nicht ausreicht, können wir versuchen, ein größeres Zimmer zu bekommen.

Ich glaube wirklich nicht, dass du wirklich zu schätzen weißt, was du getan hast! Wenn alle Ihre Fans auftauchen würden, wären 10-250 vielleicht nicht groß genug... Buchen Sie Kresge jetzt!

Abstraktion in der Technischen Informatik

• Doktorand: Jeff Bezanson
• Betreuer der Dissertation: Prof. Alan Edelman
• Thesis Committee: Prof. Steven Johnson, Prof. Saman Amarasinghe, Prof. Gerry Sussman
• Datum: Mittwoch, 13. Mai 2015
• Zeit: 13 Uhr
• Standort: MIT-Campus, 32-D463

_Array-basierte Programmierumgebungen sind beliebt für wissenschaftliches und technisches Rechnen. Diese Systeme bestehen aus eingebauten Funktionsbibliotheken gepaart mit Hochsprachen für die Interaktion. Obwohl die Bibliotheken gut funktionieren, wird allgemein angenommen, dass die Skripterstellung in diesen Sprachen zwangsläufig langsam ist und dass nur heroische Ingenieursleistungen dieses Problem bestenfalls teilweise lindern können._

_Diese Diplomarbeit argumentiert, dass eine kohärentere Struktur für diese Funktionalität wirklich benötigt wird. Um einen zu finden, müssen wir uns fragen, worum es bei Technical Computing wirklich geht. Diese Arbeit legt nahe, dass diese Art der Programmierung durch eine Betonung der Operatorkomplexität und der Codespezialisierung gekennzeichnet ist und dass eine Sprache entwickelt werden kann, die diesen Anforderungen besser entspricht._

_Die Schlüsselidee besteht darin, Code_ _Auswahl _ _mit Code_ _Spezialisierung _ zu integrieren, _unter Verwendung generischer Funktionen und Datenflusstyp-Inferenz. Systeme wie diese können unter ineffizienter Kompilierung leiden oder unter Unsicherheit darüber, worauf sie sich spezialisieren sollen. Wir zeigen, dass ein ausreichend leistungsfähiger typbasierter Versand diese Probleme angeht. Die resultierende Sprache, Julia, erreicht eine "Erklärung durch Eliminierung" im Stil von Quine für viele der produktiven Funktionen, die Benutzer von technischen Computern erwarten._

Wird es gedruckte Exemplare seiner Dissertation für Zuschauer geben?

Eventuell signierte Exemplare

Das ist es, worauf ich hoffe ... Ich denke, ich kann in 10-15 Jahren ein paar große Dollars bei Ebay bekommen, wenn ich ein signiertes Exemplar verkaufe (wenn ich es wirklich brauche, um die College-Ausbildung meiner Kinder zu bezahlen ... vor allem. wenn sie dorthin gehen, wo sie gesagt haben, dass sie gehen wollen... :grins: )

Viel Glück, Jeff!

Viel Glück! Wenn ich in der Gegend wäre, wäre ich einer der Fanboys, die @ScottPJones erwähnt

@ScottPJones :+1:

Brich dir ein Bein, Jeff!

Viel Glück, Jeff!

Viel Glück! @JeffBezanson

@JeffBezanson Viel Glück!!

Hoffentlich bekomme ich einen Sitzplatz.

viel Glück

Ich sagte ihm, er hätte 10-250 buchen sollen!

von meinem Iphone gesendet

Am 13. Mai 2015 um 11:53 Uhr schrieb Yichao Yu [email protected] :

@JeffBezanson Viel Glück!!

Hoffentlich bekomme ich einen Sitzplatz.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Viel Glück!

Dito!

Zum Glück bin ich früh genug reingekommen, um einen Platz zu bekommen... und ich hatte Recht (wie immer :grins:) er hätte wirklich ein größeres Zimmer buchen sollen!

Glückwünsche

Fest.

Es ist noch ein Kontrollkästchen deaktiviert. Besser arbeiten.

:shipit: :tropisches_getränk: :biere: :cocktail: :tada: !

:Daumen hoch:

Herzlichen Glückwunsch, Dr. Bezanson!

Herzlichen Glückwunsch, Jeff!

+1

Bravo

das letzte Kontrollkästchen wurde nun mit einem Kentucky Bourbon Whiskey gefüllt.

Herzlichen Glückwunsch Jeff!

Am Mittwoch, den 13. Mai 2015 um 13:44 Uhr, Mike Nolta [email protected]
schrieb:

+1

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/JuliaLang/julia/issues/8839#issuecomment -101772806.

Glückwünsche!

Glückwunsch Jeff! :bier: :bier: :smile:

Das ist wunderbar! Herzlichen Glückwunsch, Jeff. :Feuerwerk:

Großartige Neuigkeiten. Herzlichen Glückwunsch, Jeff!

Glückwünsche!

Herzlichen Glückwunsch

Woop woop herzlichen Glückwunsch Jeff!

Herzlichen Glückwunsch, Dr. Bezanson!

Danke für das Posten des Fotos, @ScottPJones. @jiahao , ich glaube, du hast auch ein paar Fotos?

Herzlichen Glückwunsch Jeff. Ihre Arbeit, die mit dieser Promotion endete, hat viele von uns beeinflusst. Es wird und hat bereits einen enormen Einfluss auf das wissenschaftliche Rechnen! Mach weiter!

Herzliche Glückwünsche.

Toll!

Herzlichen Glückwunsch Jeff!!

Fantastisch, Glückwunsch!!

Herzlichen Glückwunsch Dr. Bezanson!

Die These, für diejenigen, die einen Blick darauf werfen möchten:

https://github.com/JeffBezanson/phdthesis/blob/master/main.pdf

Herzlichen Glückwunsch!

Glückwünsche!

Glückwünsche!

Glückwunsch :+1:

Ich weiß nicht, warum GitHub beschlossen hat, alle meine Bilder zu drehen, aber hier sind sie.

Video zur Abschlusszeremonie der Ausgabe: http://youtu.be/hGpLOZX6CEY

Aleph-Null Herzlichen Glückwunsch an dich, Jeff! Wenn du jemals in Seattle bist, lass mich dir einen Glückwunschdrink spendieren. :)

Glückwunsch Jeff. Es fühlt sich sehr schön an, Ihre Arbeit als Gemeinschaft zu feiern.

Glückwünsche!

@jiahao , es könnte sich lohnen, die neueste Welt von Julia als ergänzendes Material für die Danksagungsseite erneut auszuführen :)

Dank euch allen.

Leider ist meine Diplomarbeit noch nicht fertig, aber hoffentlich bald...

Ich habe noch ein paar Bilder, ich schicke sie Jeff nach dem Aufwachen (für seine Mutter, eine sehr nette Dame!) _Dr._ Bezanson kann sie hier posten, wenn er möchte...

Nicht durchgeführt??? Hat Gerry Sie gebeten, all diese verdammte "Syntax" zu entfernen und ihn einfach mit S-Ausdrücken schreiben zu lassen?

@JeffBezanson mit einem Mac ist kein Bild, das ich jemals erwartet hätte!

Yay!

Glückwünsche

Gut gemacht von all deinen Fans diesseits des großen Teichs.

Nicht durchgeführt??? Hat Gerry Sie gebeten, all diese verdammte "Syntax" zu entfernen und ihn einfach mit S-Ausdrücken schreiben zu lassen?

Du hast den Nagel auf den Kopf getroffen! Ich scherze nicht. Aber er wird sich mit einem optionalen S-Expr-Modus begnügen.

Ich hatte nach der Präsentation mit ihm gesprochen... er mochte Ihre Sachen, aber er interessierte sich wirklich nicht für die ganze Syntax... es gibt einfach _so_ viel davon... er erinnerte mich daran, wie klein das Scheme-Handbuch ist :grinning: Als ich ihn für 6.001 hatte [im ersten Semester wurde es gelehrt], mussten wir einen kleinen Scheme-Interpreter in MacLisp implementieren ... da Scheme so klein war, war es ziemlich machbar ...

und ich bin mir sicher, dass Sie das ziemlich schnell ausschalten können, mit dieser Flasche Bourbon als Gesellschaft (falls noch welche übrig ist! ;-) )

Apropos Länge des Schema-Handbuchs, es ist lustig: Ein großer Prozentsatz davon ist der Dokumentation des Verhaltens von Zahlen gewidmet, während dies in Julia in Bibliotheken definiert ist. Julia könnte möglicherweise eine kleinere Kernsprache als Schema sein (es sei denn, Sie haben natürlich die LLVM-Spezifikation daran geheftet).

Dafür oder dagegen, es wird zu viel Wert auf die Syntax gelegt! Sehen Sie sich auch Abschnitt 7.1 von http://www.schemers.org/Documents/Standards/R5RS/HTML/ an. Die Scheme-Syntax ist komplexer als man denkt!

Julia könnte möglicherweise eine kleinere Kernsprache als Schema sein (es sei denn, Sie haben natürlich die LLVM-Spezifikation daran geheftet).

Ja, Julia hat gute Knochen!

Zeit, das alte Makro @sexpr auszugraben?

Herzlichen Glückwunsch zum Abschluss und zu dem, was Sie mit Julia herausgeholt haben!

:Kuchen: Herzlichen Glückwunsch!

Herzlichen Glückwunsch @JeffBezanson!

Herzliche Glückwünsche :)

:+1:

@boyers! Lange nicht gesehen!

vermisse euch :)

Glückwünsche!

Nur eine Frage: Das PDF hat weder Links im Inhaltsverzeichnis noch einen durchsuchbaren Index in den PDF-Metadaten.
Warum ist es für einen Compiler-Autor mit MIT-Abschluss so schwierig, \usepackage{hyperref} in seine Präambel einzufügen?

Das liegt daran, dass Sie das Ganze lesen und nicht nur herumspringen sollen. ;-)

Aber ja, hyperref würde dies viel zugänglicher machen.

Ich verspreche Ihnen, das Ganze zu lesen, wenn Sie die Links hinzufügen :P

Glückwünsche. Freiheit wartet.

Herzlichen Glückwunsch, Dr. Bezanson!

@nicola-gigante, du kannst einen Pull-Request machen : smile:.

Können wir uns für einen Preis für die beste Dissertation einsetzen?

http://awards.acm.org/doctoral_dissertation/nominations.cfm

Gratulation!!!

@jpfairbanks - gute Idee! Es muss aber von seinem Doktorvater eingereicht werden... Plage Alan Edelman, denke ich...

Ja, es braucht eine Nominierung durch den Berater und 5 Unterstützungsschreiben. Beyogen auf
Dieses Problem denke ich, dass mindestens 5 Leute denken, dass er es verdient hat.

Ist es auf 5 Unterstützungsschreiben begrenzt? Außerdem ist die tatsächliche Anzahl der Leute, die denken, dass er es verdient, mindestens ein paar Größenordnungen größer!

@JeffBezanson : Herzlichen Glückwunsch!

@alanedelman : Ich denke, @jpfairbanks hat einen guten Punkt, Jeff sollte für den ACM Doctoral Dissertation Award nominiert werden.

@JeffBezanson Gut gemacht und wohlverdient!

@ScottPJones "Darüber hinaus sollten mindestens 3 und nicht mehr als 5 Begleitschreiben von Experten auf dem Gebiet beigefügt werden, die zusätzliche Erkenntnisse oder Beweise für die Wirkung der Dissertation liefern können."

Vielleicht schreibt Gerry ihm ja eins (nachdem er den S-Expr-Modus hinzugefügt hat!) :grins:

Titelseite von Hacker News :-) Herzlichen Glückwunsch, Jeff.

@nicola-gigante Du hast recht, ich werde hyperref hinzufügen.

Nochmals vielen Dank an alle. All Ihre Wertschätzung ist der ultimative Preis.

@jiahao Das liegt daran, dass sie EXIF-Rotationsdaten haben, die Browsern egal sind. Meistens. Chrome kümmert sich nur um EXIF-Daten, wenn das Bild ein eigenes Fenster ist. Klicken Sie mit der rechten Maustaste und "In neuem Tab öffnen", um sie in der richtigen Ausrichtung anzuzeigen.

Sie können einen EXIF-Metadaten-Stripper verwenden, um das zu entfernen und sie auf die "richtige" Weise zu drehen.

+1 für die Nominierung des ACM-Dissertationspreises.

Nominierungsschluss ist der 31. Oktober 2015.

http://awards.acm.org/doctoral_dissertation/nominations.cfm

Ich mag es nicht, dass ACM eine Urheberrechtsübertragung an sie und exklusive Veröffentlichungsrechte verlangt. Wertvoll und prestigeträchtig ist es auf jeden Fall immer noch.

Herzlichen Glückwunsch!

Exklusive Veröffentlichungsrechte!?! Ich habe Dibs auf ein signiertes Exemplar (oder zwei... brauche eines, um es in 10-15 Jahren bei e-bay zu verkaufen, ein anderes, um es für mich zu behalten :grins:)... muss das bekommen, bevor es eingesperrt ist die AKM!
(Das bedeutet natürlich wahrscheinlich, dass es in der digitalen Bibliothek der ACM für Mitglieder verfügbar wäre.)

Sobald mir die Dissertation zur Unterschrift übergeben wird, habe ich alle Absichten
der Nominierung der Dissertation für verschiedene Preise :-)

Am Sonntag, 17. Mai 2015 um 8:49 Uhr, Scott P. Jones [email protected]
schrieb:

Exklusive Veröffentlichungsrechte!?! Ich habe Dibs auf ein signiertes Exemplar (bzw
zwei ... brauche einen, um ihn in 10-15 Jahren bei e-bay zu verkaufen, einen anderen, um ihn selbst zu behalten [Bild:
:grinsend:]) ... muss das holen, bevor es von der ACM eingesperrt wird!
(Das bedeutet natürlich wahrscheinlich, dass es auf den ACMs verfügbar wäre
digitale Bibliothek für Mitglieder)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/JuliaLang/julia/issues/8839#issuecomment -102801616.

Keine Kommentare von @JeffBezanson... Ich _hoffe_, dass er feiert (mehr Häkchen in seinem letzten Kästchen) und nicht irgendwo von GJS in einen Raum gesperrt wurde, bis er einen S-Expr-Modus zum Laufen gebracht hat!

Glückwünsche!

Herzlichen Glückwunsch, @JeffBezanson!

(verspätet) Glückwunsch!

Update: habe gerade das Dokument eingereicht. Die eingereichte Version ist https://github.com/JeffBezanson/phdthesis/tree/876be73a5aab9b034fac3eb9ea9d8f96713f786f .

Ich bin sicher, es ist in vielerlei Hinsicht mangelhaft. Nun ja. Hoffentlich ist nichts wirklich schlimmes drin.

Hübsch. Herzlichen Glückwunsch, dass Sie Ihre Promotion wirklich abgeschlossen haben.

Herzlichen Glückwunsch, Jeff! Großartige Leistung. Ich bin sicher, du bist froh, dass es vorbei ist.

Ich habe bereits festgestellt, dass Ihre These einige Lücken in Julias Dokumentation füllt, also wird sie eindeutig sehr nützlich sein. Alle Dokumente sind mit Mängeln versehen; der Rest von uns ist von den Stärken beeindruckt! Herzlichen Glückwunsch!

Und danke fürs Teilen!

Wow! Herzlichen Glückwunsch zum Abschluss der Verteidigung und der Dissertation und all der anderen Arbeiten, die sie bedeuten und darstellen. Es ist schön, diesen Meilenstein zu haben, um all die Dinge anzuerkennen, die Sie erreicht haben. Ich hoffe du bist stolz!

@JeffBezanson Ich hoffe, Sie planen, sich ein paar Tage frei zu nehmen, um zu entspannen und zu feiern, oder vielleicht planen Sie, mit einer Systemüberholung oder so etwas zu feiern. :-)

Schön, dass das neue pdf hyperref hat - für diejenigen, die stöbern möchten. Wir sollten es auch auf die Julia-Publikationsliste setzen.