Julia: Jeff Bezanson PhD

cc @fperez yang juga tertarik dengan isu yang beredar ini

Informasi pendukung terlampir.

Sebagai masalah prosedural, menutup ini mungkin memerlukan pekerjaan di repositori terpisah. Tesis mungkin harus dimasukkan ke dalam Base untuk memudahkan orang lain berkontribusi.

Juga urutan tugas terakhir menyesatkan; itu benar-benar akan sering berulang selama proses.

+1 untuk memasukkannya ke dalam Base, atau setidaknya di julia/doc/thesis . Atau mungkin theses untuk memenuhi kebutuhan di masa mendatang.

(Silakan buka cabang tesis, Jeff.)

Juga urutan tugas terakhir menyesatkan; itu benar-benar akan sering berulang selama proses.

*juga sudah berulang

Saya tidak sabar untuk hadir di upacara _Tutup issue_.

Saya tidak dapat mereproduksi masalah ini secara lokal; itu khusus MIT?

Salah satu penulis inti Julia, @JeffBezanson , telah menjadi akademisi pengembang yang bermasalah

Apakah ini versi github dari tesis PHD? Jeff harus membuka PR dengan proposalnya dan panitia akan memutuskan apakah akan bergabung atau tidak...

+Inf untuk resolusi cepat yang satu ini!

Saya memiliki masalah yang sama pada repo IPython beberapa bulan yang lalu, semoga sudah diperbaiki 32 hari yang lalu.
Saya cukup yakin itu melibatkan kopi, dokumen yang mengganggu, dan perubahan rencana menit terakhir karena jackhammers.

Semoga beruntung !

Diperbarui: Jeff bertemu dengan komite tesisnya dan memberi kami garis besar kasarnya.

Senang mendengar kemajuan sedang dibuat!

Tapi git log --date=short --all --since=22.days.ago --author="Jeff Bezanson" masih membuat orang bertanya-tanya bagaimana dia punya waktu untuk menulis tesis. Entah itu, atau dia seorang superhero. Sebenarnya, coret itu: kita semua tahu dia _adalah_ superhero, jadi tidak apa-apa.

Komit yang melibatkan juliatypes.jl merekam upaya kami untuk mendeskripsikan sistem tipe Julia, yang merupakan karya tesis yang relevan secara langsung.

Jenis kerja sistem tampaknya sudah membuat beberapa saraf: https://twitter.com/plt_hulk/status/535045242920378369

Saya agak ragu itu langsung dalam menanggapi pekerjaan Jeff, meskipun saya bisa saja salah. Tweet lucu juga.

@jiahao , komentar saya kebanyakan basa-basi --- saya agak bertanya-tanya tentang hal itu. Saya, misalnya, cenderung memiliki banyak komitmen ketika saya memoles sesuatu untuk presentasi.

@timholy humor dicatat. :)

Akan lalai untuk tidak menyebutkan penghormatan Magritte yang indah yang dibuat dan diposting oleh kolaborator teori lokal kami @jeanqasaur di twitter :

"The Treachery of Types" memiliki nada yang bagus untuk itu, bukan?

Itu cukup lucu.

Suka sekali!

Minta bantuan: Jeff mencari contoh bagus yang memamerkan banyak pengiriman (dan mungkin fungsi bertahap), hal-hal yang akan jauh lebih sulit/lebih lambat dalam bahasa tanpa fitur tersebut.

adalah, show ?

(dan mungkin fungsi yang dipentaskan)

subarray.jl dan subarray2.jl harus disajikan dengan baik. Dokumen desain ada di http://docs.julialang.org/en/latest/devdocs/subarrays/

Saya pikir paket Distribusi benar-benar membuat beberapa pengiriman tampak berguna. Memiliki hal-hal seperti rand(Gamma(1, 1), 5, 5) vs rand(Normal(0, 1), 3) adalah keuntungan besar dalam ekspresivitas tanpa biaya kinerja karena pengiriman ganda.

Saya tidak melihat bagaimana itu adalah contoh terbaik karena itu benar-benar pamer
pengiriman tunggal. Apa bedanya dengan Gamma(1,1).rand(5,5) yang Anda
akan dilakukan dalam bahasa OO yang lebih tradisional seperti Python atau Java?

Pada Jum, 19 Des 2014 jam 13:39, John Myles White [email protected]
menulis:

Saya pikir paket Distribusi benar-benar membuat beberapa pengiriman tampak
berguna. Memiliki hal-hal seperti Rand(Gamma(1, 1), 5, 5) vs Rand(Normal(0, 1),
3) adalah keuntungan besar dalam ekspresivitas tanpa biaya kinerja karena
beberapa pengiriman.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67678367.

Oke. Ganti itu dengan contoh penghitungan KL-divergences menggunakan hasil analitik: kl(Normal(0, 1), Normal(0, 1)) vs kl(Normal(0, 1), Gamma(1, 1)) .

Saya juga harus menambahkan, ada beberapa statistik yang berpotensi berguna tentang seperti apa kehidupan _tanpa_ fungsi bertahap di posting awal saya di #8235. Pesan yang dapat dibawa pulang: menghasilkan semua metode melalui dimensi 8 menghasilkan > 5000 metode terpisah, dan membutuhkan lebih dari 4 menit waktu penguraian&penurunan (yaitu, penundaan 4 menit saat kompilasi julia). Sebagai perbandingan, implementasi fungsi bertahap dimuat dalam sekejap, dan tentu saja dapat melampaui 8 dimensi.

Vs pengiriman tunggal, itu masih menunjukkan penyatuan dari apa yang digambarkan oleh bahasa OO lainnya sebagai: fungsi vs metode. Anda dapat membedakan dengan python's sorts(a) vs a.sort(). Dibandingkan dengan bahasa OO "tradisional", ini secara dramatis mengubah apa artinya suatu fungsi "dikaitkan dengan" kelas.

Anda dapat menunjukkan bagaimana ia menggantikan kebutuhan variabel statis vs variabel instan, karena Anda dapat mengirimkan instans atau tipenya. Saya mungkin memiliki beberapa ide lagi dari beberapa percakapan IRC baru-baru ini, ketika saya bisa mendapatkan komputer.

Saya memiliki implementasi fmap . Ini melintasi beberapa array dan
menerapkan fungsi untuk setiap himpunan elemen. Implementasi ini sebenarnya
sangat lambat karena jumlah array dapat berubah-ubah. Untuk membuat ini berguna,
Saya telah membuat spesialisasi ini secara manual untuk berbagai nomor
argumen yss . Saya selalu ingin menulis fungsi bertahap untuk ini,
tapi belum melakukannya.

Fungsi yang dipentaskan perlu mengevaluasi khususnya panggilan map
yang menghasilkan argumen ke 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

Pada Jum, 19 Des 2014 jam 12:46, Steven G. Johnson <
[email protected]> menulis:

Minta bantuan: Jeff mencari contoh bagus yang memamerkan banyak hal
pengiriman (dan mungkin fungsi yang dipentaskan), hal-hal yang akan banyak
lebih sulit/lebih lambat dalam bahasa tanpa fitur-fitur itu.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

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

Maaf, abaikan panggilan ke eltype(f) di tanda tangan fungsi dalam kode saya,
itu tidak standar.

-erik

Pada Jum, 19 Des 2014 jam 15:08, Erik Schnetter [email protected]
menulis:

Saya memiliki implementasi fmap . Ini melintasi beberapa array dan
menerapkan fungsi untuk setiap himpunan elemen. Implementasi ini sebenarnya
sangat lambat karena jumlah array dapat berubah-ubah. Untuk membuat ini berguna,
Saya telah membuat spesialisasi ini secara manual untuk berbagai nomor
argumen yss . Saya selalu ingin menulis fungsi bertahap untuk ini,
tapi belum melakukannya.

Fungsi yang dipentaskan perlu mengevaluasi khususnya panggilan map
yang menghasilkan argumen ke 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

Pada Jum, 19 Des 2014 jam 12:46, Steven G. Johnson <
[email protected]> menulis:

Minta bantuan: Jeff mencari contoh bagus yang memamerkan banyak hal
pengiriman (dan mungkin fungsi yang dipentaskan), hal-hal yang akan banyak
lebih sulit/lebih lambat dalam bahasa tanpa fitur-fitur itu.

Balas email ini secara langsung atau lihat di 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 , karena Matlab dan NumPy juga memiliki subarray/irisan, mengapa kami dapat berargumen bahwa pengiriman ganda sangat penting di sini?

Kemudahan implementasi? Sejauh yang saya tahu Anda dapat mensimulasikan beberapa pengiriman dalam bahasa apa pun, jadi itu tidak penting untuk apa pun.

Mungkin tidak baik untuk menyarankan sesuatu yang belum kita putuskan kita inginkan. Di https://github.com/JuliaLang/julia/issues/9297 , ada proposal yang memungkinkan kami memiliki posisi buffer UTF-8 yang efisien dan pengindeksan yang nyaman tanpa lubang sehingga Anda dapat melakukan aritmatika dengan nyaman saat Anda menginginkannya. Regex dan pencarian akan mengembalikan indeks internal yang dibungkus, tetapi s[2] dapat memberikan karakter kedua terlepas dari berapa banyak byte yang digunakan untuk mengkodekan yang pertama.

Bisakah mereka membuat subarray/irisan AbstractArrays yang efisien, atau apakah implementasinya hanya berfungsi untuk blok memori yang berdekatan? Ini bukan masalah yang sangat sulit untuk dipecahkan jika Anda dapat menganggap array induk Anda memiliki memori yang berdekatan; itu menjadi lebih menarik ketika Anda tidak membuat asumsi itu.

Ya, itulah fitur utama yang kami cari: bukan hanya bahwa sesuatu dapat dilakukan dengan baik dengan beberapa fungsi pengiriman dan/atau bertahap, tetapi kurangnya fitur ini dalam bahasa lain membuat implementasi fitur menjadi lebih sulit (idealnya, begitu banyak lebih keras sehingga tidak ada yang mencobanya).

@timholy , array NumPy ditandai dengan langkah tetap untuk setiap dimensi, tidak harus kedekatan (pada dasarnya setara dengan DenseArray kami). Properti ini dipertahankan di bawah irisan, sehingga irisan itu sendiri dapat diiris dan sebagainya.

menyimpang memiliki beberapa pertanyaan bagus tentang IRC di sepanjang garis ini. Saya telah mencoba mengekstrak hanya sedikit komentar yang relevan (dari antara percakapan dan pemberitahuan yang tidak terkait) di bawah ini:

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

jika Anda mencari lebih banyak contoh: https://github.com/JuliaLang/julia/pull/7291

Pengurangan kode bersih bagus dari 6K C++ menjadi sekitar 1K Julia. Tolok ukur kinerja awal menunjukkan itu hanya di bawah 2x C++ asli.

berapa banyak bahasa yang Anda ketahui yang dapat mengklaim implementasi printf, dari operator (+-*/, Int, Float) hingga pemformatan output numerik, dalam bahasa itu sendiri, dan benchmark dalam margin kecil dari versi libc? Mungkin C++? C bahkan tidak dapat mengklaim ini (tidak memiliki kelebihan operator).

Python/MATLAB/dll. mungkin dapat mengklaim sedikit dari ini, tetapi apakah Anda pernah mencoba menggunakan operator string di MATLAB?

Ini adalah diskusi yang sangat menarik dan saya ingin menambahkan beberapa poin:

• Apa yang tampaknya tidak benar-benar dijawab adalah bagaimana Julia membandingkan dengan polimorfisme dalam C++ secara cepat. Dalam C++ seseorang dapat memiliki polimorfisme statis melalui templat atau polimorfisme dinamis melalui OO. Tetapi nanti membutuhkan vtable dan selalu sedikit lebih lambat, terutama saat memanggil hal-hal seperti itu dalam lingkaran yang ketat. Untuk alasan ini orang tidak akan membebani operator akses array karena ini tidak akan cepat. Eigen misalnya menggunakan polimorfisme statis.
• Di Julia tidak ada tujuan antara fungsi virtual dan non-virtual dan kami masih tidak memiliki penalti kinerja. Pemahaman saya adalah bahwa keuntungan besar adalah Julia dapat menghasilkan kode "on the fly" dan dengan demikian masih menghasilkan kode cepat di mana dalam runtime C++ berarti seseorang tidak dapat memodifikasi kode yang dihasilkan lagi. Selain itu di Julia kami dapat melakukan inlining saat runtime. Jadi tidak ada fungsi panggilan overhead. Dan di Julia kita tidak perlu memikirkan semua ini karena dilakukan secara otomatis
• Satu hal besar (sekali lagi) adalah: obat generik tanpa overhead dan tanpa semua rasa sakit yang dimiliki C++ (mencari waktu kompilasi) Ada berbagai metode cara mengimplementasikan obat generik dan IMHO Julia menggunakan model yang sama dengan C#, jadi ini mungkin tidak sepenuhnya baru (untuk tesis Jeff). Tapi tetap saya pikir ini bisa menjadi sesuatu untuk dibahas dalam tesis.

Betapa sulitnya menjelaskan seberapa efektif pengiriman ganda itu sendiri cukup menarik.

Senang kita berada di halaman yang sama sekarang. Ya, SubArray baru kami tidak bergantung pada memiliki langkah, juga tidak memerlukan pengindeksan linier (walaupun mereka dapat menggunakannya, dan melakukannya secara default jika itu efisien). Jadi mereka bekerja secara efisien untuk AbstractArray apa pun, dan mendukung tampilan "non-strided" ( Vector{Int} indexes) juga.

Untuk memperjelas, saya menyajikan SubArray baru kami terutama sebagai contoh fungsi bertahap, bukan pengiriman ganda. Yang mengatakan, skema saat ini akan berantakan pada langkah konstruksi tanpa pengiriman ganda: kami memanggil metode konstruktor yang sama sekali berbeda untuk slice(::AbstractArray, ::UnitRange{Int}, ::Int, ::Vector{Int}) dan slice(::AbstractArray, ::Int, ::UnitRange{Int}, ::UnitRange{Int}) , dll. Konstruktor tersebut dihasilkan oleh fungsi bertahap, tetapi kami perlu beberapa pengiriman agar sistem berfungsi.

Tanpa fungsi terpisah, konstruktor varargs harus menghadapi kenyataan bahwa mengulang entri dalam tupel indeks tidak stabil-jenis: untuk memproses indeks individu dalam satu lingkaran, Anda harus menetapkannya ke variabel skalar bernama, dan variabel itu adalah dijamin tidak akan diketik dengan baik meskipun input tuple bisa. Tentu saja, fungsi bertahap melakukan lebih banyak lagi: hampir semua keputusan "sulit" --- apakah kita menjatuhkan ini sebagai dimensi irisan, atau mempertahankannya, dan apa konsekuensinya untuk representasi internal objek? --- dapat dibuat pada waktu kompilasi, mengurangi konstruktor runtime menjadi operasi yang sangat sepele. Kebetulan bahwa operasi sepele tertentu berbeda untuk setiap kombinasi tipe input, jadi untuk mengeksploitasi hal sepele ini dan membuat konstruksi cepat, Anda perlu memanggil metode berbeda yang disesuaikan untuk setiap kombinasi tipe input. Inilah sebabnya mengapa Anda membutuhkan fungsi bertahap dan pengiriman ganda.

Secara pribadi, saya ragu apakah mungkin untuk melakukan apa yang telah kami lakukan tanpa kombinasi fungsi bertahap dan pengiriman ganda, dan kemungkinan julia sekarang memiliki tampilan array paling fleksibel dan efisien dari bahasa apa pun. Tetapi saya tidak berpura-pura telah melakukan studi aktual apa pun tentang masalah ini.

Ini membuat saya bertanya-tanya apakah saya harus menulis SubArrays kami untuk publikasi --- sepertinya kami memiliki sesuatu yang baru di sini.

@StefanKarpinski : Mari kita mengkritik diri sendiri: Mungkin kita belum menulisnya?

@timholy Saya benar-benar melihat dua hal di sini, fungsi yang dipentaskan (yang harus saya akui tidak sepenuhnya dipahami) dan bagaimana Julia cocok dengan fungsi virtual C++ vs template universe (C# dan Java serupa di sini).

Untuk perbandingan C++ akan sangat menarik untuk melakukan pengaturan waktu dan secara eksperimental membuktikan bahwa kita dapat mencapai waktu kompilasi polimorfisme (yang saya yakin kita lakukan)

Hal lain yang ingin saya rumuskan untuk beberapa waktu adalah bagaimana Julia membandingkan dengan C++ sehubungan dengan Konsep C++ (lite). Subtipe yang kami miliki adalah bagian besar dari Konsep C++.

Apakah seseorang bahkan perlu menulis banyak kode C++ dan menjalankan pengaturan waktu untuk memeriksa ini?

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

Pada dasarnya tidak ada apa-apa selain memuat dan menyimpan operasi (yaitu, akses memori) di sana.

@timholy Saya pikir ini layak untuk ditulis. Saya percaya (tetapi belum memverifikasi) bahwa banyak sistem yang mengimplementasikan array Nd memiliki implementasi khusus untuk beberapa dimensi pertama, dan kemudian secara umum kembali ke sesuatu yang lambat jika tidak, dan itu seharusnya tidak berlaku untuk implementasi baru.

Kasus terkait lainnya adalah menulis penyimpanan Nd jarang yang efisien (array menjadi kasus khusus yang umum).

tim,

ya memang melihat kode perakitan yang dihasilkan adalah alat yang hebat. Tapi tetap saja saya pikir ini harus dibandingkan dalam konteks yang lebih besar, di mana (dalam implementasi C++) fungsi virtual harus diperhitungkan.

Dugaan saya sebenarnya bukan multiple dispatch yang begitu cepat tetapi kita dapat inline saat runtime dan dengan demikian mengubah fungsi virtual (yang merupakan fungsi generik kita) menjadi instruksi yang efisien tanpa tipuan panggilan fungsi.

Jika ini benar (tolong perbaiki saya jika saya salah @JeffBezanson @vtjnash @stevengj @timholy ) kelipatan dalam multiple dispatch bukan alasan Julia beeing begitu cepat tetapi sisi yang rapi mempengaruhi bahwa kode tertentu dapat dirumuskan lebih bagus (di mana pengiriman tunggal membatasi)

Saya mungkin hanya tidak mengerti, tetapi saya tidak yakin dengan perbedaan yang Anda buat. Di Julia, "inline" dan "runtime" sepertinya tidak cocok; inlining dilakukan selama inferensi tipe, yaitu, pada waktu kompilasi. Beberapa pengiriman digunakan untuk memilih metode yang sesuai untuk jenis yang disimpulkan.

Kebingungan di sini adalah bahwa "waktu kompilasi" dan "runtime" dari C++ tidak dapat dibandingkan dengan Julia. Codegen dapat terjadi selama "runtime" jadi ya saya pikir ketika saya melakukan include("myscript.jl") inlining dilakukan. Dan bahkan jika "runtime" bukan kata yang tepat untuk itu dari perspektif C++, itu adalah "runtime".

Dan pengiriman pada jenis yang berbeda seperti vtable tetapi lebih umum, bukan?

Ini membuat saya bertanya-tanya apakah saya harus menulis SubArrays kami untuk publikasi --- sepertinya kami memiliki sesuatu yang baru di sini.

Ini agak jauh dari topik standar, tetapi Anda mungkin mempertimbangkan untuk mengirimkan ke JSS. Kami membutuhkan lebih banyak artikel Julia.

Saya akan senang jika Tim menulis posting blog untuk menjelaskan pekerjaan ini untuk memulai, karena ini akan membuat banyak orang lebih cepat. JSS adalah ide yang bagus, dan mungkin beberapa pekerjaan dasar yang telah dilakukan dalam kerangka data dan distribusi layak untuk ditulis juga? Saya pasti akan senang membacanya.

Nah, yang membuat saya berpikir adalah bahwa sebagian besar telah ditulis: http://docs.julialang.org/en/latest/devdocs/subarrays/. Untuk publikasi, Anda ingin membahas lebih banyak detail, tetapi ini cukup mengenai poin gambaran besar utama.

Untuk pertanyaan yang diajukan @stevenngj tentang beberapa pengiriman, saya akan mengatakan bahwa tanpa beberapa pengiriman, cukup sulit untuk menulis perpustakaan dasar kami di julia. Saya mengatakan apa yang sudah diketahui oleh semua orang di sini, dan bertanya-tanya apakah ini bukan contoh yang meyakinkan untuk alasan yang diangkat di sini.

Detail seperti operasi pada nomor dan konversi/promosi terkait erat dengan beberapa pengiriman. Karena beberapa pengiriman adalah yang pada dasarnya memaparkan inferensi tipe dalam kompiler dengan cara tipe digunakan dalam kode, kami dapat menulis pustaka dasar numerik yang generik dan cepat. Mengutip pernyataan yang Anda buat - ini membantu memisahkan pembuatan kebijakan dari kompiler dan ke dalam perpustakaan. Misalnya, @JeffBezanson pernah menunjukkan kepada saya bagaimana spesifikasi Skema menghabiskan 1/3 ruangnya untuk detail numerik.

Banyak sistem yang ditafsirkan seringkali berakhir dengan tipe umum dan memeriksa tipe objek mereka saat runtime untuk membuat keputusan tentang kode apa yang akan dieksekusi. Mereka kemudian sering memiliki implementasi terpisah di C/C++/Fortran di perpustakaan dasar untuk setiap jenis, yang mengarah ke basis kode yang besar dan sulit untuk di-debug. Seringkali ini dihasilkan melalui sistem makro eksternal, tetapi semakin banyak penggunaan template C++ telah menghindari masalah khusus ini. Masalah dua bahasa dan inferensi tipe masih tetap ada dalam kasus ini.

Pada tingkat tertentu, vektorisasi adalah berapa banyak bahasa ilmiah yang mengamortisasi biaya penentuan jenis saat runtime dan melakukan pemilihan kode yang sesuai. Di Julia, dengan kombinasi inferensi tipe, pengiriman ganda, dan pemrograman generik, biaya kami untuk keduanya jauh lebih rendah sehingga memungkinkan kami untuk menulis kode devectorized generik - C tanpa tipe.

Salah satu contohnya adalah perbandingan pertidaksamaan dengan MathConst (mewakili bilangan irasional) pada PR #9198:

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

• FloatingPoint vs MathConst membandingkan float dengan float di atas/di bawah konstanta
• Rational{T} vs MathConst (untuk tipe integer terbatas T ) menemukan rasional terdekat yang dapat diwakili oleh tipe; kemudian berdasarkan apakah di atas atau di bawah tipe irasional sejati.

Apa yang membuat ini layak adalah akses mudah ke fungsionalitas Rational dan BigFloat pada waktu kompilasi. Meskipun dimungkinkan menggunakan sesuatu seperti praprosesor makro, pada dasarnya itu akan membutuhkan dua implementasi dari semua fungsi.

Saya memiliki pembaruan kecil tentang masalah ini. Dokumen sekarang terbuka untuk umum: https://github.com/JeffBezanson/phdthesis

Hari ini saya merilis semacam draf dengan tenggat waktu yang ditentukan sendiri. Ini tidak banyak konsep; banyak bagian yang hilang sama sekali. Saya juga mengklaim tidak bertanggung jawab atas apa pun yang ada di dalam komentar TeX, atau hanya ada di riwayat versi sebelumnya :)

Semua umpan balik diterima! Khususnya, jika Anda memiliki contoh kode julia yang bagus yang menunjukkan bahasa dengan baik, terutama apa pun yang sulit dilakukan tanpanya. Selalu mencari contoh pengiriman ganda non-sepele yang bagus.

Terima kasih telah membuat ini menjadi publik. Saya terkejut ketika saya mencoba mengikuti tautan yang digunakan SGJ dan mencapai 404.

Mungkin aritmatika matriks segitiga bisa menjadi contoh kegunaan multiple dispatch Julia. Di sini UpperTriangular+UpperTriangular=UpperTriangular , tetapi UpperTriangular+LowerTriangular=Matrix .

Kami juga berbicara tentang promosi jenis elemen. Saya suka bahwa Anda dapat menghindari promosi ketika tidak diperlukan, misalnya

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

Saya tidak bisa mengatakan seberapa spesifik ini untuk Julia, tetapi seperti yang kita lihat, tampaknya setidaknya Eigen tidak akan mengelola promosi, tetapi mengharuskan jenis elemen stabil di bawah operasi aljabar linier.

Jeff akan memasuki tahap terakhir sekarang, kami berharap, jadi umpan balik dan koreksi untuk tesisnya (lihat repositori github yang disebutkan di atas) akan sangat diterima sekarang.

Jangan ragu untuk mengirimkan PR untuk kesalahan ketik, referensi yang hilang, dll.

@stevenngj Haruskah kita mengharapkan pengumuman jadwal pertahanan di sini?

Ya.

Saya harap dia sudah mendapatkan pekerjaan di MIT... (atau di mana pun dia akan melanjutkan pekerjaan Julia yang hebat)... membaca tesisnya sekarang... hal-hal hebat, IMO!

@andreasnoack Sedikit esoteris, tapi tetap lucu: Tentukan jenis cincin matriks panah dan terapkan faktorisasi Cholesky dari basis untuk melihat seperti apa struktur faktorisasi cholesky dari matriks panah matriks panah. https://Gist.github.com/mschauer/c325ff89cd378fe7ecd6 ("A" Panah matriks, "F" matriks penuh, "L" Setengah panah bawah").

@ScottPJones terima kasih!!

Pertahanan dijadwalkan: Rabu 13 Mei, 1 siang Stata D-463.

@JeffBezanson apakah Anda berencana untuk merekamnya melalui replay.csail.mit.edu?

...mungkin aku lebih suka melupakannya... :)

Bukankah itu gunanya kotak centang terakhir?

Apakah Anda _benar-benar_ yakin harus memberikan alamatnya? Anda mungkin dikerumuni oleh para penggemar, yang ingin menandatangani salinan tesis Anda! :nyengir:

Saya sudah mendapatkan tiket saya. Saya mendengar harganya sudah mencapai $800 di pasar gelap.

Stata D-463 tidak ada di hari saya... (Saya hanya ke sana untuk mengunjungi teman dan untuk Hari Database NE)... Apakah itu akan cukup besar? Tentunya dia akan membutuhkan 10-250!

Secara resmi D-463 muat 48 kursi. Jika menurut kami itu tidak cukup, kami bisa mencari kamar yang lebih besar.

Saya benar-benar tidak berpikir Anda benar-benar menghargai apa yang telah Anda lakukan! Jika semua penggemar Anda muncul, mungkin 10-250 tidak akan cukup besar... pesan Kresge sekarang!

Abstraksi dalam Komputasi Teknis

• Kandidat PhD: Jeff Bezanson
• Pembimbing Skripsi: Prof. Alan Edelman
• Panitia Tesis: Prof. Steven Johnson, Prof. Saman Amarasinghe, Prof. Gerry Sussman
• Tanggal : Rabu 13 Mei 2015
• Waktu: 1 siang
• Lokasi: Kampus MIT, 32-D463

_Lingkungan pemrograman berbasis array populer untuk komputasi ilmiah dan teknis. Sistem ini terdiri dari pustaka fungsi bawaan yang dipasangkan dengan bahasa tingkat tinggi untuk interaksi. Meskipun perpustakaan berkinerja baik, diyakini secara luas bahwa skrip dalam bahasa ini pasti lambat, dan bahwa hanya prestasi rekayasa yang heroik yang dapat memperbaiki sebagian masalah ini._

_Skripsi ini berpendapat bahwa yang benar-benar dibutuhkan adalah struktur yang lebih koheren untuk fungsi ini. Untuk menemukannya, kita harus bertanya tentang apa sebenarnya komputasi teknis itu. Tesis ini menunjukkan bahwa jenis pemrograman ini dicirikan oleh penekanan pada kompleksitas operator dan spesialisasi kode, dan bahwa suatu bahasa dapat dirancang agar lebih sesuai dengan persyaratan ini._

_Ide kuncinya adalah mengintegrasikan kode_ _seleksi _ _dengan kode_ _spesialisasi _, _menggunakan fungsi generik dan inferensi tipe aliran data. Sistem seperti ini dapat mengalami kompilasi yang tidak efisien, atau dari ketidakpastian tentang apa yang menjadi spesialisasi. Kami menunjukkan bahwa pengiriman berbasis tipe yang cukup kuat mengatasi masalah ini. Bahasa yang dihasilkan, Julia, mencapai "penjelasan dengan penghapusan" gaya Quine dari banyak fitur produktif yang diharapkan pengguna komputasi teknis._

Apakah akan ada salinan cetak tesisnya yang tersedia untuk penonton?

Mungkin salinan yang ditandatangani

Itulah yang saya harapkan... Saya pikir saya bisa mendapatkan banyak uang di Ebay dengan menjual salinan bertanda tangan dalam 10-15 tahun (ketika saya benar-benar membutuhkannya untuk membayar pendidikan perguruan tinggi anak-anak saya... khususnya. jika mereka pergi ke tempat yang mereka katakan ingin pergi ... : nyengir: )

Semoga beruntung, Jeff!

Semoga beruntung! Jika saya berada di area tersebut, saya akan menjadi salah satu fanboy yang disebutkan @ScottPJones

@ScottPJones :+1:

Patah kaki, Jeff!

Semoga beruntung, Jeff!

Semoga beruntung! @JeffBezanson

@JeffBezanson Semoga Sukses!!

Semoga saya dapat tempat duduk.

semoga beruntung

Saya mengatakan kepadanya bahwa dia seharusnya memesan 10-250!

dikirim dari iPhone saya

Pada 13 Mei 2015, pukul 11:53, Yichao [email protected] menulis:

@JeffBezanson Semoga Sukses!!

Semoga saya dapat tempat duduk.

—
Balas email ini secara langsung atau lihat di GitHub.

Semoga beruntung!

Dito!

Untungnya saya masuk cukup awal untuk mendapatkan tempat duduk... dan saya benar (seperti biasa : nyengir:) dia seharusnya memesan kamar yang lebih besar!

Selamat

Tetap.

Masih ada satu kotak centang yang tidak dicentang. Lebih baik bekerja.

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

:jempolan:

Selamat, Dr. Bezanson!

Selamat, Jeff!

+1

Bravo

kotak centang terakhir telah diisi sekarang dengan Wiski Bourbon Kentucky.

Selamat Jeff!

Pada hari Rabu, 13 Mei 2015 pukul 13:44, Mike Nolta [email protected]
menulis:

+1

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -101772806.

Selamat!

Selamat Jeff! :bir: :bir: :senyum:

Ini luar biasa! Selamat, Jeff. :kembang api:

Kabar baik. Selamat, Jeff!

Selamat!

Selamat

Woop woop selamat Jeff!

Selamat, Dr. Bezanson!

Terima kasih telah memposting fotonya, @ScottPJones. @jiahao , saya pikir Anda punya beberapa foto juga?

Selamat Jeff. Pekerjaan Anda yang berakhir di PHD ini telah mempengaruhi banyak dari kita. Ini akan dan sudah memiliki dampak besar pada komputasi ilmiah! Tetap semangat!

Selamat.

Besar!

Selamat Jeff!!

Fantastis, selamat!!

Selamat Dr. Bezanson!

Tesis, bagi mereka yang ingin mengintip:

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

Selamat!

Selamat!

Selamat!

Selamat :+1:

Saya tidak tahu mengapa GitHub memutuskan untuk memutar semua gambar saya, tetapi ini dia.

Video upacara penutupan masalah: http://youtu.be/hGpLOZX6CEY

Aleph-zero selamat untukmu, Jeff! Jika Anda pernah di Seattle, izinkan saya membelikan Anda minuman ucapan selamat. :)

Selamat Jeff. Rasanya sangat menyenangkan untuk merayakan pekerjaan Anda sebagai sebuah komunitas.

Selamat!

@jiahao , mungkin ada baiknya menjalankan kembali dunia terbaru Julia sebagai bahan pelengkap untuk halaman ucapan terima kasih :)

Terima kasih semuanya.

Sayangnya skripsi saya belum jadi, tapi mudah-mudahan bisa segera...

Saya punya beberapa foto lagi, saya akan mengirimkannya ke Jeff setelah saya bangun (untuk ibunya, wanita yang sangat baik!) _Dr._ Bezanson dapat mempostingnya di sini jika dia mau...

Belum selesai??? Apakah Gerry meminta Anda untuk menghapus semua "sintaks" berdarah itu dan membiarkannya menulis dengan ekspresi-s?

@JeffBezanson menggunakan mac bukanlah gambar yang pernah saya harapkan untuk dilihat!

Ya!

Selamat

Selamat dari semua penggemar Anda di sisi kolam ini.

Belum selesai??? Apakah Gerry meminta Anda untuk menghapus semua "sintaks" berdarah itu dan membiarkannya menulis dengan ekspresi-s?

Kamu berhasil! Aku tidak bercanda. Tapi dia akan menerima mode s-expr opsional.

Saya telah berbicara dengannya setelah presentasi... dia menyukai barang-barang Anda, tetapi benar-benar tidak peduli dengan semua sintaksnya... hanya ada _begitu_ banyak... dia mengingatkan saya betapa kecilnya manual Skema : nyengir: Ketika saya memilikinya untuk 6.001 [semester pertama diajarkan], kami harus menerapkan juru Skema kecil di MacLisp... karena Skema sangat kecil, itu cukup bisa dilakukan...

dan saya yakin Anda dapat menyelesaikannya dengan cukup cepat, dengan sebotol bourbon untuk ditemani (jika ada yang tersisa! ;-))

Berbicara tentang panjang manual skema, itu lucu: sebagian besar dikhususkan untuk mendokumentasikan perilaku angka, sementara di Julia itu didefinisikan di perpustakaan. Julia berpotensi menjadi bahasa inti yang lebih kecil daripada skema (kecuali tentu saja Anda menstaples spesifikasi LLVM ke dalamnya).

Untuk itu atau menentangnya, ada terlalu banyak penekanan pada sintaks! Lihat juga bagian 7.1 dari http://www.schemers.org/Documents/Standards/R5RS/HTML/. Sintaks skema lebih kompleks daripada yang dipikirkan orang!

Julia berpotensi menjadi bahasa inti yang lebih kecil daripada skema (kecuali tentu saja Anda menstaples spesifikasi LLVM ke dalamnya).

Ya, Julia memiliki tulang yang bagus!

Saatnya menggali makro @sexpr yang lama?

Selamat atas kelulusan dan apa yang Anda dapatkan bersama Julia!

:kue: Selamat!

Selamat @JeffBezanson!

Selamat :)

:+1:

@boyers! Lama tidak bertemu!

Rindu kalian :)

Selamat!

Hanya sebuah pertanyaan: PDF tidak memiliki tautan di ToC atau indeks yang dapat dijelajahi dalam metadata pdf.
Mengapa begitu sulit bagi penulis kompiler lulusan MIT untuk menambahkan \usepackage{hyperref} dalam pembukaannya?

Itu karena Anda seharusnya membaca semuanya dan tidak hanya melompat-lompat. ;-)

Tapi ya, hyperref akan membuat ini lebih mudah diakses.

Saya berjanji untuk membaca semuanya jika Anda menambahkan tautan: P

Selamat. Kebebasan menunggu.

Selamat, Dr. Bezanson!

@nicola-gigante, Anda dapat membuat permintaan tarik: senyum:.

bisakah kita melobi untuk penghargaan disertasi terbaik?

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

Selamat!!!

@jpfairbanks - ide bagus! Itu harus diserahkan oleh penasihat tesisnya meskipun ... mengganggu Alan Edelman, saya pikir ...

Ya itu perlu nominasi oleh penasihat dan 5 surat dukungan. Berdasarkan
masalah ini saya pikir setidaknya 5 orang berpikir dia pantas mendapatkannya.

Apakah terbatas pada 5 surat dukungan? Juga, jumlah sebenarnya dari orang-orang yang berpikir dia pantas mendapatkannya setidaknya beberapa kali lipat lebih besar!

@JeffBezanson : Selamat!

@alanedelman : Saya pikir @jpfairbanks memiliki poin yang bagus, Jeff harus dinominasikan untuk Penghargaan Disertasi Doktor ACM .

@JeffBezanson Dilakukan dengan baik dan layak!

@ScottPJones "Selain itu, setidaknya 3, dan tidak lebih dari 5, harus disertakan surat pendukung dari para ahli di bidangnya yang dapat memberikan wawasan tambahan atau bukti dampak disertasi."

Mungkin Gerry akan menulis untuknya (setelah dia menambahkan mode s-expr!): nyengir:

Halaman depan Berita Hacker :-) Selamat, Jeff.

@nicola-gigante Anda benar, saya akan menambahkan hyperref.

Terima kasih untuk semua orang lagi. Semua penghargaan Anda adalah hadiah utama.

@jiahao Itu karena mereka memiliki data rotasi EXIF ​​yang tidak dipedulikan oleh browser. Sebagian besar waktu. Chrome hanya peduli dengan data EXIF ​​​​jika gambar adalah jendelanya sendiri. Klik kanan dan "Buka di tab baru" untuk melihat orientasi yang benar.

Anda dapat menggunakan stripper metadata EXIF ​​untuk melepasnya dan memutarnya dengan cara yang "tepat".

+1 untuk nominasi penghargaan disertasi ACM.

Batas waktu nominasi adalah 31 Oktober 2015.

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

Saya tidak suka bahwa ACM memerlukan transfer hak cipta kepada mereka dan hak publikasi eksklusif. Itu masih berharga dan bergengsi dalam hal apa pun.

Selamat!

Hak publikasi eksklusif!?! Saya punya dibs pada salinan bertanda tangan (atau dua ... perlu satu untuk dijual di e-bay dalam 10-15 tahun, yang lain untuk disimpan sendiri : nyengir :)... harus mendapatkannya sebelum dikunci oleh ACM!
(Tentu saja, itu mungkin berarti bahwa itu akan tersedia di perpustakaan digital ACM untuk anggota)

begitu disertasi diserahkan kepada saya untuk ditandatangani, saya memiliki setiap niat
nominasi disertasi untuk berbagai penghargaan :-)

Pada hari Minggu, 17 Mei 2015 jam 08:49, Scott P. Jones [email protected]
menulis:

Hak publikasi eksklusif!?! Saya punya dibs pada salinan bertanda tangan (atau
dua... perlu satu untuk dijual di e-bay dalam 10-15 tahun, satu lagi untuk disimpan sendiri [image:
:grinning:])... harus mendapatkannya sebelum dikunci oleh ACM!
(Tentu saja, itu mungkin berarti bahwa itu akan tersedia di ACM
perpustakaan digital untuk anggota)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -102801616.

Tidak ada komentar dari @JeffBezanson... Saya _berharap_ dia merayakan (lebih banyak mencentang kotak terakhirnya), dan belum dikunci di sebuah ruangan di suatu tempat oleh GJS sampai dia mendapatkan mode s-expr bekerja!

Selamat!

Selamat, @JeffBezanson!

(terlambat) Selamat!

Pembaruan: baru saja mengirimkan dokumen. Versi yang dikirimkan adalah https://github.com/JeffBezanson/phdthesis/tree/876be73a5aab9b034fac3eb9ea9d8f96713f786f .

Saya yakin itu kekurangan dalam banyak hal. Baiklah. Semoga tidak ada yang benar-benar buruk di sana.

Bagus. Selamat telah benar-benar menyelesaikan PhD Anda.

Selamat, Jeff! Prestasi besar. Saya yakin Anda senang ini sudah berakhir.

Saya telah menemukan bahwa tesis Anda mengisi beberapa lubang di dokumentasi Julia, jadi ini jelas akan sangat berguna. Semua dokumen datang dengan kekurangan; kita semua terkesan dengan kekuatannya! Selamat!

Dan terima kasih telah membagikannya!

Woot! Selamat atas terselesaikannya pembelaan dan tesis, dan semua karya lain yang mereka tandai dan wakili. Sangat menyenangkan memiliki tonggak sejarah ini untuk mengakui semua hal yang telah Anda capai. Saya harap Anda bangga!

@JeffBezanson Saya harap Anda berencana untuk mengambil cuti beberapa hari untuk bersantai dan merayakan, atau mungkin Anda berencana untuk merayakan dengan perbaikan sistem tipe atau sesuatu. :-)

Bagus bahwa pdf baru memiliki hyperref - bagi mereka yang ingin menjelajah. Kita juga harus memasukkannya ke dalam daftar publikasi julia.