Julia: Jeff Bezanson PhD

cc @fperez que también está interesado en este tema pendiente

Se adjunta información de apoyo.

Como cuestión de procedimiento, cerrar esto podría requerir trabajar en un repositorio separado. La tesis tal vez debería incluirse en Base para que sea más fácil para otros contribuir.

Además, el orden de la última tarea es engañoso; en realidad se repetirá con frecuencia a lo largo del proceso.

+1 por incluirlo en Base, o al menos en julia/doc/thesis . O tal vez theses para cubrir necesidades futuras.

(Adelante, abre una sucursal de tesis, Jeff).

Además, el orden de la última tarea es engañoso; en realidad se repetirá con frecuencia a lo largo del proceso.

*también ya se ha repetido

Tengo muchas ganas de estar presente en la ceremonia de _Cerrar problema_.

No puedo reproducir este problema localmente; ¿Es específico del MIT?

Uno de los principales autores de Julia, @JeffBezanson , se ha convertido en un desarrollador académico problemático.

¿Es esta la versión github de una tesis doctoral? Jeff tiene que abrir un PR con su propuesta y el comité decidirá si fusionarse o no...

+Inf para resolución rápida de este!

Tuve el mismo problema en el repositorio de IPython hace unos meses, con suerte se solucionó hace 32 días.
Estoy bastante seguro de que involucró café, papeleo molesto y un cambio de planes de última hora debido a los martillos neumáticos.

Buena suerte !

Actualizado: Jeff se reunió con su comité de tesis y nos dio un resumen general.

¡Me alegra saber que se está progresando!

Pero git log --date=short --all --since=22.days.ago --author="Jeff Bezanson" todavía hace que uno se pregunte cómo tiene tiempo para escribir una tesis. O eso, o es un superhéroe. En realidad, borra eso: todos sabemos que él _es_ un superhéroe, así que no importa.

Los compromisos relacionados con juliatypes.jl registran nuestros intentos de describir el sistema de tipos de Julia, que es un trabajo de tesis directamente relevante.

El trabajo del sistema de tipos parece que ya está afectando algunos nervios: https://twitter.com/plt_hulk/status/535045242920378369

Dudo que sea una respuesta directa al trabajo de Jeff, aunque podría estar equivocado. Sin embargo, un tweet hilarante de cualquier manera.

@jiahao , mi comentario fue en su mayoría irónico; me preguntaba algo sobre eso mismo. Yo, por mi parte, tiendo a tener muchos compromisos cuando estoy puliendo algo para la presentación.

señaló el humor de @timholy . :)

Sería negligente no mencionar el encantador homenaje a Magritte que nuestro colaborador teórico local @jeanqasaur hizo y publicó en Twitter :

"La traición de los tipos" suena bien, ¿no?

Eso es bastante divertido.

¡Me encanta!

Llame para pedir ayuda: Jeff está buscando buenos ejemplos que muestren múltiples envíos (y tal vez funciones por etapas), cosas que serían mucho más difíciles o más lentas en idiomas sin esas características.

es, show ?

(y tal vez funciones escenificadas)

subarray.jl y subarray2.jl deberían servir bastante bien. El documento de diseño está en http://docs.julialang.org/en/latest/devdocs/subarrays/

Creo que el paquete de distribuciones realmente hace que el envío múltiple parezca útil. Tener cosas como rand(Gamma(1, 1), 5, 5) frente a rand(Normal(0, 1), 3) es una gran ganancia en expresividad sin costo de rendimiento debido al envío múltiple.

No veo cómo ese es el mejor ejemplo, ya que realmente está mostrando
envío único. ¿En qué se diferencia de Gamma(1,1).rand(5,5) que
haría en un lenguaje OO más tradicional como Python o Java?

El viernes 19 de diciembre de 2014 a la 1:39 p. m., John Myles White [email protected]
escribió:

Creo que el paquete de distribuciones realmente hace que parezca que el envío múltiple
útil. Tener cosas como rand(Gamma(1, 1), 5, 5) vs rand(Normal(0, 1),
3) es una gran ganancia en expresividad sin costo de rendimiento debido a
despacho múltiple.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67678367.

Está bien. Reemplace eso con ejemplos de cálculo de divergencias KL usando resultados analíticos: kl(Normal(0, 1), Normal(0, 1)) vs kl(Normal(0, 1), Gamma(1, 1)) .

También debería haber agregado, había algunas estadísticas potencialmente útiles sobre cómo habría sido la vida _sin_ funciones escenificadas en mi publicación inicial en #8235. El mensaje final: generar todos los métodos a través de la dimensión 8 dio como resultado> 5000 métodos separados y requirió más de 4 minutos de tiempo de análisis y reducción (es decir, un retraso de 4 minutos mientras se compilaba julia). En comparación, la implementación de la función por etapas se carga en un instante y, por supuesto, puede ir incluso más allá de 8 dimensiones.

Vs single-dispatch, todavía demuestra la unificación de lo que otros lenguajes OO describen como: funciones vs métodos. Podría contrastar con python's sorted(a) vs a.sort(). En comparación con los lenguajes OO "tradicionales", cambia drásticamente lo que significa que una función esté "asociada con" una clase.

Podría señalar cómo reemplaza la necesidad de variables estáticas frente a instancias, ya que puede despachar en la instancia o el tipo. Podría tener algunas ideas más de algunas conversaciones recientes de IRC, cuando pueda acceder a una computadora.

Tengo una implementación de fmap . Esto atraviesa varias matrices y
aplica una función a cada conjunto de elementos. Esta implementación es en realidad
muy lento ya que el número de matrices puede ser arbitrario. Para hacer esto útil,
He creado manualmente la especialización de esto para varios números de
argumentos yss . Siempre quise escribir una función escenificada para esto,
pero no lo ha hecho todavía.

La función por etapas necesitaría evaluar en particular la llamada map
que produce los argumentos para 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

El viernes, 19 de diciembre de 2014 a las 12:46 p. m., Steven G. Johnson <
[email protected]> escribió:

Llame para pedir ayuda: Jeff está buscando buenos ejemplos que muestren múltiples
despacho (y tal vez funciones escenificadas), cosas que serían mucho
más difícil/más lento en idiomas sin esas características.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

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

Lo siento, ignore la llamada a eltype(f) en la firma de la función en mi código,
eso no es estándar.

-erik

El viernes 19 de diciembre de 2014 a las 15:08, Erik Schnetter [email protected]
escribió:

Tengo una implementación de fmap . Esto atraviesa varias matrices y
aplica una función a cada conjunto de elementos. Esta implementación es en realidad
muy lento ya que el número de matrices puede ser arbitrario. Para hacer esto útil,
He creado manualmente la especialización de esto para varios números de
argumentos yss . Siempre quise escribir una función escenificada para esto,
pero no lo ha hecho todavía.

La función por etapas necesitaría evaluar en particular la llamada map
que produce los argumentos para 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

El viernes, 19 de diciembre de 2014 a las 12:46 p. m., Steven G. Johnson <
[email protected]> escribió:

Llame para pedir ayuda: Jeff está buscando buenos ejemplos que muestren múltiples
despacho (y tal vez funciones escenificadas), cosas que serían mucho
más difícil/más lento en idiomas sin esas características.

Responda a este correo electrónico directamente o véalo en 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 , dado que Matlab y NumPy también tienen subarrays/slices, ¿por qué podemos argumentar que el envío múltiple es esencial aquí?

¿Facilidad de implementación? Por lo que puedo decir, puede simular envíos múltiples en cualquier idioma, por lo que no es esencial para nada.

Tal vez no sea bueno sugerir algo que aún no hemos decidido que queremos. En https://github.com/JuliaLang/julia/issues/9297 , hay una propuesta que nos permite tener posiciones de búfer UTF-8 eficientes y una indexación conveniente sin agujeros para que pueda hacer aritmética conveniente cuando lo desee. Regex y la búsqueda devolverán el índice interno envuelto, pero s[2] puede dar el segundo carácter independientemente de cuántos bytes se usaron para codificar el primero.

¿Pueden hacer subarrays/segmentos eficientes de AbstractArrays , o su implementación solo funciona para bloques de memoria contiguos? Este no es un problema terriblemente difícil de resolver si puede asumir que su matriz principal tiene memoria contigua; se vuelve más interesante cuando no haces esa suposición.

Sí, esa es la función clave que estamos buscando: no solo que algo se pueda hacer bien con múltiples funciones de despacho y/o etapas, sino que la falta de estas funciones en otros lenguajes hizo que la implementación de la función fuera mucho más difícil (idealmente, tanto más difícil que nadie lo haya intentado).

@timholy , una matriz NumPy se caracteriza por un paso fijo para cada dimensión, no necesariamente contigüidad (esencialmente equivalente a nuestro DenseArray ). Esta propiedad se conserva con el corte, por lo que los propios cortes se pueden cortar, etcétera.

aberrant tenía algunas buenas preguntas en IRC en este sentido. Intenté extraer solo los fragmentos de comentarios relevantes (de entre las conversaciones y notificaciones no relacionadas) a continuación:

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 está buscando más ejemplos: https://github.com/JuliaLang/julia/pull/7291

La reducción de código neto es agradable de 6K C++ a alrededor de 1K Julia. Los puntos de referencia de rendimiento iniciales muestran que es casi el doble del C++ nativo.

¿Cuántos idiomas conoce que puedan reclamar la implementación de printf, desde los operadores (+-*/, Int, Float) hasta el formato de salida numérica, en el idioma mismo y el punto de referencia dentro de un pequeño margen de las versiones libc? ¿Quizás C++? C ni siquiera puede reclamar esto (no tiene sobrecarga de operadores).

Python/MATLAB/etc. podría reclamar bits de esto, pero ¿alguna vez ha intentado usar los operadores de cadenas en MATLAB?

Esta es una discusión muy interesante y me gustaría agregar algunos puntos:

• Lo que parece no estar realmente respondido es cómo Julia se compara con el polimorfismo en C ++ a la velocidad. En C++ uno puede tener polimorfismo estático a través de plantillas o polimorfismo dinámico a través de OO. Pero el último requiere una vtable y siempre es un poco más lento, especialmente cuando se llama a este tipo de cosas en un ciclo cerrado. Por esta razón, nunca se sobrecargaría el operador de acceso a la matriz, ya que no sería rápido. Eigen, por ejemplo, utiliza polimorfismo estático.
• En Julia no hay destino entre una función virtual y una no virtual y aún no tenemos penalizaciones de rendimiento. Tengo entendido que la gran ventaja es que Julia puede generar código "sobre la marcha" y, por lo tanto, generar código rápido donde en el tiempo de ejecución de C ++ significa que ya no se puede modificar el código generado. Además, en Julia podemos hacer inline en tiempo de ejecución. Así que no hay sobrecarga de llamada de función. Y en Julia no tenemos que pensar en todo esto porque se hace automáticamente
• Una gran cosa (nuevamente) es: genéricos sin sobrecarga y sin todo el dolor que tiene C ++ (buscando tiempos de compilación) Hay diferentes métodos para implementar genéricos y en mi humilde opinión, Julia usa el mismo modelo que C #, por lo que esto podría no ser completamente nuevo (para tesis de Jeff). Pero aún así creo que esto podría ser algo para discutir en la tesis.

Lo difícil que es explicar cuán efectivo es el envío múltiple es bastante interesante.

Me alegro de que ahora estemos en la misma página. Sí, nuestros nuevos SubArrays no se basan en tener avances, ni requieren indexación lineal (aunque pueden usarlo y lo hacen de manera predeterminada si resulta ser eficiente). Por lo tanto, funcionan de manera eficiente para cualquier AbstractArray y también admiten vistas "sin estrías" (índices Vector{Int} ).

Para aclarar, presenté nuestros nuevos SubArrays principalmente como un ejemplo de funciones por etapas, no de distribución múltiple. Dicho esto, el esquema actual se desmoronaría en el paso de construcción sin envío múltiple: llamamos a métodos constructores completamente diferentes para slice(::AbstractArray, ::UnitRange{Int}, ::Int, ::Vector{Int}) y slice(::AbstractArray, ::Int, ::UnitRange{Int}, ::UnitRange{Int}) , etc. Esos constructores son generados por funciones por etapas, pero necesita despacho múltiple para que el sistema funcione.

Sin funciones separadas, un constructor de varargs tiene que enfrentar el hecho de que recorrer las entradas en la tupla de índices no es de tipo estable: para procesar índices individuales en un ciclo, debe asignarlos a una variable escalar con nombre, y esa variable es garantizado que no esté bien tipado aunque la tupla de entrada pueda estarlo. Por supuesto, la función por etapas hace mucho más: casi todas las decisiones "difíciles": ¿estamos eliminando esto como una dimensión dividida o manteniéndolo, y cuáles son las consecuencias para la representación interna del objeto? ---puede hacerse en tiempo de compilación, reduciendo el constructor de tiempo de ejecución a una operación notablemente trivial. Da la casualidad de que la operación trivial particular es diferente para cada combinación de tipos de entrada, por lo que para explotar esta trivialidad y hacer que la construcción sea rápida, debe llamar a diferentes métodos personalizados para cada combinación de tipos de entrada. Esta es la razón por la que necesita tanto funciones por etapas como envíos múltiples.

Personalmente, dudo que sea posible hacer lo que hemos hecho sin la combinación de funciones por etapas y despacho múltiple, y es probable que julia ahora tenga las vistas de matriz más flexibles y eficientes de cualquier idioma. Pero no pretendo haber emprendido ningún tipo de estudio real de este problema.

Esto hace que me pregunte si debería escribir nuestros SubArrays para su publicación --- parece que tenemos algo nuevo aquí.

@StefanKarpinski : Seamos autocríticos: ¿Quizás simplemente no lo hemos escrito todavía?

@timholy De hecho, veo dos cosas aquí, las funciones por etapas (que debo admitir que no se entienden completamente) y cómo Julia encaja en el universo de funciones virtuales frente a plantillas de C ++ (C # y Java son similares aquí).

Para la comparación de C++, sería muy interesante hacer tiempos y pruebas experimentales de que podemos alcanzar el polimorfismo en tiempo de compilación (que estoy seguro de que lo hacemos)

Otra cosa que quería formular desde hace algún tiempo es cómo Julia se compara con C++ con respecto a C++ Concepts (lite). La subtipificación que tenemos es una gran parte de los conceptos de C++.

¿Es necesario escribir un montón de código C ++ y ejecutar tiempos para verificar esto?

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

Básicamente, no hay nada más que operaciones de carga y almacenamiento (es decir, acceso a la memoria) allí.

@timholy Creo que vale la pena escribir esto. Creo (pero no lo he verificado) que muchos sistemas que implementan arreglos Nd tienen implementaciones especializadas para las primeras dimensiones y, de lo contrario, generalmente vuelven a algo lento, y ese no debería ser el caso para la nueva implementación.

Otro caso relacionado es escribir un almacén Nd disperso eficiente (las matrices son el caso especial común).

timo,

sí, de hecho, mirar el código ensamblador resultante es una gran herramienta. Pero aún creo que esto debe compararse en un contexto más amplio, donde (en la implementación de C ++) las funciones virtuales deberían tenerse en cuenta.

Supongo que realmente no es multiple dispatch lo que es tan rápido, sino que podemos en línea en tiempo de ejecución y, por lo tanto, transformar la función virtual (que son nuestras funciones genéricas) en instrucción eficiente sin indirección de llamada de función.

Si esto es cierto (por favor, corríjame si me equivoco @JeffBezanson @vtjnash @stevengj @timholy ) el múltiplo en multiple dispatch no es la razón por la que Julia es tan rápida, sino un lado claro que afecta que se puede formular cierto código más agradable (donde el envío único es limitante)

Probablemente no estoy entendiendo, pero no estoy seguro de la distinción que estás haciendo. En Julia, "en línea" y "tiempo de ejecución" realmente no parecen ir juntos; la inserción se realiza durante la inferencia de tipo, es decir, en tiempo de compilación. El envío múltiple se utiliza para seleccionar el método apropiado para los tipos inferidos.

La confusión aquí es que el "tiempo de compilación" y el "tiempo de ejecución" de C++ no se pueden comparar con los de Julia. Codegen puede ocurrir durante el "tiempo de ejecución", así que sí, creo que cuando hago include("myscript.jl") se realiza la inserción. E incluso si "tiempo de ejecución" no es la palabra adecuada desde la perspectiva de C++, es "tiempo de ejecución".

Y el despacho en diferentes tipos es como un vtable pero más general, ¿no?

Esto hace que me pregunte si debería escribir nuestros SubArrays para su publicación --- parece que tenemos algo nuevo aquí.

Está un poco lejos de los temas estándar, pero podría considerar enviarlo a JSS. Necesitamos más artículos de Julia.

Me encantaría que Tim escribiera una publicación de blog para describir este trabajo, ya que pondrá a mucha gente al día. JSS es una gran idea, y quizás también valga la pena escribir parte del trabajo fundamental que se ha realizado en marcos de datos y distribuciones. Sin duda disfrutaría leyéndolo.

Bueno, lo que me hizo pensar en esto es que gran parte se ha escrito: http://docs.julialang.org/en/latest/devdocs/subarrays/. Para una publicación, le gustaría entrar en muchos más detalles, pero esto toca una buena cantidad de los puntos principales del panorama general.

A la pregunta que planteó @stevengj sobre el envío múltiple, diría que sin el envío múltiple, es bastante difícil escribir nuestra biblioteca base en julia. Estoy diciendo lo que ya saben todos aquí, y me pregunto si este no es un ejemplo convincente por las razones planteadas aquí.

Detalles como las operaciones con números y la conversión/promoción están íntimamente ligados al envío múltiple. Dado que el envío múltiple es lo que esencialmente expone la inferencia de tipos en el compilador a la forma en que se usan los tipos en el código, podemos escribir una biblioteca de base numérica genérica y rápida. Para citar una declaración que hizo, ayuda a separar la creación de políticas del compilador y en las bibliotecas. Por ejemplo, @JeffBezanson me mostró una vez cómo la especificación Scheme gasta 1/3 de su espacio en detalles numéricos.

Muchos sistemas interpretados a menudo terminan teniendo tipos generales e inspeccionando los tipos de sus objetos en tiempo de ejecución para tomar decisiones sobre qué código ejecutar. A menudo tienen una implementación separada en C/C++/Fortran en la biblioteca base para cada tipo, lo que lleva a una base de código grande y difícil de depurar. A menudo, estos se generan a través de un sistema de macros externo, pero cada vez más el uso de plantillas de C++ ha evitado este problema específico. La cuestión de los dos idiomas y la inferencia de tipos aún permanece en estos casos.

En algún nivel, la vectorización es la forma en que muchos lenguajes científicos amortizan el costo de determinar los tipos en tiempo de ejecución y realizar la selección de código adecuada. En Julia, con la combinación de inferencia de tipos, despacho múltiple y programación genérica, nuestros costos para ambos son significativamente más bajos, lo que nos permite escribir código desvectorizado genérico: C sin tipos.

Un ejemplo es la comparación de desigualdad con MathConst (representando números irracionales) en PR #9198:

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

• FloatingPoint vs MathConst compara el flotante con el flotante arriba/abajo de la constante
• Rational{T} vs MathConst (para tipos enteros acotados T ) encuentra el racional representable más cercano por el tipo; luego en función de si está por encima o por debajo del verdadero tipo irracional.

Lo que hace que esto sea factible es el fácil acceso a la funcionalidad Rational y BigFloat en tiempo de compilación. Aunque podría ser posible usar algo como un preprocesador de macros, requeriría esencialmente dos implementaciones de toda la funcionalidad.

Tengo una pequeña actualización sobre este tema. El documento ahora está abierto al público: https://github.com/JeffBezanson/phdthesis

Hoy estoy lanzando una especie de borrador por fecha límite autoimpuesta. No es mucho de un borrador; faltan muchas piezas por completo. Tampoco me responsabilizo por nada que esté dentro de los comentarios de TeX, o presente solo en el historial de versiones anteriores :)

¡Todos los comentarios son bienvenidos! En particular, si tiene buenos ejemplos de código julia que muestren bien el lenguaje, especialmente cualquier cosa que sea difícil de hacer sin él. Siempre buscando buenos ejemplos de despacho múltiple no triviales.

Gracias por hacer esto público. Me sorprendí cuando traté de seguir un enlace que usó SGJ y pulsé un 404.

Quizás la aritmética de matrices triangulares podría ser un ejemplo de la utilidad del despacho múltiple de Julia. Aquí UpperTriangular+UpperTriangular=UpperTriangular , pero UpperTriangular+LowerTriangular=Matrix .

También hablamos sobre la promoción de los tipos de elementos. Me gusta que puedes evitar la promoción cuando no es necesaria, por ejemplo.

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

No puedo decir qué tan específico es esto para Julia, pero como vimos, parece que al menos Eigen no administrará la promoción, pero requerirá que los tipos de elementos sean estables bajo la operación de álgebra lineal.

Jeff está entrando en la recta final ahora, esperamos, por lo que los comentarios y las correcciones a su tesis (consulte el repositorio de github mencionado anteriormente) serían especialmente bienvenidos ahora.

Siéntase libre de enviar PRs para errores tipográficos, referencias faltantes, etc.

@stevengj ¿Deberíamos esperar un anuncio del cronograma de defensa aquí?

Si.

Espero que ya tenga un trabajo en el MIT... (o en cualquier lugar donde continúe con el gran trabajo de Julia)... leyendo su tesis ahora... ¡buen material, en mi opinión!

@andreasnoack Un poco esotérico, pero de todos modos divertido: defina un tipo de anillo de matriz de flecha y aplique la factorización de Cholesky desde la base para ver cómo se ve la estructura de una factorización de Cholesky de una matriz de flecha de matrices de flecha. https://gist.github.com/mschauer/c325ff89cd378fe7ecd6 ("A" Matriz de flecha, "F" matriz completa, "L" Media flecha inferior").

@ScottPJones gracias!!

Defensa programada: miércoles 13 de mayo, 1 p. m. Stata D-463.

@JeffBezanson , ¿planea grabarlo a través de replay.csail.mit.edu?

...tal vez prefiero olvidarlo... :)

¿No es para eso para lo que sirve la última casilla de verificación?

¿Estás _realmente_ seguro de que deberías dar la dirección? ¡Es posible que te acosen los fanáticos que quieren copias firmadas de tu tesis! :sonriendo:

Ya tengo mis boletos. Escuché que el precio ya es de $800 en el mercado negro.

Stata D-463 no estaba allí en mi día... (Solo he estado allí para visitar amigos y para el Día de la base de datos NE)... ¿Será lo suficientemente grande? ¡Seguro que va a necesitar 10-250!

Oficialmente D-463 se adapta a 48 sillas. Si creemos que eso no será suficiente, podemos buscar una habitación más grande.

¡En serio, no creo que realmente aprecies lo que has hecho! Si todos tus fans vinieran, tal vez 10-250 no serían lo suficientemente grandes... ¡Reserva Kresge ahora!

Abstracción en Informática Técnica

• Candidato a doctorado: Jeff Bezanson
• Supervisor de tesis: Prof. Alan Edelman
• Comité de tesis: Prof. Steven Johnson, Prof. Saman Amarasinghe, Prof. Gerry Sussman
• Fecha: miércoles 13 de mayo de 2015
• Hora: 13:00
• Ubicación: campus del MIT, 32-D463

_Los entornos de programación basados ​​en matrices son populares para la computación científica y técnica. Estos sistemas consisten en bibliotecas de funciones integradas combinadas con lenguajes de alto nivel para la interacción. Aunque las bibliotecas funcionan bien, se cree ampliamente que la creación de scripts en estos lenguajes es necesariamente lenta y que solo las proezas heroicas de la ingeniería pueden, en el mejor de los casos, mejorar parcialmente este problema._

_Esta tesis argumenta que lo que realmente se necesita es una estructura más coherente para esta funcionalidad. Para encontrar uno, debemos preguntarnos de qué se trata realmente la informática técnica. Esta tesis sugiere que este tipo de programación se caracteriza por un énfasis en la complejidad del operador y la especialización del código, y que se puede diseñar un lenguaje que se ajuste mejor a estos requisitos._

_La idea clave es integrar código_ _selección_ _con código_ _especialización_ , _usando funciones genéricas e inferencia de tipo flujo de datos. Los sistemas como estos pueden sufrir una compilación ineficiente o incertidumbre sobre en qué especializarse. Mostramos que el envío basado en tipos suficientemente potente aborda estos problemas. El lenguaje resultante, Julia, logra una "explicación por eliminación" al estilo de Quine de muchas de las características productivas que esperan los usuarios de computación técnica._

¿Habrá copias impresas de su tesis disponibles para los espectadores?

Tal vez copias firmadas

Eso es lo que espero... Me imagino que puedo conseguir mucho dinero en Ebay vendiendo una copia autografiada en 10-15 años (cuando realmente lo necesitaré para pagar la educación universitaria de mis hijos... especialmente. si van a donde han dicho que quieren ir... :sonriendo: )

¡Buena suerte, Jeff!

¡Buena suerte! Si estuviera en el área sería uno de los fanboys que menciona @ScottPJones

@ScottPJones :+1:

¡Rompe una pierna, Jeff!

¡Buena suerte, Jeff!

¡Buena suerte! @JeffBezanson

@JeffBezanson ¡Buena suerte!

Ojalá pueda conseguir un asiento.

buena suerte

¡Le dije que debería haber reservado 10-250!

Enviado desde mi iPhone

El 13 de mayo de 2015, a las 11:53 a. m., Yichao Yu [email protected] escribió:

@JeffBezanson ¡Buena suerte!

Ojalá pueda conseguir un asiento.

—
Responda a este correo electrónico directamente o véalo en GitHub.

¡Buena suerte!

¡Ídem!

Por suerte llegué lo suficientemente temprano para conseguir un asiento... y tenía razón (como siempre :sonriendo :) ¡realmente debería haber reservado una habitación más grande!

Felicidades

Reparado.

Todavía queda una casilla de verificación sin marcar. Mejor ponte a trabajar.

:shipit: :tropical_drink: :cervezas: :cocktail: :tada: !

:Pulgares hacia arriba:

¡Felicitaciones, Dra. Bezanson!

¡Felicidades, Jeff!

+1

Bravo

la última casilla de verificación se llenó ahora con un whisky Bourbon de Kentucky.

¡Felicidades Jeff!

El miércoles 13 de mayo de 2015 a las 13:44, Mike Nolta [email protected]
escribió:

+1

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -101772806.

¡Felicidades!

¡Felicidades Jef! :cervezas: :cervezas: :sonrisa:

¡Esto es maravilloso! Felicitaciones, Jeff. :fuegos artificiales:

Una gran noticia. ¡Felicidades, Jeff!

¡Felicidades!

felicitaciones

Woop Woop felicidades Jeff!

¡Felicitaciones, doctor Bezanson!

Gracias por publicar la foto, @ScottPJones. @jiahao , creo que también tienes algunas fotos.

Felicidades jeff Su trabajo que terminó en este doctorado ha influido en muchos de nosotros. ¡Tendrá y ya tiene un gran impacto en la computación científica! ¡Rock on!

Felicidades.

¡Genial!

Felicidades jeff!!

Fantástico, felicidades!!

¡Felicidades Dr. Bezanson!

La tesis, para aquellos que quieran echar un vistazo:

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

¡Felicitaciones!

¡Felicidades!

¡Felicidades!

Felicidades :+1:

No sé por qué GitHub decidió rotar todas mis imágenes, pero aquí están.

Vídeo de la ceremonia de clausura del número: http://youtu.be/hGpLOZX6CEY

Aleph-zero ¡felicidades a ti, Jeff! Si alguna vez estás en Seattle, déjame invitarte a una bebida de felicitación. :)

Felicidades jeff Se siente muy lindo celebrar su trabajo como comunidad.

¡Felicidades!

@jiahao , podría valer la pena volver a ejecutar el último mundo de Julia como material complementario para la página de agradecimientos :)

Gracias a todos.

Desafortunadamente, mi tesis no está realmente terminada, pero espero que lo esté pronto...

Tengo un par de fotos más, se las enviaré a Jeff después de que me despierte (¡para su madre, una dama muy amable!) _Dr._ Bezanson puede publicarlas aquí si lo desea...

no hecho??? ¿Gerry te pidió que eliminaras toda esa maldita "sintaxis" y solo lo dejaras escribir con expresiones s?

¡@JeffBezanson usando una Mac no es una imagen que esperaba ver!

¡Hurra!

Felicidades

Bien hecho de parte de todos tus fans de este lado del charco.

no hecho??? ¿Gerry te pidió que eliminaras toda esa maldita "sintaxis" y solo lo dejaras escribir con expresiones s?

¡Lo lograste! No estoy bromeando. Pero se conformará con un modo s-expr opcional.

Estuve hablando con él después de la presentación... le gustaban tus cosas, pero en realidad no le importaba toda la sintaxis... hay _mucha_ de ella... me recordó lo pequeño que es el manual de Scheme :sonriendo: Cuando lo tuve en 6.001 [primer semestre que se impartió], tuvimos que implementar un pequeño intérprete de Scheme en MacLisp... dado que Scheme era tan pequeño, era bastante factible...

y estoy seguro de que puedes eliminarlo bastante rápido, con esa botella de bourbon como compañía (¡si queda algo! ;-))

Hablando de la extensión del manual de esquemas, es divertido: un gran porcentaje está dedicado a documentar el comportamiento de los números, mientras que en Julia eso se define en las bibliotecas. Julia podría ser potencialmente un lenguaje central más pequeño que el esquema (a menos, por supuesto, que le hayas engrapado la especificación LLVM).

A favor o en contra, ¡hay demasiado énfasis en la sintaxis! Consulte también la sección 7.1 de http://www.schemers.org/Documents/Standards/R5RS/HTML/. ¡La sintaxis del esquema es más compleja de lo que la gente piensa!

Julia podría ser potencialmente un lenguaje central más pequeño que el esquema (a menos, por supuesto, que le hayas engrapado la especificación LLVM).

¡Sí, Julia tiene buenos huesos!

¿Es hora de desenterrar la antigua macro @sexpr ?

¡Felicitaciones por graduarte y por lo que lograste con Julia!

:torta: ¡Felicidades!

¡Felicidades @JeffBezanson!

Felicidades :)

:+1:

@boyers! ¡Mucho tiempo sin verte!

los extraño chicos :)

¡Felicidades!

Solo una pregunta: el PDF no tiene enlaces en el ToC ni un índice navegable en los metadatos del pdf.
¿Por qué es tan difícil para un compilador y escritor graduado del MIT agregar \usepackage{hyperref} en su preámbulo?

Eso es porque se supone que debes leer todo y no solo saltearlo. ;-)

Pero sí, hiperref haría esto mucho más accesible.

Te prometo que leerás todo si agregas los enlaces :P

Felicidades. La libertad espera.

¡Felicitaciones, Dra. Bezanson!

@nicola-gigante, puedes hacer una solicitud de extracción: sonríe:.

¿Podemos cabildear por un premio a la mejor disertación?

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

Felicidades!!!

@jpfairbanks - ¡buena idea! Sin embargo, tiene que ser presentado por su asesor de tesis... molestar a Alan Edelman, creo...

Sí, necesita la nominación del asesor y 5 cartas de apoyo. Residencia en
este tema creo que al menos 5 personas piensan que se lo merece.

¿Está limitado a 5 cartas de apoyo? Además, ¡el número real de personas que piensan que se lo merece es al menos unos cuantos órdenes de magnitud mayor!

@JeffBezanson : ¡Felicitaciones!

@alanedelman : Creo que @jpfairbanks tiene un buen punto, Jeff debería ser nominado para el Premio de disertación doctoral de ACM .

@JeffBezanson ¡ Bien hecho y bien merecido!

@ScottPJones "Además, se deben incluir al menos 3 y no más de 5 cartas de respaldo de expertos en el campo que puedan proporcionar información adicional o evidencia del impacto de la disertación".

Tal vez Gerry le escriba uno (¡después de que haya agregado el modo s-expr!) :sonriendo:

Portada de Hacker News :-) Felicitaciones, Jeff.

@nicola-gigante Tienes razón, agregaré hiperref.

Gracias a todos de nuevo. Todo su agradecimiento es el premio final.

@jiahao Es porque tienen datos de rotación EXIF ​​que a los navegadores no les importan. La mayor parte del tiempo. Chrome solo se preocupa por los datos EXIF ​​si la imagen es su propia ventana. Haga clic con el botón derecho y "Abrir en una pestaña nueva" para verlos con la orientación correcta.

Puede usar un eliminador de metadatos EXIF ​​para quitarlos y rotarlos de la manera "adecuada".

+1 para la nominación al premio de disertación ACM.

La fecha límite de nominación es el 31 de octubre de 2015.

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

No me gusta que ACM requiera una transferencia de derechos de autor y derechos de publicación exclusivos. Sigue siendo valioso y prestigioso en cualquier caso.

¡Felicitaciones!

Derechos de publicación exclusivos!?! Tengo dibs en una copia autografiada (o dos... necesito uno para vender en e-bay en 10-15 años, otro para guardarlo para mí :sonriendo :)... tengo que conseguirlo antes de que lo cierren el ACM!
(Por supuesto, eso probablemente significa que estaría disponible en la biblioteca digital de ACM para miembros)

una vez que me entreguen la disertación para que la firme, tengo toda la intención
de nominar la disertación para varios premios :-)

El domingo 17 de mayo de 2015 a las 8:49 a. m., Scott P. Jones [email protected]
escribió:

Derechos de publicación exclusivos!?! Tengo dibs en una copia autografiada (o
dos... necesito uno para vender en e-bay en 10-15 años, otro para guardar para mí [imagen:
:sonriendo:])... ¡tengo que conseguirlo antes de que el ACM lo bloquee!
(Por supuesto, eso probablemente significa que estaría disponible en el ACM
biblioteca digital para miembros)

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -102801616.

No hay comentarios de @JeffBezanson... ¡Espero que esté celebrando (más marcando su última casilla), y que GJS no lo haya encerrado en una habitación en algún lugar hasta que tenga un modo s-expr funcionando!

¡Felicidades!

¡Felicitaciones, @JeffBezanson!

(con retraso) ¡Felicidades!

Actualización: acaba de enviar el documento. La versión enviada es https://github.com/JeffBezanson/phdthesis/tree/876be73a5aab9b034fac3eb9ea9d8f96713f786f .

Estoy seguro de que es deficiente en muchos sentidos. Oh bien. Esperemos que no haya nada realmente malo allí.

Agradable. Felicidades por terminar realmente tu doctorado.

¡Felicidades, Jeff! Gran logro. Estoy seguro de que te alegras de que haya terminado.

Ya encontré que su tesis llena algunos vacíos en la documentación de Julia, por lo que claramente será muy útil. Todos los documentos vienen con fallas; ¡el resto de nosotros estamos impresionados por las fortalezas! ¡Felicitaciones!

¡Y gracias por compartirlo!

¡Guau! Felicitaciones por terminar la defensa y la tesis, y todo el trabajo que significan y representan. Es bueno tener este hito para reconocer todas las cosas que has logrado. ¡Espero que estés orgulloso!

@JeffBezanson Espero que esté planeando tomarse unos días libres para relajarse y celebrar, o tal vez esté planeando celebrar con una revisión del sistema tipográfico o algo así. :-)

Es bueno que el nuevo pdf tenga hiperref, para aquellos que quieran navegar. También deberíamos incluirlo en la lista de publicaciones de julia.