Julia: Jeff Bezanson PhD

cc @fperez qui s'intéresse également à ce problème en suspens

Pièces justificatives jointes.

En tant que problème de procédure, sa fermeture peut nécessiter de travailler dans un référentiel séparé. La thèse devrait peut-être être incluse dans Base pour faciliter la contribution des autres.

De plus, l'ordre de la dernière tâche est trompeur ; il se reproduira fréquemment tout au long du processus.

+1 pour l'avoir inclus dans Base, ou au moins dans julia/doc/thesis . Ou peut-être theses pour répondre aux besoins futurs.

(S'il vous plaît, allez-y et ouvrez une branche de thèse, Jeff.)

De plus, l'ordre de la dernière tâche est trompeur ; il se reproduira fréquemment tout au long du processus.

* a également déjà récidivé

J'ai hâte d'être présent à la cérémonie de _Close issue_.

Je ne peux pas reproduire ce problème localement ; est-ce spécifique au MIT ?

L'un des principaux auteurs de Julia, @JeffBezanson , est devenu un développeur académique problématique

Est-ce la version github d'une thèse de doctorat ? Jeff doit ouvrir un PR avec sa proposition et le comité décidera de fusionner ou non...

+Inf pour une résolution rapide de celui-ci !

J'ai eu le même problème sur IPython repo il y a quelques mois, j'espère qu'il a été résolu il y a 32 jours.
Je suis presque sûr que cela impliquait du café, de la paperasse ennuyeuse et un changement de plan de dernière minute à cause des marteaux-piqueurs.

Bonne chance !

Mise à jour : Jeff a rencontré son comité de thèse et nous a donné un aperçu approximatif.

Content d'apprendre que des progrès sont faits !

Mais git log --date=short --all --since=22.days.ago --author="Jeff Bezanson" fait encore se demander comment il a le temps d'écrire une thèse. Soit ça, soit c'est un super-héros. En fait, oubliez ça : nous savons tous qu'il _est_ un super-héros, alors tant pis.

Les commits impliquant juliatypes.jl enregistrent nos tentatives de description du système de typage de Julia, qui est un travail de thèse directement pertinent.

Le travail sur le système de type semble déjà énerver : https://twitter.com/plt_hulk/status/535045242920378369

Je doute que ce soit directement en réponse au travail de Jeff, même si je peux me tromper. Tweet hilarant de toute façon.

@jiahao , mon commentaire était surtout ironique --- je me suis un peu posé la question. Pour ma part, j'ai tendance à avoir beaucoup de commits lorsque je peaufine quelque chose pour la présentation.

@timholy humour noté. :)

Il serait négligent de ne pas mentionner le bel hommage à Magritte que notre collaborateur théorique local @jeanqasaur a réalisé et posté sur twitter :

"The Treachery of Types" sonne bien, non ?

C'est assez drôle.

Aimer!

Appel à l'aide : Jeff est à la recherche de bons exemples qui montrent plusieurs répartitions (et peut-être des fonctions mises en scène), des choses qui seraient beaucoup plus difficiles/plus lentes dans des langages sans ces fonctionnalités.

est, show ?

(et peut-être des fonctions mises en scène)

subarray.jl et subarray2.jl devraient plutôt bien servir. Le document de conception est à http://docs.julialang.org/en/latest/devdocs/subarrays/

Je pense que le package Distributions rend vraiment l'envoi multiple utile. Avoir des choses comme rand(Gamma(1, 1), 5, 5) vs rand(Normal(0, 1), 3) est un énorme gain d'expressivité sans coût de performance en raison de l'envoi multiple.

Je ne vois pas en quoi c'est le meilleur exemple car il se montre vraiment
envoi unique. En quoi est-ce différent de Gamma(1,1).rand(5,5) que vous
ferait dans un langage OO plus traditionnel comme Python ou Java ?

Le vendredi 19 décembre 2014 à 13h39, John Myles White [email protected]
a écrit:

Je pense que le package Distributions donne vraiment l'impression que l'envoi multiple
utile. Avoir des choses comme rand(Gamma(1, 1), 5, 5) vs rand(Normal(0, 1),
3) est un énorme gain d'expressivité sans coût de performance en raison de
envoi multiple.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67678367.

D'accord. Remplacez cela par des exemples de calcul de divergences KL à l'aide de résultats analytiques : kl(Normal(0, 1), Normal(0, 1)) vs kl(Normal(0, 1), Gamma(1, 1)) .

J'aurais également dû ajouter qu'il y avait des statistiques potentiellement utiles sur ce qu'aurait été la vie _sans_ fonctions mises en scène dans mon message initial dans # 8235. Le message à retenir : la génération de toutes les méthodes via la dimension 8 a donné lieu à > 5 000 méthodes distinctes et a nécessité plus de 4 minutes de temps d'analyse et de réduction (c'est-à-dire un délai de 4 minutes lors de la compilation de Julia). En comparaison, l'implémentation de la fonction staged se charge en un clin d'œil, et bien sûr peut même aller au-delà de 8 dimensions.

Vs single-dispatch, il démontre toujours l'unification de ce que d'autres langages OO décrivent comme : fonctions vs méthodes. Vous pouvez comparer trié(a) vs a.sort() de python. Par rapport aux langages OO "traditionnels", cela change radicalement ce que signifie pour une fonction d'être "associée à" une classe.

Vous pouvez indiquer comment cela remplace le besoin de variables statiques ou d'instance, puisque vous pouvez répartir sur l'instance ou le type. J'ai peut-être d'autres idées à partir de conversations IRC récentes, quand je peux accéder à un ordinateur.

J'ai une implémentation de fmap . Cela traverse plusieurs tableaux et
applique une fonction à chaque ensemble d'éléments. Cette implémentation est en fait
très lent car le nombre de tableaux peut être arbitraire. Pour rendre cela utile,
J'ai créé manuellement une spécialisation de ceci pour différents nombres de
arguments yss . J'ai toujours voulu écrire une fonction mise en scène pour cela,
mais je ne l'ai pas encore fait.

La fonction mise en scène devrait évaluer en particulier l'appel map
qui produit les arguments de 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

Le ven. 19 décembre 2014 à 12 h 46, Steven G. Johnson <
[email protected]> a écrit :

Appel à l'aide : Jeff est à la recherche de beaux exemples qui montrent plusieurs
dispatch (et peut-être des fonctions mises en scène), des choses qui seraient beaucoup
plus difficile/plus lent dans les langues sans ces fonctionnalités.

Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

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

Désolé, ignorez l'appel à eltype(f) dans la signature de la fonction dans mon code,
ce n'est pas standard.

-erik

Le ven. 19 décembre 2014 à 15 h 08, Erik Schnetter [email protected]
a écrit:

J'ai une implémentation de fmap . Cela traverse plusieurs tableaux et
applique une fonction à chaque ensemble d'éléments. Cette implémentation est en fait
très lent car le nombre de tableaux peut être arbitraire. Pour rendre cela utile,
J'ai créé manuellement une spécialisation de ceci pour différents nombres de
arguments yss . J'ai toujours voulu écrire une fonction mise en scène pour cela,
mais je ne l'ai pas encore fait.

La fonction mise en scène devrait évaluer en particulier l'appel map
qui produit les arguments de 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

Le ven. 19 décembre 2014 à 12 h 46, Steven G. Johnson <
[email protected]> a écrit :

Appel à l'aide : Jeff est à la recherche de beaux exemples qui montrent plusieurs
dispatch (et peut-être des fonctions mises en scène), des choses qui seraient beaucoup
plus difficile/plus lent dans les langues sans ces fonctionnalités.

Répondez directement à cet e-mail ou consultez-le sur GitHub
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 , puisque Matlab et NumPy ont aussi des sous-tableaux/tranches, pourquoi pouvons-nous affirmer que l'envoi multiple est essentiel ici ?

Facilité de mise en œuvre? Autant que je sache, vous pouvez simuler plusieurs envois dans n'importe quelle langue, donc ce n'est essentiel à rien.

Peut-être pas bon de suggérer quelque chose que nous n'avons pas encore décidé que nous voulons. Dans https://github.com/JuliaLang/julia/issues/9297 , il existe une proposition qui nous permet d'avoir à la fois des positions de tampon UTF-8 efficaces et une indexation pratique sans trous afin que vous puissiez faire de l'arithmétique pratique quand vous le souhaitez. Regex et search renverront l'index interne enveloppé, mais s[2] peut donner le deuxième caractère quel que soit le nombre d'octets utilisés pour encoder le premier.

Peuvent-ils créer des sous-tableaux/tranches efficaces de AbstractArrays , ou leur implémentation ne fonctionne-t-elle que pour des blocs de mémoire contigus ? Ce n'est pas un problème très difficile à résoudre si vous pouvez supposer que votre tableau parent a une mémoire contiguë ; cela devient plus intéressant lorsque vous ne faites pas cette hypothèse.

Oui, c'est la fonctionnalité clé que nous recherchons : non seulement que quelque chose peut être bien fait avec plusieurs fonctions de répartition et/ou de mise en scène, mais que l'absence de ces fonctionnalités dans d'autres langages a rendu la mise en œuvre de la fonctionnalité beaucoup plus difficile (idéalement, tellement plus difficile que personne ne l'a même tenté).

@timholy , un tableau NumPy est caractérisé par une foulée fixe pour chaque dimension, pas nécessairement de contiguïté (essentiellement équivalente à notre DenseArray ). Cette propriété est préservée lors du découpage, de sorte que les tranches elles-mêmes peuvent être découpées en tranches, etc.

aberrant avait de bonnes questions sur IRC dans ce sens. J'ai essayé d'extraire uniquement les commentaires pertinents (parmi les conversations et les notifications sans rapport) ci-dessous :

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

si vous cherchez plus d'exemples : https://github.com/JuliaLang/julia/pull/7291

La réduction de code net est agréable de 6K C++ à environ 1K Julia. Les tests de performance initiaux montrent que c'est un peu moins de 2 fois le C++ natif.

combien de langages connaissez-vous qui peuvent prétendre à l'implémentation de printf, des opérateurs (+-*/, Int, Float) au formatage de sortie numérique, dans le langage lui-même, et référence dans une petite marge des versions libc ? Peut-être C++ ? C ne peut même pas revendiquer cela (il n'a pas de surcharge d'opérateur).

Python/MATLAB/etc. pourriez-vous en réclamer des morceaux, mais avez-vous déjà essayé d'utiliser les opérateurs de chaîne dans MATLAB?

C'est une discussion très intéressante et j'aimerais ajouter quelques points:

• Ce qui semble ne pas être vraiment répondu, c'est comment Julia se compare au polymorphisme en C++ speedwise. En C++, on peut avoir un polymorphisme statique via des modèles ou un polymorphisme dynamique via OO. Mais ce dernier nécessite une vtable et est toujours un peu plus lent, en particulier lors de l'appel de telles choses dans une boucle serrée. Pour cette raison, on ne surchargerait jamais l'opérateur d'accès au tableau car ce ne serait pas rapide. Eigen, par exemple, utilise le polymorphisme statique.
• Dans Julia, il n'y a pas de destination entre une fonction virtuelle et une fonction non virtuelle et nous n'avons toujours pas de pénalités de performance. Ma compréhension est que l'énorme avantage est que Julia peut générer du code "à la volée" et donc toujours générer du code rapide où, dans l'exécution C++, on ne peut plus modifier le code généré. De plus, dans Julia, nous pouvons faire de l'inlining au moment de l'exécution. Donc pas de surcoût d'appel de fonction. Et dans Julia, nous n'avons pas à penser à tout cela car cela se fait automatiquement
• Une chose énorme (encore une fois) est : les génériques sans surcharge et sans toute cette douleur que C++ a (en regardant les temps de compilation) Il existe différentes méthodes pour implémenter les génériques et IMHO Julia utilise le même modèle que C#, donc ce n'est peut-être pas entièrement nouveau (pour thèse de Jeff). Mais je pense quand même que cela pourrait être quelque chose à discuter dans la thèse.

La difficulté d'expliquer l'efficacité de la répartition multiple est en soi assez intéressante.

Heureux que nous soyons sur la même page maintenant. Oui, nos nouveaux SubArrays ne reposent pas sur des foulées, ni sur une indexation linéaire (bien qu'ils puissent l'utiliser, et le font par défaut si cela s'avère efficace). Ils fonctionnent donc efficacement pour n'importe quel tableau abstrait et prennent également en charge les vues "non stridées" ( index Vector{Int} ).

Pour clarifier, j'ai présenté nos nouveaux SubArrays principalement comme un exemple de fonctions étagées, et non de répartition multiple. Cela dit, le schéma actuel s'effondrerait à l'étape de construction sans répartition multiple : nous appelons des méthodes de constructeur complètement différentes pour slice(::AbstractArray, ::UnitRange{Int}, ::Int, ::Vector{Int}) et slice(::AbstractArray, ::Int, ::UnitRange{Int}, ::UnitRange{Int}) , etc. Ces constructeurs sont générés par des fonctions étagées, mais nous besoin d'envoi multiple pour que le système fonctionne.

Sans fonctions séparées, un constructeur varargs doit faire face au fait que boucler sur les entrées du tuple d'index n'est pas de type stable : pour traiter des index individuels dans une boucle, vous devez les affecter à une variable scalaire nommée, et cette variable est garanti de ne pas être bien typé même si le tuple d'entrée peut l'être. Bien sûr, la fonction mise en scène fait tellement plus : presque toutes les décisions "difficiles" --- abandonnons-nous cela en tant que dimension découpée, ou la conservons-nous, et quelles sont les conséquences pour la représentation interne de l'objet ? ---peut être fait au moment de la compilation, réduisant le constructeur d'exécution à une opération remarquablement triviale. Il se trouve que l'opération triviale particulière est différente pour chaque combinaison de types d'entrée, donc pour exploiter cette trivialité et accélérer la construction, vous devez appeler différentes méthodes personnalisées pour chaque combinaison de types d'entrée. C'est pourquoi vous avez besoin à la fois de fonctions étagées et d'envois multiples.

Personnellement, je doute qu'il soit possible de faire ce que nous avons fait sans la combinaison de fonctions étagées et de répartition multiple, et qu'il est probable que julia dispose désormais des vues de tableau les plus flexibles et les plus efficaces de tous les langages. Mais je ne prétends pas avoir entrepris une quelconque étude réelle de ce problème.

Cela me fait me demander si je devrais rédiger nos sous-tableaux pour publication --- il semble que nous ayons quelque chose de nouveau ici.

@StefanKarpinski : Soyons autocritiques : Peut-être ne l'avons-nous pas encore écrit ?

@timholy Je vois en fait deux choses ici, les fonctions mises en scène (que je dois admettre qu'elles ne sont pas entièrement comprises) et comment Julia s'intègre dans l'univers des fonctions virtuelles C++ par rapport aux modèles (C# et Java sont similaires ici).

Pour la comparaison C++, il serait très intéressant de faire des timings et de prouver expérimentalement que nous pouvons atteindre le polymorphisme de temps de compilation (ce que nous sommes sûrs de faire)

Une autre chose que je voulais formuler depuis un certain temps est de savoir comment Julia se compare à C++ en ce qui concerne C++ Concepts (lite). Le sous-typage que nous avons est une grande partie des concepts C++.

A-t-on même besoin d'écrire un tas de code C++ et d'exécuter des timings pour vérifier cela ?

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

Il n'y a essentiellement rien d'autre que des opérations de chargement et de stockage (c'est-à-dire un accès à la mémoire).

@timholy Je pense que cela vaut la peine d'écrire ceci. Je crois (mais je n'ai pas vérifié) que de nombreux systèmes qui implémentent des tableaux Nd ont des implémentations spécialisées pour les premières dimensions, puis retombent généralement à quelque chose de lent autrement, et cela ne devrait pas être le cas pour la nouvelle implémentation.

Un autre cas connexe est l'écriture d'un magasin Nd clairsemé efficace (les tableaux étant le cas particulier courant).

Tim,

oui, en effet, regarder le code d'assemblage résultant est un excellent outil. Mais je pense toujours que cela doit être comparé dans un contexte plus large, où (dans l'implémentation C++) les fonctions virtuelles devraient être prises en compte.

Je suppose vraiment que ce n'est pas multiple dispatch qui est si rapide mais que nous pouvons inline au moment de l'exécution et ainsi transformer la fonction virtuelle (ce que sont nos fonctions génériques) en instruction efficace sans indirection d'appel de fonction.

Si c'est vrai (veuillez me corriger si je me trompe @JeffBezanson @vtjnash @stevengj @timholy ) le multiple dans multiple dispatch n'est pas la raison pour laquelle Julia est si rapide mais un côté soigné affecte que certains codes peuvent être formulés plus agréable (où l'envoi unique est limité)

Je ne comprends probablement pas, mais je ne suis pas sûr de la distinction que vous faites. Dans Julia, "inline" et "runtime" ne semblent pas vraiment aller de pair ; l'inlining est effectué pendant l'inférence de type, c'est-à-dire au moment de la compilation. La distribution multiple est utilisée pour sélectionner la méthode appropriée pour les types inférés.

La confusion ici est que le "temps de compilation" et le "temps d'exécution" de C++ ne peuvent pas être comparés à celui de Julia. Codegen peut se produire pendant "l'exécution", donc oui, je pense que lorsque je fais include("myscript.jl") l'inlining est effectué. Et même si "runtime" n'est pas le bon mot pour cela d'un point de vue C++, c'est "runtime".

Et le dispatching sur différents types est comme une vtable mais plus général, non ?

Cela me fait me demander si je devrais rédiger nos sous-tableaux pour publication --- il semble que nous ayons quelque chose de nouveau ici.

C'est un peu loin des sujets standards, mais vous pourriez envisager de soumettre à JSS. Nous avons besoin de plus d'articles sur Julia.

J'adorerais que Tim écrive un article de blog pour décrire ce travail pour commencer, car cela mettra beaucoup de gens au courant. JSS est une excellente idée, et peut-être que certains des travaux fondamentaux qui ont été effectués dans les cadres de données et les distributions valent également la peine d'être écrits ? Je serais certainement ravi de le lire.

Eh bien, ce qui m'y a fait penser, c'est qu'une grande partie a été écrite: http://docs.julialang.org/en/latest/devdocs/subarrays/. Pour une publication, vous voudriez entrer dans beaucoup plus de détails, mais cela touche un bon nombre des principaux points généraux.

À la question que @stevengj a posée à propos de l'envoi multiple, je dirais que sans envoi multiple, il est assez difficile d'écrire notre bibliothèque de base en julia. Je dis ce que tout le monde sait déjà ici, et je me demande si ce n'est pas un exemple probant pour les raisons évoquées ici.

Des détails tels que les opérations sur les numéros et la conversion/promotion sont intimement liés à l'envoi multiple. Étant donné que la répartition multiple est ce qui expose essentiellement l'inférence de type dans le compilateur à la façon dont les types sont utilisés dans le code, nous sommes en mesure d'écrire une bibliothèque de base numérique générique et rapide. Pour citer une déclaration que vous avez faite - cela aide à séparer la politique du compilateur et celle des bibliothèques. Par exemple, @JeffBezanson m'a montré une fois comment la spécification Scheme dépense 1/3 de son espace sur des détails numériques.

De nombreux systèmes interprétés finissent souvent par avoir des types généraux et inspectent les types de leurs objets au moment de l'exécution pour prendre des décisions sur le code à exécuter. Ils ont alors souvent une implémentation séparée en C/C++/Fortran dans la bibliothèque de base pour chaque type, ce qui conduit à une base de code volumineuse et difficile à déboguer. Souvent, ceux-ci sont générés via un système de macros externe, mais de plus en plus, l'utilisation de modèles C++ évite ce problème spécifique. La question des deux langues et de l'inférence de type demeure toujours dans ces cas.

À un certain niveau, la vectorisation est la façon dont de nombreux langages scientifiques amortissent le coût de la détermination des types au moment de l'exécution et de la sélection de code appropriée. Dans Julia, avec la combinaison de l'inférence de type, de la répartition multiple et de la programmation générique, nos coûts pour les deux sont nettement inférieurs, ce qui nous permet d'écrire du code dévectorisé générique - C sans types.

Un exemple est la comparaison d'inégalité avec MathConst (représentant des nombres irrationnels) dans PR #9198 :

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

• FloatingPoint vs MathConst compare le flottant avec le flottant au-dessus/en-dessous de la constante
• Rational{T} vs MathConst (pour les types entiers bornés T ) trouve le rationnel le plus proche représentable par le type ; puis selon qu'il est au-dessus ou au-dessous du vrai type irrationnel.

Ce qui rend cela possible est un accès facile aux fonctionnalités Rational et BigFloat au moment de la compilation. Bien qu'il soit possible d'utiliser quelque chose comme un préprocesseur de macro, cela nécessiterait essentiellement deux implémentations de toutes les fonctionnalités.

J'ai une petite mise à jour sur ce problème. Le document est maintenant ouvert au public : https://github.com/JeffBezanson/phdthesis

Aujourd'hui, je publie une sorte de brouillon dans un délai que je m'impose. Ce n'est pas vraiment un brouillon; de nombreuses pièces manquent entièrement. Je décline également toute responsabilité pour tout ce qui se trouve dans les commentaires TeX, ou présent uniquement dans l'historique des versions précédentes :)

Tous les commentaires sont les bienvenus ! En particulier, si vous avez de beaux exemples de code julia qui mettent bien en valeur le langage, en particulier tout ce qui serait difficile à faire sans lui. Toujours à la recherche de bons exemples d'envois multiples non triviaux.

Merci d'avoir rendu cela public. J'ai été surpris quand j'ai essayé de suivre un lien utilisé par SGJ et que j'ai frappé un 404.

Peut-être que l' arithmétique matricielle triangulaire pourrait être un exemple de l'utilité de l'envoi multiple de Julia. Ici UpperTriangular+UpperTriangular=UpperTriangular , mais UpperTriangular+LowerTriangular=Matrix .

Nous avons également parlé de la promotion des types d'éléments. J'aime que vous puissiez éviter la promotion quand ce n'est pas nécessaire, par exemple

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

Je ne peux pas dire à quel point cela est spécifique à Julia, mais comme nous l'avons vu, il est apparu qu'au moins Eigen ne gérera pas la promotion, mais exigera que les types d'éléments soient stables sous l'opération d'algèbre linéaire.

Jeff entre maintenant dans la dernière ligne droite, nous l'espérons, donc des commentaires et des corrections sur sa thèse (voir le référentiel github mentionné ci-dessus) seraient particulièrement bienvenus maintenant.

N'hésitez pas à soumettre des PR pour les fautes de frappe, les références manquantes, etc.

@stevengj Faut-il s'attendre à une annonce du calendrier de la soutenance ici ?

Oui.

J'espère qu'il a déjà un travail prévu au MIT... (ou n'importe où où il poursuivra l'excellent travail de Julia)... en train de lire sa thèse maintenant... super truc, IMO !

@andreasnoack Un peu ésotérique, mais quand même amusant: définissez un type d'anneau de matrice de flèches et appliquez la factorisation de Cholesky à partir de la base pour voir à quoi ressemble la structure d'une factorisation de cholesky d'une matrice de flèches de matrices de flèches. https://gist.github.com/mschauer/c325ff89cd378fe7ecd6 ("A" Arrow matrix, "F" full matrix, "L" Lower half arrow").

@ScottPJones merci !!

Soutenance prévue : mercredi 13 mai, 13h Stata D-463.

@JeffBezanson prévoyez -vous de l'enregistrer via replay.csail.mit.edu ?

... peut-être que je préfère l'oublier... :)

N'est-ce pas à cela que sert la dernière case à cocher ?

Êtes-vous _vraiment_ sûr de devoir donner l'adresse ? Vous pourriez être assailli par des fans qui veulent des copies signées de votre thèse ! :sourire:

J'ai déjà mes billets. J'entends dire que le prix est déjà à 800 $ sur le marché noir.

Stata D-463 n'était pas là à mon époque... (Je n'y suis allé que pour rendre visite à des amis et pour le NE Database Day)... Est-ce que ça va être assez grand ? Il va sûrement en avoir besoin de 10-250 !

Officiellement, D-463 convient à 48 chaises. Si nous pensons que cela ne suffira pas, nous pouvons envisager d'obtenir une salle plus grande.

Je ne pense vraiment pas que tu apprécies vraiment ce que tu as fait ! Si tous vos fans se présentaient, peut-être que 10 à 250 ne seraient pas assez nombreux... réservez Kresge maintenant !

L'abstraction en informatique technique

• Candidat au doctorat : Jeff Bezanson
• Directeur de thèse : Prof. Alan Edelman
• Comité de thèse : Prof. Steven Johnson, Prof. Saman Amarasinghe, Prof. Gerry Sussman
• Date : mercredi 13 mai 2015
• Heure : 13 h 00
• Emplacement : campus du MIT, 32-D463

_Les environnements de programmation basés sur des tableaux sont populaires pour le calcul scientifique et technique. Ces systèmes se composent de bibliothèques de fonctions intégrées associées à des langages de haut niveau pour l'interaction. Bien que les bibliothèques fonctionnent bien, il est largement admis que les scripts dans ces langages sont nécessairement lents et que seuls des exploits héroïques d'ingénierie peuvent, au mieux, résoudre partiellement ce problème._

_Cette thèse soutient que ce qui est vraiment nécessaire est une structure plus cohérente pour cette fonctionnalité. Pour en trouver un, il faut se demander ce qu'est réellement l'informatique technique. Cette thèse suggère que ce type de programmation se caractérise par l'accent mis sur la complexité des opérateurs et la spécialisation du code, et qu'un langage peut être conçu pour mieux répondre à ces exigences._

_L'idée clé est d'intégrer le code_ _selection _ _avec le code_ _specialization _, _en utilisant des fonctions génériques et l'inférence de type de flux de données. Des systèmes comme ceux-ci peuvent souffrir d'une compilation inefficace ou d'une incertitude quant à ce sur quoi se spécialiser. Nous montrons qu'une distribution basée sur les types suffisamment puissante résout ces problèmes. Le langage résultant, Julia, réalise une « explication par élimination » à la Quine de bon nombre des fonctionnalités productives attendues par les utilisateurs de l'informatique technique._

Y aura-t-il des copies imprimées de sa thèse disponibles pour les spectateurs ?

Peut-être des copies signées

C'est ce que j'espère... Je pense que je peux gagner beaucoup d'argent sur Ebay en vendant une copie dédicacée dans 10 à 15 ans (quand j'en aurai vraiment besoin pour payer les études universitaires de mes enfants... en particulier. s'ils vont là où ils ont dit vouloir aller... :grinning: )

Bonne chance, Jeff !

Bonne chance! Si j'étais dans le coin, je serais l'un des fanboys mentionnés par @ScottPJones

@ScottPJones :+1 :

Casse-toi une jambe, Jeff !

Bonne chance, Jeff !

Bonne chance! @JeffBezanson

@JeffBezanson Bonne chance !!

J'espère que je pourrai avoir une place.

Bonne chance

Je lui ai dit qu'il aurait dû réserver 10-250 !

Envoyé de mon iPhone

Le 13 mai 2015, à 11h53, Yichao Yu [email protected] a écrit :

@JeffBezanson Bonne chance !!

J'espère que je pourrai avoir une place.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Bonne chance!

Idem!

Heureusement, je suis arrivé assez tôt pour avoir une place... et j'avais raison (comme d'habitude :sourire:) il aurait vraiment dû réserver une chambre plus grande !

Toutes nos félicitations

Fixé.

Il reste encore une case décochée. Mieux vaut travailler.

:shipit: :tropical_drink: :beers: :cocktail: :tada: !

:pouces vers le haut:

Félicitations, Dr Bezanson !

Félicitations Jeff !

+1

Bravo

la dernière case à cocher a été remplie maintenant avec un Kentucky Bourbon Whiskey.

Félicitations Jeff!

Le mercredi 13 mai 2015 à 13h44, Mike Nolta [email protected]
a écrit:

+1

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -101772806.

Toutes nos félicitations!

Félicitations Jeff! :bières: :bières: :sourire:

C'est merveilleux ! Félicitations, Jef. :les feux d'artifices:

Bonne nouvelle. Félicitations Jeff!

Toutes nos félicitations!

félicitations

Woop woop bravo Jeff !

Félicitations, Dr Bezanson !

Merci d'avoir posté la photo, @ScottPJones. @jiahao , je pense que tu as aussi des photos ?

Félicitations Jef. Votre travail qui s'est terminé par ce doctorat a influencé beaucoup d'entre nous. Il aura et a déjà un énorme impact sur le calcul scientifique ! Rock On!

toutes nos félicitations.

Génial!

Félicitations Jef !!

Fantastique, félicitations !!

Félicitations Dr Bezanson !

La thèse, pour ceux qui voudraient y jeter un œil :

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

Félicitations!

Toutes nos félicitations!

Toutes nos félicitations!

Félicitations :+1:

Je ne sais pas pourquoi GitHub a décidé de faire pivoter toutes mes photos, mais les voici.

Vidéo de la cérémonie de clôture du numéro : http://youtu.be/hGpLOZX6CEY

Félicitations Aleph-zéro à toi, Jeff! Si jamais tu passes à Seattle, laisse-moi t'offrir un verre de félicitations. :)

Félicitations Jeff. C'est très agréable de célébrer votre travail en tant que communauté.

Toutes nos félicitations!

@jiahao , cela vaut peut-être la peine de relancer le dernier monde de Julia en tant que matériel supplémentaire pour la page de remerciements :)

Merci tout le monde.

Malheureusement, ma thèse n'est pas encore terminée, mais j'espère qu'elle le sera bientôt...

J'ai encore quelques photos, je les enverrai à Jeff après mon réveil (pour sa mère, une très gentille dame !) _Dr._ Bezanson peut les poster ici s'il le souhaite...

Pas fini??? Gerry vous a-t-il demandé de supprimer toute cette foutue "syntaxe" et de le laisser écrire avec des expressions s ?

@JeffBezanson utilisant un mac n'est pas une image que je m'attendais à voir !

Yay!

Toutes nos félicitations

Bravo à tous vos fans de ce côté de l'étang.

Pas fini??? Gerry vous a-t-il demandé de supprimer toute cette foutue "syntaxe" et de le laisser écrire avec des expressions s ?

Vous avez réussi! Je ne plaisante pas. Mais il faudra se contenter d'un mode s-expr optionnel.

Je lui avais parlé après la présentation... il aimait vos trucs, mais ne se souciait vraiment pas de toute la syntaxe... il y en a juste _tellement_... il m'a rappelé à quel point le manuel Scheme est petit :grinning: Quand je l'ai eu pour 6.001 [premier semestre, il a été enseigné], nous avons dû implémenter un petit interpréteur Scheme dans MacLisp... puisque Scheme était si petit, c'était assez faisable...

et je suis sûr que vous pouvez assommer ça assez rapidement, avec cette bouteille de bourbon pour compagnie (s'il en reste ! ;-) )

En parlant de la longueur du manuel du schéma, c'est amusant : un grand pourcentage de celui-ci est consacré à documenter le comportement des nombres, alors que chez Julia, c'est défini dans les bibliothèques. Julia pourrait potentiellement être un langage de base plus petit que le schéma (à moins bien sûr que vous n'y ayez agrafé la spécification LLVM).

Pour ou contre, on met trop l'accent sur la syntaxe ! Consultez également la section 7.1 de http://www.schemers.org/Documents/Standards/R5RS/HTML/. La syntaxe des schémas est plus complexe que les gens ne le pensent !

Julia pourrait potentiellement être un langage de base plus petit que le schéma (à moins bien sûr que vous n'y ayez agrafé la spécification LLVM).

Oui, Julia a de bons os !

Il est temps de déterrer l'ancienne macro @sexpr ?

Félicitations pour ton diplôme et pour ce que tu as fait avec Julia !

:gâteau: Félicitations !

Félicitations @JeffBezanson !

toutes nos félicitations :)

:+1:

@boyers ! Ça fait longtemps!

vous me manquez :)

Toutes nos félicitations!

Juste une question : le PDF n'a pas de liens dans la table des matières ni d'index navigable dans les métadonnées du pdf.
Pourquoi est-il si difficile pour un compilateur-écrivain diplômé du MIT d'ajouter \usepackage{hyperref} dans son préambule ?

C'est parce que vous êtes censé lire le tout et pas simplement sauter. ;-)

Mais oui, hyperref rendrait cela beaucoup plus accessible.

Je vous promets de tout lire si vous rajoutez les liens :P

Toutes nos félicitations. La liberté attend.

Félicitations, Dr Bezanson !

@nicola-gigante, tu peux faire une pull request : smile:.

pouvons-nous faire pression pour un prix de la meilleure thèse ?

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

Félicitation !!!

@jpfairbanks - bonne idée ! Il doit être soumis par son directeur de thèse cependant... harceler Alan Edelman, je pense...

Oui, il faut une nomination par le conseiller et 5 lettres de soutien. Basé sur
cette question, je pense qu'au moins 5 personnes pensent qu'il le mérite.

Est-ce limité à 5 lettres de soutien ? De plus, le nombre réel de personnes qui pensent qu'il le mérite est au moins supérieur de quelques ordres de grandeur !

@JeffBezanson : Félicitations !

@alanedelman : Je pense que @jpfairbanks a raison, Jeff devrait être nominé pour le prix de thèse de doctorat de l'ACM .

@JeffBezanson Bravo et bien mérité !

@ScottPJones "De plus, au moins 3 et pas plus de 5 lettres de soutien doivent être incluses par des experts dans le domaine qui peuvent fournir des informations supplémentaires ou des preuves de l'impact de la thèse."

Peut-être que Gerry lui en écrira un (après avoir ajouté le mode s-expr !) :grinning:

Première page de Hacker News :-) Félicitations, Jeff.

@nicola-gigante Vous avez raison, je vais ajouter hyperref.

Merci encore à tous. Toute votre appréciation est le prix ultime.

@jiahao C'est parce qu'ils ont des données de rotation EXIF ​​dont les navigateurs ne se soucient pas. Le plus souvent. Chrome ne se soucie des données EXIF ​​​​que si l'image est sa propre fenêtre. Faites un clic droit et "Ouvrir dans un nouvel onglet" pour les voir dans la bonne orientation.

Vous pouvez utiliser un décapant de métadonnées EXIF ​​​​pour les supprimer et les faire pivoter de la manière "appropriée".

+1 pour la nomination au prix de thèse ACM.

La date limite de nomination est le 31 octobre 2015.

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

Je n'aime pas qu'ACM leur demande un transfert de droits d'auteur et des droits de publication exclusifs. Il est toujours précieux et prestigieux en tout cas.

Félicitations!

Droits de publication exclusifs !?! J'ai des dibs sur une copie dédicacée (ou deux... j'en ai besoin d'une pour vendre sur e-bay dans 10-15 ans, une autre à garder pour moi : souriant :)... je dois l'obtenir avant qu'elle ne soit verrouillée par l'ACM !
(Bien sûr, cela signifie probablement qu'il serait disponible sur la bibliothèque numérique de l'ACM pour les membres)

une fois que la thèse m'est remise à signer, j'ai bien l'intention
de nominer la thèse pour divers prix :-)

Le dimanche 17 mai 2015 à 8h49, Scott P. Jones [email protected]
a écrit:

Droits de publication exclusifs !?! J'ai des dibs sur une copie dédicacée (ou
deux... j'en ai besoin d'un à vendre sur e-bay dans 10-15 ans, un autre à garder pour moi [image :
:grinning:])... je dois le récupérer avant qu'il ne soit verrouillé par l'ACM !
(Bien sûr, cela signifie probablement qu'il serait disponible sur l'ACM
bibliothèque numérique pour les membres)

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -102801616.

Pas de commentaires de @JeffBezanson... J'espère qu'il fête (plus en cochant sa dernière case) et qu'il n'a pas été enfermé dans une pièce quelque part par GJS jusqu'à ce qu'il fasse fonctionner le mode s-expr !

Toutes nos félicitations!

Félicitations, @JeffBezanson !

(en retard) Félicitations !

Mise à jour : je viens de soumettre le document. La version soumise est https://github.com/JeffBezanson/phdthesis/tree/876be73a5aab9b034fac3eb9ea9d8f96713f786f .

Je suis sûr qu'il est déficient à bien des égards. Tant pis. J'espère qu'il n'y a rien de vraiment mauvais là-dedans.

Agréable. Félicitations pour avoir vraiment terminé votre doctorat.

Félicitations Jeff! Grande réalisation. Je suis sûr que tu es content que ce soit fini.

J'ai déjà trouvé que votre thèse comble certains trous dans la documentation de Julia, donc ça va clairement être très utile. Tous les documents ont des défauts ; le reste d'entre nous est impressionné par les points forts ! Félicitations!

Et merci de le partager !

Ouf ! Félicitations pour avoir terminé la soutenance et la thèse, et tous les autres travaux qu'ils signifient et représentent. C'est agréable d'avoir ce jalon pour reconnaître toutes les choses que vous avez accomplies. J'espère que tu es fier !

@JeffBezanson J'espère que vous prévoyez de prendre quelques jours de congé pour vous détendre et célébrer, ou peut-être que vous prévoyez de célébrer avec une refonte du système de type ou quelque chose du genre. :-)

Bien que le nouveau pdf ait hyperref - pour ceux qui veulent naviguer. Nous devrions également le mettre sur la liste des publications de Julia.