Julia: Jeff Bezanson PhD

cc @fperez que também está interessado nesta edição pendente

Informações de apoio em anexo.

Como uma questão de procedimento, fechar isso pode exigir trabalho em um repositório separado. A tese talvez deva ser incluída na Base para facilitar a contribuição de outros.

Também a ordenação da última tarefa é enganosa; na verdade, ele se repetirá com frequência durante todo o processo.

+1 por incluí-lo na Base, ou pelo menos em julia/doc/thesis . Ou talvez theses para permitir necessidades futuras.

(Por favor, vá em frente e abra um ramo de tese, Jeff.)

Também a ordenação da última tarefa é enganosa; na verdade, ele se repetirá com frequência durante todo o processo.

*também já se repetiu

Estou ansioso para estar presente na cerimônia de _Fechar questão_.

Não consigo reproduzir este problema localmente; é específico do MIT?

Um dos principais autores de Julia, @JeffBezanson , tornou-se um acadêmico desenvolvedor problemático

Esta é a versão github de uma tese de doutorado? Jeff tem que abrir um PR com sua proposta e o comitê decidirá se fará a fusão ou não...

+Inf para resolução rápida deste!

Eu tive o mesmo problema no repositório do IPython há alguns meses, espero que tenha sido corrigido 32 dias atrás.
Tenho certeza que envolveu café, papelada chata e mudança de plano de última hora por causa de britadeiras.

Boa sorte !

Atualizado: Jeff se reuniu com seu comitê de tese e nos deu um esboço.

Fico feliz em saber que o progresso está sendo feito!

Mas git log --date=short --all --since=22.days.ago --author="Jeff Bezanson" ainda nos faz pensar como ele tem tempo para escrever uma tese. Ou isso, ou ele é um super-herói. Na verdade, risque isso: todos nós sabemos que ele _é_ um super-herói, então não importa.

Os commits envolvendo juliatypes.jl registram nossas tentativas de descrever o sistema de tipos de Julia, que é um trabalho de tese diretamente relevante.

O trabalho do sistema de tipos parece já estar dando nos nervos: https://twitter.com/plt_hulk/status/535045242920378369

Eu meio que duvido que seja diretamente em resposta ao trabalho de Jeff, embora eu possa estar errado. Tweet hilário de qualquer maneira.

@jiahao , meu comentário foi principalmente irônico --- eu meio que me perguntei sobre isso. Eu, por exemplo, costumo ter muitos commits quando estou polindo algo para apresentação.

@timholy humor anotado. :)

Seria negligente não mencionar a adorável homenagem a Magritte que nosso colaborador local da teoria @jeanqasaur fez e postou no twitter :

"A Traição dos Tipos" soa bem, não?

Isso é muito engraçado.

Adoro!

Peça ajuda: Jeff está procurando bons exemplos que mostrem vários despachos (e talvez funções encenadas), coisas que seriam muito mais difíceis/lentas em idiomas sem esses recursos.

é show ?

(e talvez funções encenadas)

subarray.jl e subarray2.jl devem servir muito bem. O documento de design está em http://docs.julialang.org/en/latest/devdocs/subarrays/

Eu acho que o pacote Distributions realmente faz com que o envio múltiplo pareça útil. Ter coisas como rand(Gamma(1, 1), 5, 5) vs rand(Normal(0, 1), 3) é um grande ganho em expressividade sem custo de desempenho devido ao envio múltiplo.

Não vejo como esse é o melhor exemplo, pois realmente está se exibindo
despacho único. Qual é a diferença de Gamma(1,1).rand(5,5) que você
faria em uma linguagem OO mais tradicional como Python ou Java?

Em sex, 19 de dezembro de 2014 às 13h39, John Myles White [email protected]
escrevi:

Eu acho que o pacote Distributions realmente faz com que vários despachos pareçam
útil. Ter coisas como rand(Gamma(1, 1), 5, 5) vs rand(Normal(0, 1),
3) é um enorme ganho de expressividade sem custo de desempenho devido ao
despacho múltiplo.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67678367.

OK. Substitua isso por exemplos de cálculo de divergências KL usando resultados analíticos: kl(Normal(0, 1), Normal(0, 1)) vs kl(Normal(0, 1), Gamma(1, 1)) .

Eu também deveria ter acrescentado, havia algumas estatísticas potencialmente úteis sobre como a vida teria sido _sem_ funções encenadas no meu post inicial em #8235. A mensagem para levar para casa: gerar todos os métodos por meio da dimensão 8 resultou em > 5.000 métodos separados e exigiu mais de 4 minutos de tempo de análise e redução (ou seja, um atraso de 4 minutos ao compilar julia). Em comparação, a implementação da função staged é carregada em um piscar de olhos e, é claro, pode ir além de 8 dimensões.

Vs single-dispatch, ainda demonstra a unificação do que outras linguagens OO descrevem como: funções vs métodos. Você pode contrastar com sorted(a) vs a.sort() do python. Em comparação com as linguagens OO "tradicionais", ela muda drasticamente o que significa uma função ser "associada" a uma classe.

Você pode apontar como ele substitui a necessidade de variáveis ​​estáticas versus variáveis ​​de instância, já que você pode despachar na instância ou no tipo. Eu posso ter mais algumas idéias de algumas conversas recentes no IRC, quando eu puder chegar a um computador.

Eu tenho uma implementação de fmap . Isso percorre várias matrizes e
aplica uma função a cada conjunto de elementos. Esta implementação é na verdade
muito lento, pois o número de matrizes pode ser arbitrário. Para tornar isso útil,
Eu criei manualmente a especialização disso para vários números de
argumentos yss . Eu sempre quis escrever uma função encenada para isso,
mas ainda não o fez.

A função encenada precisaria avaliar em particular a chamada map
que produz os 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

Na sexta-feira, 19 de dezembro de 2014 às 12h46, Steven G. Johnson <
[email protected]> escreveu:

Peça ajuda: Jeff está procurando bons exemplos que mostrem vários
despacho (e talvez funções encenadas), coisas que seriam muito
mais difícil/mais lento em idiomas sem esses recursos.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

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

Desculpe, ignore a chamada para eltype(f) na assinatura da função no meu código,
isso não é padrão.

-erik

Na sexta-feira, 19 de dezembro de 2014 às 15h08, Erik Schnetter [email protected]
escrevi:

Eu tenho uma implementação de fmap . Isso percorre várias matrizes e
aplica uma função a cada conjunto de elementos. Esta implementação é na verdade
muito lento, pois o número de matrizes pode ser arbitrário. Para tornar isso útil,
Eu criei manualmente a especialização disso para vários números de
argumentos yss . Eu sempre quis escrever uma função encenada para isso,
mas ainda não o fez.

A função encenada precisaria avaliar em particular a chamada map
que produz os 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

Na sexta-feira, 19 de dezembro de 2014 às 12h46, Steven G. Johnson <
[email protected]> escreveu:

Peça ajuda: Jeff está procurando bons exemplos que mostrem vários
despacho (e talvez funções encenadas), coisas que seriam muito
mais difícil/mais lento em idiomas sem esses recursos.

Responda a este e-mail diretamente ou visualize-o no 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 , como o Matlab e o NumPy também têm subarrays/slices, por que podemos argumentar que o envio múltiplo é essencial aqui?

Facilidade de implementação? Até onde eu sei, você pode simular vários despachos em qualquer idioma, então não é essencial para nada.

Talvez não seja bom sugerir algo que ainda não decidimos que queremos. Em https://github.com/JuliaLang/julia/issues/9297 , há uma proposta que nos permite ter posições de buffer UTF-8 eficientes e indexação conveniente sem furos para que você possa fazer aritmética conveniente quando quiser. Regex e search retornarão o índice interno encapsulado, mas s[2] pode fornecer o segundo caractere, independentemente de quantos bytes foram usados ​​para codificar o primeiro.

Eles podem fazer subarrays/fatias eficientes de AbstractArrays ou sua implementação funciona apenas para blocos contíguos de memória? Este não é um problema muito difícil de resolver se você pode assumir que seu array pai tem memória contígua; fica mais interessante quando você não faz essa suposição.

Sim, esse é o principal recurso que estamos procurando: não apenas que algo pode ser feito bem com várias funções de expedição e/ou encenadas, mas que a falta desses recursos em outras linguagens tornou a implementação do recurso muito mais difícil (idealmente, muito mais difícil que ninguém sequer tentou).

@timholy , um array NumPy é caracterizado por um passo fixo para cada dimensão, não necessariamente contiguidade (essencialmente equivalente ao nosso DenseArray ). Essa propriedade é preservada sob fatiamento, de modo que as próprias fatias podem ser fatiadas etc.

aberrant tinha algumas boas perguntas no IRC nesse sentido. Tentei extrair apenas os comentários relevantes (entre as conversas e notificações não relacionadas) abaixo:

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

se você estiver procurando por mais exemplos: https://github.com/JuliaLang/julia/pull/7291

A redução de código de rede é boa de 6K C++ para cerca de 1K Julia. Os benchmarks de desempenho iniciais mostram que é pouco menos de 2x o C++ nativo.

quantas linguagens você conhece que podem reivindicar a implementação de printf, desde os operadores (+-*/, Int, Float) até a formatação de saída numérica, na própria linguagem, e benchmark dentro de uma pequena margem das versões libc? Talvez C++? C nem pode reivindicar isso (não tem sobrecarga de operador).

Python/MATLAB/etc. pode ser capaz de reivindicar bits disso, mas você já tentou usar os operadores de string no MATLAB?

Esta é uma discussão muito interessante e eu gostaria de acrescentar alguns pontos:

• O que parece não ser realmente respondido é como Julia se compara ao polimorfismo em C++ speedwise. Em C++ pode-se ter polimorfismo estático através de templates ou polimorfismo dinâmico através de OO. Mas o posterior requer uma vtable e é sempre um pouco mais lento, especialmente ao chamar essas coisas em um loop apertado. Por esta razão, nunca se sobrecarregaria o operador de acesso ao array, pois isso não seria rápido. Eigen, por exemplo, usa polimorfismo estático.
• Em Julia não há destino entre uma função virtual e uma não virtual e ainda não temos penalidades de desempenho. Meu entendimento é que a grande vantagem é que Julia pode gerar código "on the fly" e, portanto, ainda gerar código rápido, onde em tempo de execução C++ significa que não é mais possível modificar o código gerado. Além disso, em Julia, podemos fazer inlining em tempo de execução. Portanto, nenhuma sobrecarga de chamada de função. E na Julia não temos que pensar em tudo isso porque é feito automaticamente
• Uma coisa enorme (novamente) é: genéricos sem sobrecarga e sem toda a dor que C++ tem (olhando tempos de compilação) Existem métodos diferentes de como implementar genéricos e IMHO Julia usa o mesmo modelo que C#, então isso pode não ser totalmente novo (para tese de Jeff). Mas ainda acho que isso poderia ser algo para discutir na tese.

O quão difícil é explicar o quão eficaz é o despacho múltiplo é bastante interessante.

Ainda bem que estamos na mesma página agora. Sim, nossos novos SubArrays não dependem de passos, nem requerem indexação linear (embora possam usá-la, e o fazem por padrão se for eficiente). Portanto, eles funcionam eficientemente para qualquer AbstractArray e também suportam visualizações "não-strided" ( Vector{Int} índices).

Para esclarecer, apresentei nossos novos SubArrays principalmente como um exemplo de funções encenadas, não de despacho múltiplo. Dito isso, o esquema atual desmoronaria na etapa de construção sem despacho múltiplo: chamamos métodos construtores completamente diferentes para slice(::AbstractArray, ::UnitRange{Int}, ::Int, ::Vector{Int}) e slice(::AbstractArray, ::Int, ::UnitRange{Int}, ::UnitRange{Int}) , etc. Esses construtores são gerados por funções encenadas, mas nós precisa de vários despachos para o sistema funcionar.

Sem funções separadas, um construtor varargs tem que encarar o fato de que fazer um loop sobre as entradas na tupla de índices não é de tipo estável: para processar índices individuais em um loop, você precisa atribuí-los a uma variável escalar nomeada, e essa variável é garantido não ser bem tipado, mesmo que a tupla de entrada possa ser. Claro, a função encenada faz muito mais: quase todas as decisões "difíceis" --- estamos abandonando isso como uma dimensão fatiada, ou mantendo-a, e quais são as consequências para a representação interna do objeto? ---pode ser feito em tempo de compilação, reduzindo o construtor de tempo de execução a uma operação notavelmente trivial. Acontece que a operação trivial específica é diferente para cada combinação de tipos de entrada, portanto, para explorar essa trivialidade e tornar a construção rápida, você precisa chamar diferentes métodos personalizados para cada combinação de tipos de entrada. É por isso que você precisa de funções encenadas e de despacho múltiplo.

Pessoalmente, duvido que seja possível fazer o que fizemos sem a combinação de funções encenadas e despacho múltiplo, e que é provável que Julia agora tenha as visualizações de array mais flexíveis e eficientes de qualquer linguagem. Mas não pretendo ter realizado nenhum tipo de estudo real desse problema.

Isso me faz pensar se devo escrever nossos SubArrays para publicação --- parece que temos algo novo aqui.

@StefanKarpinski : Vamos ser autocríticos: talvez ainda não tenhamos escrito?

@timholy Na verdade, vejo duas coisas aqui, as funções encenadas (que devo admitir não totalmente compreendidas) e como Julia se encaixa no universo de funções virtuais C++ vs templates (C# e Java são semelhantes aqui).

Para a comparação C++ seria muito interessante fazer cronometragem e provar experimentalmente que podemos alcançar o polimorfismo em tempo de compilação (o que tenho certeza que fazemos)

Outra coisa que eu queria formular há algum tempo é como Julia se compara ao C++ em relação aos conceitos de C++ (lite). A subtipagem que temos é uma grande parte dos Conceitos C++.

Alguém precisa escrever um monte de código C++ e executar tempos para verificar isso?

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

Não há essencialmente nada além de operações de carga e armazenamento (ou seja, acesso à memória) lá.

@timholy , acho que vale a pena escrever isso. Eu acredito (mas não verifiquei) que muitos sistemas que implementam arrays Nd têm implementações especializadas para as primeiras dimensões e, em seguida, geralmente voltam para algo lento, e esse não deve ser o caso da nova implementação.

Outro caso relacionado é escrever um armazenamento Nd esparso eficiente (arrays sendo o caso especial comum).

Tim,

sim, de fato, olhar para o código assembly resultante é uma ótima ferramenta. Mas ainda acho que isso deve ser comparado em um contexto maior, onde (na implementação C++) as funções virtuais teriam que ser levadas em consideração.

Meu palpite é realmente que não é multiple dispatch que é tão rápido, mas que podemos inline em tempo de execução e, assim, transformar a função virtual (que são nossas funções genéricas) em instrução eficiente sem indireção de chamada de função.

Se isso for verdade (por favor, corrija-me se estiver errado @JeffBezanson @vtjnash @stevengj @timholy ) o múltiplo em multiple dispatch não é a razão de Julia ser tão rápida, mas um lado legal afeta que determinado código pode ser formulado mais agradável (onde o despacho único é limitante)

Provavelmente não estou entendendo, mas não tenho certeza da distinção que você está fazendo. Em Julia, "inline" e "runtime" não parecem andar juntos; inlining é executado durante a inferência de tipo, ou seja, em tempo de compilação. O despacho múltiplo é usado para selecionar o método apropriado para os tipos inferidos.

A confusão aqui é que "tempo de compilação" e "tempo de execução" de C++ não podem ser comparados com os de Julia. Codegen pode acontecer durante o "tempo de execução", então sim, acho que quando faço include("myscript.jl") inlining é executado. E mesmo que "tempo de execução" não seja a palavra certa para isso, do ponto de vista do C++, é "tempo de execução".

E o despacho em diferentes tipos é como uma vtable, mas mais geral, não?

Isso me faz pensar se devo escrever nossos SubArrays para publicação --- parece que temos algo novo aqui.

Está um pouco longe dos tópicos padrão, mas você pode considerar enviar para JSS. Precisamos de mais artigos de Julia.

Eu adoraria se Tim escrevesse um post no blog para descrever esse trabalho para começar, pois isso deixará muitas pessoas atualizadas. JSS é uma ótima ideia, e talvez valha a pena escrever parte do trabalho fundamental que foi feito em quadros de dados e distribuições? Eu certamente adoraria lê-lo.

Bem, o que me fez pensar nisso é que muito disso foi escrito: http://docs.julialang.org/en/latest/devdocs/subarrays/. Para uma publicação, você gostaria de entrar em muito mais detalhes, mas isso atinge um bom número dos principais pontos gerais.

Para a pergunta que @stevengj levantou sobre despacho múltiplo, eu diria que sem despacho múltiplo, é muito difícil escrever nossa biblioteca base em julia. Estou dizendo o que já é conhecido por todos aqui, e me pergunto se este não é um exemplo convincente para as razões aqui levantadas.

Detalhes como operações em números e conversão/promoção estão intrinsecamente vinculados ao envio múltiplo. Como o despacho múltiplo é o que essencialmente expõe a inferência de tipos no compilador à maneira como os tipos são usados ​​no código, podemos escrever uma biblioteca de base numérica genérica e rápida. Para citar uma declaração que você fez - isso ajuda a separar a criação de políticas do compilador e em bibliotecas. Por exemplo, @JeffBezanson me mostrou uma vez como a especificação Scheme gasta 1/3 de seu espaço em detalhes numéricos.

Muitos sistemas interpretados geralmente acabam tendo tipos gerais e inspecionando os tipos de seus objetos em tempo de execução para tomar decisões sobre qual código executar. Eles geralmente têm uma implementação separada em C/C++/Fortran na biblioteca base para cada tipo, levando a uma base de código grande e difícil de depurar. Muitas vezes, eles são gerados por meio de um sistema de macro externo, mas cada vez mais o uso de modelos C++ tem evitado esse problema específico. A questão de duas linguagens e inferência de tipos ainda permanece nestes casos.

Em algum nível, vetorização é quantas linguagens científicas amortizam o custo de determinar tipos em tempo de execução e fazer a seleção de código apropriada. Em Julia, com a combinação de inferência de tipos, despacho múltiplo e programação genérica, nossos custos para ambos são significativamente menores, permitindo-nos escrever código devectorizado genérico - C sem tipos.

Um exemplo é a comparação de desigualdade com MathConst (representando números irracionais) na PR #9198:

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

• FloatingPoint vs MathConst compara o float com o float acima/abaixo da constante
• Rational{T} vs MathConst (para tipos inteiros limitados T ) encontra o racional mais próximo representável pelo tipo; então com base se está acima ou abaixo do verdadeiro tipo irracional.

O que torna isso viável é o fácil acesso às funcionalidades Rational e BigFloat em tempo de compilação. Embora seja possível usar algo como um pré-processador de macro, isso exigiria essencialmente duas implementações de toda a funcionalidade.

Tenho uma pequena atualização sobre este assunto. O documento já está aberto ao público: https://github.com/JeffBezanson/phdthesis

Hoje estou lançando uma espécie de rascunho por prazo auto-imposto. Não é bem um rascunho; muitas peças estão totalmente ausentes. Também não reivindico nenhuma responsabilidade por qualquer coisa que esteja dentro dos comentários do TeX, ou presente apenas no histórico de versões anteriores :)

Todos os comentários são bem-vindos! Em particular, se você tiver bons exemplos de código julia que mostrem bem a linguagem, especialmente qualquer coisa que seria difícil de fazer sem ela. Sempre procurando bons exemplos de despacho múltiplo não triviais.

Obrigado por tornar isso público. Fiquei surpreso quando tentei seguir um link que o SGJ usou e bati um 404.

Talvez a aritmética da matriz triangular possa ser um exemplo da utilidade do despacho múltiplo de Julia. Aqui UpperTriangular+UpperTriangular=UpperTriangular , mas UpperTriangular+LowerTriangular=Matrix .

Também falamos sobre a promoção de tipos de elementos. Eu gosto que você possa evitar a promoção quando não for necessário, por exemplo

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

Não posso dizer o quão específico isso é para Julia, mas, como vimos, parecia que pelo menos Eigen não gerenciaria a promoção, mas exigiria que os tipos de elementos fossem estáveis ​​sob a operação de álgebra linear.

Jeff está indo para a reta final agora, esperamos, então comentários e correções em sua tese (veja o repositório github acima mencionado) seriam especialmente bem-vindos agora.

Sinta-se à vontade para enviar PRs para erros de digitação, referências ausentes, etc.

@stevengj Devemos esperar um anúncio do cronograma de defesa aqui?

sim.

Espero que ele já tenha um emprego no MIT... (ou em qualquer lugar onde ele continue o ótimo trabalho de Julia)... lendo sua tese agora... ótimas coisas, IMO!

@andreasnoack Um pouco esotérico, mas engraçado: defina um tipo de anel de matriz de seta e aplique a fatoração de Cholesky da base para ver como é a estrutura de uma fatoração de cholesky de uma matriz de seta de matrizes de seta. https://gist.github.com/mschauer/c325ff89cd378fe7ecd6 ("A" matriz de seta, "F" matriz completa, "L" meia seta inferior").

@ScottPJones obrigado!!

Defesa agendada: quarta-feira, 13 de maio, 13h Stata D-463.

@JeffBezanson você está planejando gravá-lo através do replay.csail.mit.edu?

...talvez eu prefira esquecer isso... :)

Não é para isso que serve a última caixa de seleção?

Você tem _realmente_ certeza de que deveria dar o endereço? Você pode ser assediado por fãs, que querem cópias autografadas de sua tese! :sorrindo:

Já tenho meus ingressos. Ouvi dizer que o preço já está em US$ 800 no mercado negro.

Stata D-463 não estava lá na minha época... (eu só estive lá para visitar amigos e para o Dia do Banco de Dados NE)... Será que vai ser grande o suficiente? Certamente ele vai precisar de 10-250!

Oficialmente D-463 cabe 48 cadeiras. Se acharmos que isso não será suficiente, podemos pensar em conseguir um quarto maior.

Eu realmente não acho que você realmente aprecia o que você fez! Se todos os seus fãs aparecessem, talvez 10-250 não seria grande o suficiente... reserve Kresge agora!

Abstração em Computação Técnica

• Doutorando: Jeff Bezanson
• Orientador de Tese: Prof. Alan Edelman
• Comissão de Tese: Prof. Steven Johnson, Prof. Saman Amarasinghe, Prof. Gerry Sussman
• Data: quarta-feira, 13 de maio de 2015
• Horário: 13h
• Localização: campus do MIT, 32-D463

_Ambientes de programação baseados em array são populares para computação científica e técnica. Esses sistemas consistem em bibliotecas de funções integradas emparelhadas com linguagens de alto nível para interação. Embora as bibliotecas tenham um bom desempenho, acredita-se amplamente que os scripts nessas linguagens são necessariamente lentos e que apenas feitos heróicos de engenharia podem, na melhor das hipóteses, melhorar parcialmente esse problema._

_Esta tese defende que o que realmente é necessário é uma estrutura mais coerente para esta funcionalidade. Para encontrar um, devemos perguntar sobre o que é realmente a computação técnica. Esta tese sugere que esse tipo de programação é caracterizado por uma ênfase na complexidade do operador e especialização do código, e que uma linguagem pode ser projetada para melhor atender a esses requisitos._

_A ideia chave é integrar código_ _seleção _ _com código_ _especialização _, _usando funções genéricas e inferência de tipo de fluxo de dados. Sistemas como esses podem sofrer com a compilação ineficiente ou com a incerteza sobre em que se especializar. Mostramos que o despacho baseado em tipo suficientemente poderoso resolve esses problemas. A linguagem resultante, Julia, alcança uma "explicação por eliminação" no estilo Quine de muitos dos recursos produtivos que os usuários de computação técnica esperam._

Haverá cópias impressas de sua tese disponíveis para os espectadores?

Talvez cópias assinadas

Isso é o que eu espero... Acho que posso ganhar muito dinheiro no Ebay vendendo uma cópia autografada em 10-15 anos (quando eu realmente precisar para pagar a educação universitária dos meus filhos... esp. se eles vão aonde eles disseram que querem ir... :sorrindo: )

Boa sorte, Jeff!

Boa sorte! Se eu estivesse na área eu seria um dos fanboys que @ScottPJones menciona

@ScottPJones :+1:

Quebre uma perna, Jeff!

Boa sorte, Jeff!

Boa sorte! @JeffBezanson

@JeffBezanson Boa Sorte!!

Espero conseguir um assento.

boa sorte

Eu disse a ele que ele deveria ter reservado 10-250!

Enviado do meu iPhone

Em 13 de maio de 2015, às 11h53, Yichao Yu [email protected] escreveu:

@JeffBezanson Boa Sorte!!

Espero conseguir um assento.

—
Responda a este e-mail diretamente ou visualize-o no GitHub.

Boa sorte!

Idem!

Por sorte eu cheguei cedo o suficiente para conseguir um lugar... e eu estava certo (como sempre :sorrindo:) ele realmente deveria ter reservado um quarto maior!

Parabéns

Fixo.

Ainda há uma caixa de seleção desmarcada. Melhor começar a trabalhar.

:shipit: :tropical_drink: :cervejas: :coquetel: :tada: !

:afirmativo:

Parabéns, Dr. Bezanson!

Parabéns, Jeff!

+1

Bravo

a última caixa de seleção foi preenchida agora com um Kentucky Bourbon Whiskey.

Parabéns Jef!

Na quarta-feira, 13 de maio de 2015 às 13h44, Mike Nolta [email protected]
escrevi:

+1

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -101772806.

Parabéns!

Parabéns Jef! :cervejas: :cervejas: :sorriso:

Isso é maravilhoso! Parabéns, Jef. :fogos de artifício:

Boas notícias. Parabéns, Jef!

Parabéns!

parabéns

Woop woop parabéns Jeff!

Parabéns, Dr Bezanson!

Obrigado por postar a foto, @ScottPJones. @jiahao , acho que você tem algumas fotos também?

Parabéns Jef. Seu trabalho que terminou neste PHD influenciou muitos de nós. Terá e já tem um enorme impacto na computação científica! Arrase!

Parabéns.

Excelente!

Parabéns Jef!!

Fantástico, parabéns!!

Parabéns Dr. Bezanson!

A tese, para quem quiser dar uma olhada:

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

Parabéns!

Parabéns!

Parabéns!

Parabéns :+1:

Não sei por que o GitHub decidiu girar todas as minhas fotos, mas aqui estão elas.

Vídeo da cerimônia de encerramento da edição: http://youtu.be/hGpLOZX6CEY

Aleph-zero parabéns para você, Jeff! Se você estiver em Seattle, deixe-me pagar-lhe uma bebida de felicitações. :)

Parabéns Jef. É muito bom celebrar seu trabalho como comunidade.

Parabéns!

@jiahao , pode valer a pena reexecutar o último mundo de Julia como material complementar para a página de agradecimentos :)

Obrigado a todos.

Infelizmente minha tese não está realmente concluída, mas espero que seja em breve...

Tenho mais algumas fotos, vou enviá-las para Jeff assim que acordar (para a mãe dele, uma senhora muito simpática!) _Dr._ Bezanson pode postá-las aqui se quiser...

Não realizado??? Gerry pediu para você remover toda aquela maldita "sintaxe" e deixá-lo escrever com expressões-s?

@JeffBezanson usando um mac não é uma foto que eu esperava ver!

Yay!

Parabéns

Bem feito de todos os seus fãs deste lado da lagoa.

Não realizado??? Gerry pediu para você remover toda aquela maldita "sintaxe" e deixá-lo escrever com expressões-s?

Você acertou em cheio! Eu não estou brincando. Mas ele vai se contentar com um modo s-expr opcional.

Eu estava conversando com ele depois da apresentação... ele gostou do seu material, mas realmente não se importou com toda a sintaxe... há apenas _muito_ disso... ele me lembrou o quão pequeno é o manual do Scheme :grinning: Quando eu o tive por 6.001 [primeiro semestre foi ensinado], tivemos que implementar um pequeno interpretador Scheme no MacLisp... já que Scheme era tão pequeno, era bastante factível...

e tenho certeza que você pode acabar com isso rapidamente, com aquela garrafa de bourbon como companhia (se sobrar alguma! ;-) )

Falando do tamanho do manual do esquema, é engraçado: uma grande porcentagem dele é dedicada a documentar o comportamento dos números, enquanto em Julia isso é definido nas bibliotecas. Julia poderia ser uma linguagem de núcleo menor que o esquema (a menos, é claro, que você tenha grampeado a especificação LLVM a ela).

A favor ou contra, há muita ênfase na sintaxe! Confira também a seção 7.1 de http://www.schemers.org/Documents/Standards/R5RS/HTML/. A sintaxe do esquema é mais complexa do que as pessoas pensam!

Julia poderia ser uma linguagem de núcleo menor que o esquema (a menos, é claro, que você tenha grampeado a especificação LLVM a ela).

Sim, Julia tem bons ossos!

Hora de desenterrar a velha macro @sexpr ?

Parabéns pela formatura e pelo que você conseguiu com Julia!

:bolo: Parabéns!

Parabéns @JeffBezanson!

parabéns :)

:+1:

@boyers! Há quanto tempo!

saudades de vcs :)

Parabéns!

Só uma pergunta: o PDF não possui links no ToC nem índice navegável nos metadados do pdf.
Por que é tão difícil para um compilador-escritor graduado pelo MIT adicionar \usepackage{hyperref} em seu preâmbulo?

Isso é porque você deve ler a coisa toda e não apenas pular. ;-)

Mas sim, hyperref tornaria isso muito mais acessível.

Eu prometo que você lerá tudo se adicionar os links :P

Parabéns. A liberdade espera.

Parabéns, Dr. Bezanson!

@nicola-gigante, você pode fazer um pull request : smile:.

podemos fazer lobby por um prêmio de melhor dissertação?

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

Parabéns!!!

@jpfairbanks - boa ideia! Tem que ser submetido por seu orientador de tese embora... importunar Alan Edelman, eu acho...

Sim, precisa de indicação do orientador e 5 cartas de apoio. Baseado em
essa questão eu acho que pelo menos 5 pessoas acham que ele merece.

É limitado a 5 cartas de apoio? Além disso, o número real de pessoas que pensam que ele merece é pelo menos algumas ordens de magnitude maior!

@JeffBezanson : Parabéns!

@alanedelman : Eu acho que @jpfairbanks tem um bom ponto, Jeff deveria ser indicado para o ACM Doctoral Dissertation Award .

@JeffBezanson Muito bem e merecido!

@ScottPJones "Além disso, pelo menos 3 e não mais que 5 cartas de apoio devem ser incluídas de especialistas na área que possam fornecer informações adicionais ou evidências do impacto da dissertação."

Talvez Gerry escreva um para ele (depois de adicionar o modo s-expr!) :grinning:

Primeira página do Hacker News :-) Parabéns, Jeff.

@nicola-gigante Você está certo, vou adicionar hyperref.

Obrigado a todos novamente. Toda a sua apreciação é o prêmio final.

@jiahao É porque eles têm dados de rotação EXIF ​​com os quais os navegadores não se importam. A maior parte do tempo. O Chrome só se preocupa com os dados EXIF ​​se a imagem for sua própria janela. Clique com o botão direito e "Abrir em nova guia" para vê-los na orientação correta.

Você pode usar um removedor de metadados EXIF ​​para tirar isso e girá-los da maneira "correta".

+1 para a indicação ao prêmio de dissertação da ACM.

O prazo de candidatura é até 31 de outubro de 2015.

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

Não gosto que a ACM exija uma transferência de direitos autorais para eles e direitos exclusivos de publicação. Ainda é valioso e prestigioso em qualquer caso.

Parabéns!

Direitos de publicação exclusivos!?! Eu tenho direito a uma cópia autografada (ou duas... preciso de uma para vender no e-bay em 10-15 anos, outra para guardar para mim: sorrindo:)... tenho que conseguir isso antes que seja trancado por o ACM!
(Claro, isso provavelmente significa que estaria disponível na biblioteca digital da ACM para membros)

uma vez que a dissertação é entregue a mim para assinar eu tenho toda a intenção
de nomear a dissertação para vários prémios :-)

No domingo, 17 de maio de 2015 às 8h49, Scott P. Jones [email protected]
escrevi:

Direitos de publicação exclusivos!?! Eu tenho direito a uma cópia autografada (ou
dois... preciso de um para vender no e-bay em 10-15 anos, outro para guardar para mim [imagem:
:sorrindo:])... tenho que pegar isso antes que seja trancado pelo ACM!
(Claro, isso provavelmente significa que estaria disponível no ACM's
biblioteca digital para membros)

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -102801616.

Sem comentários de @JeffBezanson... Eu _espero_ que ele esteja comemorando (mais marcando sua última caixa), e não foi trancado em uma sala em algum lugar por GJS até que ele tenha um modo s-expr funcionando!

Parabéns!

Parabéns, @JeffBezanson!

(atrasado) Parabéns!

Atualização: acabou de enviar o documento. A versão enviada é https://github.com/JeffBezanson/phdthesis/tree/876be73a5aab9b034fac3eb9ea9d8f96713f786f .

Tenho certeza que é deficiente em muitos aspectos. Ah bem. Espero que não haja nada realmente ruim lá.

Agradável. Parabéns por realmente terminar seu doutorado.

Parabéns, Jef! Grande realização. Tenho certeza que você está feliz que acabou.

Eu já descobri que sua tese preenche algumas lacunas na documentação de Julia, então claramente será bastante útil. Todos os documentos vêm com falhas; o resto de nós está impressionado com os pontos fortes! Parabéns!

E obrigada por compartilhar!

Uau! Parabéns por terminar a defesa e tese, e todos os demais trabalhos que elas significam e representam. É bom ter esse marco para reconhecer todas as coisas que você realizou. Espero que você esteja orgulhoso!

@JeffBezanson Espero que você esteja planejando tirar alguns dias de folga para relaxar e comemorar, ou talvez esteja planejando comemorar com a revisão do sistema de tipos ou algo assim. :-)

Legal que o novo pdf tenha hyperref - para quem quiser navegar. Devíamos também colocá-lo na lista de publicações da Julia.