Julia: Джефф Безансон, доктор философии

cc @fperez , который также заинтересован в этом нерешенном вопросе

Вспомогательная информация прилагается.

Из-за процедурной проблемы закрытие этого может потребовать работы в отдельном репозитории. Возможно, диссертацию следует включить в базу, чтобы другим было легче вносить свой вклад.

Также порядок последней задачи вводит в заблуждение; на самом деле это будет часто повторяться на протяжении всего процесса.

+1 за включение в Base или хотя бы в julia/doc/thesis . Или, может быть, theses для будущих нужд.

(Пожалуйста, откройте ветку диссертации, Джефф.)

Также порядок последней задачи вводит в заблуждение; на самом деле это будет часто повторяться на протяжении всего процесса.

*тоже уже повторилось

Я с нетерпением жду возможности присутствовать на церемонии _Закрытия выпуска_.

Я не могу воспроизвести эту проблему локально; это специфично для Массачусетского технологического института?

Один из основных авторов Julia, @JeffBezanson , стал проблематичным академическим разработчиком .

Это версия докторской диссертации на github? Джефф должен открыть PR со своим предложением, и комитет решит, объединяться или нет...

+Инф за быстрое решение этой проблемы!

У меня была такая же проблема в репозитории IPython несколько месяцев назад, надеюсь, она была исправлена ​​32 дня назад.
Я почти уверен, что это связано с кофе, надоедливой бумажной работой и изменением плана в последнюю минуту из-за отбойных молотков.

Удачи !

Обновлено: Джефф встретился со своим тезисным комитетом и дал нам приблизительный план.

Рад слышать, что прогресс есть!

Но git log --date=short --all --since=22.days.ago --author="Jeff Bezanson" до сих пор заставляет задуматься, откуда у него время на написание диссертации. Либо так, либо он супергерой. На самом деле, зачеркни это: мы все знаем, что он супергерой, так что не обращай внимания.

Коммиты с участием juliatypes.jl фиксируют наши попытки описать систему типов Джулии, которая имеет прямое отношение к дипломной работе.

Работа над системой шрифтов, кажется, уже бьет по нервам: https://twitter.com/plt_hulk/status/535045242920378369

Я немного сомневаюсь, что это прямой ответ на работу Джеффа, хотя я могу ошибаться. Веселый твит в любом случае.

@jiahao , мой комментарий был в основном ироничным --- я как бы задавался вопросом об этом. Я, например, обычно делаю много коммитов, когда полирую что-то для презентации.

@timholy отметил юмор. :)

Было бы упущением не упомянуть прекрасную дань уважения Магритту , сделанную и опубликованную в твиттере нашим сотрудником по локальной теории @jeanqasaur:

"Вероломство типов" звучит неплохо, не так ли?

Это довольно забавно.

Любить это!

Позовите на помощь: Джефф ищет хорошие примеры, которые демонстрируют множественную диспетчеризацию (и, возможно, поэтапные функции), вещи, которые были бы намного сложнее/медленнее в языках без этих функций.

есть, show ?

(и, возможно, поэтапные функции)

subarray.jl и subarray2.jl должны служить довольно хорошо. Дизайн-документ находится по адресу http://docs.julialang.org/en/latest/devdocs/subarrays/.

Я думаю, что пакет Distributions действительно делает множественную отправку полезной. Наличие таких вещей, как rand(Gamma(1, 1), 5, 5) по сравнению с rand(Normal(0, 1), 3) , — это огромный выигрыш в выразительности без ущерба для производительности из-за множественной диспетчеризации.

Я не понимаю, как это лучший пример, потому что он действительно хвастается
разовая отправка. Чем он отличается от Gamma(1,1).rand(5,5) , который вы
будет ли работать на более традиционном объектно-ориентированном языке, таком как Python или Java?

В пятницу, 19 декабря 2014 г., в 13:39, Джон Майлз Уайт, [email protected]
написал:

Я думаю, что пакет Distributions действительно делает многократную отправку
полезный. Имея такие вещи, как rand(Gamma(1, 1), 5, 5) vs rand(Normal(0, 1),
3) это огромный выигрыш в выразительности без потери производительности из-за
многократная отправка.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment-67678367 .

Ok. Замените это примерами вычисления KL-расхождений с использованием аналитических результатов: kl(Normal(0, 1), Normal(0, 1)) vs kl(Normal(0, 1), Gamma(1, 1)) .

Я должен был также добавить, что в моем первоначальном посте #8235 была некоторая потенциально полезная статистика о том, какой была бы жизнь _без_ поэтапных функций. Итоговое сообщение: генерация всех методов с помощью измерения 8 привела к > 5000 отдельных методов и потребовала более 4 минут времени на синтаксический анализ и понижение (т. е. 4-минутная задержка при компиляции julia). Для сравнения, реализация поэтапной функции загружается мгновенно и, конечно, может выйти за пределы 8 измерений.

По сравнению с единой отправкой он по-прежнему демонстрирует унификацию того, что другие языки OO описывают как: функции и методы. Вы можете сравнить с sorted(a) python и a.sort(). По сравнению с «традиционными» объектно-ориентированными языками, он резко меняет то, что означает, что функция «связана» с классом.

Вы могли бы указать, как это заменяет необходимость статических переменных вместо переменных экземпляра, поскольку вы можете отправлять экземпляр или тип. У меня могут появиться еще идеи из недавних IRC-разговоров, когда я смогу добраться до компьютера.

У меня есть реализация fmap . Это пересекает несколько массивов и
применяет функцию к каждому набору элементов. Эта реализация на самом деле
очень медленно, так как количество массивов может быть произвольным. Чтобы сделать это полезным,
Я вручную создал специализацию этого для различного количества
аргументы yss . Я всегда хотел написать для этого поэтапную функцию,
но еще не сделал этого.

Поэтапная функция должна будет оценивать, в частности, вызов map
который производит аргументы для f .

-Эрик

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

В пятницу, 19 декабря 2014 г., в 12:46, Стивен Дж. Джонсон <
уведомления@github.com> написал:

Зовите на помощь: Джефф ищет хорошие примеры, демонстрирующие несколько
диспетчеризация (и, возможно, поэтапные функции), вещи, которые были бы намного
сложнее/медленнее на языках без этих функций.

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment-67671331 .

Эрик Шнеттер [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

Извините, игнорируйте вызов eltype(f) в сигнатуре функции в моем коде,
это нестандартно.

-Эрик

В пятницу, 19 декабря 2014 г., в 15:08, Эрик Шнеттер [email protected]
написал:

У меня есть реализация fmap . Это пересекает несколько массивов и
применяет функцию к каждому набору элементов. Эта реализация на самом деле
очень медленно, так как количество массивов может быть произвольным. Чтобы сделать это полезным,
Я вручную создал специализацию этого для различного количества
аргументы yss . Я всегда хотел написать для этого поэтапную функцию,
но еще не сделал этого.

Поэтапная функция должна будет оценивать, в частности, вызов map
который производит аргументы для f .

-Эрик

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

В пятницу, 19 декабря 2014 г., в 12:46, Стивен Дж. Джонсон <
уведомления@github.com> написал:

Зовите на помощь: Джефф ищет хорошие примеры, демонстрирующие несколько
диспетчеризация (и, возможно, поэтапные функции), вещи, которые были бы намного
сложнее/медленнее на языках без этих функций.

Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment-67671331 .

Эрик Шнеттер [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

Эрик Шнеттер [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

@timholy , поскольку в Matlab и NumPy тоже есть подмассивы / срезы, почему мы можем утверждать, что здесь важна множественная отправка?

Простота реализации? Насколько я могу судить, вы можете имитировать множественную отправку на любом языке, так что это ни для чего не нужно.

Может быть, нехорошо предлагать что-то, чего мы еще не решили, что хотим. В https://github.com/JuliaLang/julia/issues/9297 есть предложение, которое позволяет нам иметь как эффективные позиции буфера UTF-8, так и удобную индексацию без дыр, чтобы вы могли выполнять удобную арифметику, когда захотите. Regex и search вернут обернутый внутренний индекс, но s[2] может дать второй символ независимо от того, сколько байтов было использовано для кодирования первого.

Могут ли они создавать эффективные подмассивы/срезы AbstractArrays или их реализация работает только для смежных блоков памяти? Это не очень сложная проблема, если вы можете предположить, что ваш родительский массив имеет непрерывную память; становится интереснее, когда вы не делаете этого предположения.

Да, это ключевая функция, которую мы ищем: не только то, что что-то можно сделать хорошо с помощью нескольких диспетчерских и/или поэтапных функций, но и то, что отсутствие этих функций в других языках значительно усложнило реализацию этой функции (в идеале, настолько сильно). сложнее, чем никто даже не пытался).

@timholy массив NumPy характеризуется фиксированным шагом для каждого измерения, не обязательно смежностью (фактически эквивалентно нашему DenseArray ). Это свойство сохраняется при нарезке, поэтому сами слайсы можно нарезать и так далее.

У aberrant было несколько хороших вопросов в IRC на эту тему. Я попытался извлечь только соответствующие фрагменты комментариев (из несвязанных разговоров и уведомлений) ниже:

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

если вы ищете дополнительные примеры: https://github.com/JuliaLang/julia/pull/7291

Сокращение чистого кода приятно с 6K C++ примерно до 1K Julia. Первоначальные тесты производительности показывают, что он чуть менее чем в 2 раза превосходит нативный C++.

сколько языков вы знаете, которые могут претендовать на реализацию printf, от операторов (+-*/, Int, Float) до числового форматирования вывода, на самом языке и тестов с небольшим отрывом от версий libc? Может С++? C даже не может заявить об этом (у него нет перегрузки операторов).

Python/MATLAB/и т. д. могли бы претендовать на части этого, но пытались ли вы когда-нибудь использовать строковые операторы в MATLAB?

Это очень интересное обсуждение, и я хотел бы добавить несколько моментов:

• На что, кажется, на самом деле не ответили, так это на то, как Джулия сравнивается с полиморфизмом в С++ по скорости. В C++ можно иметь статический полиморфизм через шаблоны или динамический полиморфизм через ООП. Но последний требует vtable и всегда немного медленнее, особенно при вызове таких вещей в узком цикле. По этой причине никогда нельзя перегружать оператор доступа к массиву, так как это не будет быстрым. Eigen, например, использует статический полиморфизм.
• В Julia нет места назначения между виртуальной и невиртуальной функцией, и у нас по-прежнему нет штрафов за производительность. Насколько я понимаю, огромное преимущество заключается в том, что Джулия может генерировать код «на лету» и, таким образом, по-прежнему генерировать быстрый код, тогда как в среде выполнения C++ это означает, что сгенерированный код больше нельзя изменить. Кроме того, в Julia мы можем выполнять встраивание во время выполнения. Таким образом, нет накладных расходов на вызов функции. А в Джулии нам не нужно думать обо всем этом, потому что это делается автоматически.
• Одна огромная вещь (опять же): дженерики без накладных расходов и без всей той боли, которую имеет С++ (смотря на время компиляции). Существуют разные методы реализации дженериков, и ИМХО Джулия использует ту же модель, что и С#, так что это может быть не совсем новым (для диссертацию Джеффа). Но все же я думаю, что это можно было бы обсудить в диссертации.

Насколько сложно объяснить, насколько эффективна множественная диспетчеризация, само по себе довольно интересно.

Рад, что мы сейчас на одной волне. Да, наши новые подмассивы не полагаются на наличие шагов и не требуют линейной индексации (хотя они могут ее использовать и делают по умолчанию, если она оказывается эффективной). Таким образом, они эффективно работают для любого AbstractArray, а также поддерживают "непереходные" (индексы Vector{Int} ) представления.

Чтобы пояснить, я представил наши новые подмассивы главным образом как пример поэтапных функций, а не множественной отправки. При этом текущая схема развалилась бы на этапе построения без многократной диспетчеризации: мы вызываем совершенно разные методы конструктора для slice(::AbstractArray, ::UnitRange{Int}, ::Int, ::Vector{Int}) и slice(::AbstractArray, ::Int, ::UnitRange{Int}, ::UnitRange{Int}) и т. д. Эти конструкторы генерируются поэтапными функциями, но мы необходимо несколько диспетчеризации для работы системы.

Без отдельных функций конструктор varargs должен столкнуться с тем фактом, что цикл по записям в кортеже индексов не является стабильным по типу: для обработки отдельных индексов в цикле вы должны присвоить их именованной скалярной переменной, и эта переменная гарантированно не будет хорошо типизированным, даже если входной кортеж может быть. Конечно, поэтапная функция делает намного больше: почти все «трудные» решения — отбрасываем ли мы это как нарезанное измерение или сохраняем его, и каковы последствия для внутреннего представления объекта? ---может быть выполнено во время компиляции, уменьшая конструктор времени выполнения до чрезвычайно тривиальной операции. Так уж получилось, что конкретная тривиальная операция отличается для каждой комбинации типов ввода, поэтому, чтобы использовать эту тривиальность и ускорить построение, вам нужно вызывать разные методы, настроенные для каждой комбинации типов ввода. Вот почему вам нужны как поэтапные функции, так и множественная диспетчеризация.

Лично я сомневаюсь, что было бы возможно сделать то, что мы сделали, без комбинации поэтапных функций и множественной диспетчеризации, и что, вероятно, julia теперь имеет самые гибкие и эффективные представления массивов из всех языков. Но я не претендую на то, что предпринял какое-либо реальное исследование этой проблемы.

Это заставляет меня задаться вопросом, должен ли я написать наши SubArrays для публикации --- кажется, у нас есть что-то новое здесь.

@StefanKarpinski : Давайте будем самокритичными: может быть, мы просто еще не написали об этом?

@timholy На самом деле я вижу здесь две вещи: поэтапные функции (которые, я должен признать, не полностью поняты) и то, как Джулия вписывается во вселенную виртуальных функций C ++ по сравнению с вселенной шаблонов (C # и Java здесь похожи).

Для сравнения C++ было бы очень интересно провести тайминги и экспериментально доказать, что мы можем достичь полиморфизма времени компиляции (что, я уверен, мы делаем)

Еще одна вещь, которую я хотел сформулировать в течение некоторого времени, - это то, как Джулия сравнивается с C ++ в отношении концепций C ++ (lite). Подтипы, которые у нас есть, составляют большую часть концепций C++.

Нужно ли вообще писать кучу кода на C++ и запускать тайминги, чтобы проверить это?

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

По сути, там нет ничего, кроме операций загрузки и сохранения (т. е. доступа к памяти).

@timholy Я думаю, стоит это написать. Я считаю (но не проверял), что многие системы, которые реализуют массивы Nd, имеют специализированные реализации для первых нескольких измерений, а затем обычно возвращаются к чему-то медленному в противном случае, и это не должно иметь место для новой реализации.

Другим связанным случаем является написание эффективного разреженного хранилища Nd (массивы являются обычным частным случаем).

Тим,

да, действительно, просмотр полученного ассемблерного кода - отличный инструмент. Но все же я думаю, что это нужно сравнивать в более широком контексте, где (в реализации C++) должны быть приняты во внимание виртуальные функции.

Я предполагаю, что на самом деле это не multiple dispatch , который так быстр, а то, что мы можем встроить во время выполнения и, таким образом, преобразовать виртуальную функцию (которой являются наши общие функции) в эффективную инструкцию без косвенного вызова функции.

Если это правда (пожалуйста, поправьте меня, если я ошибаюсь @JeffBezanson @vtjnash @stevengj @timholy ), множитель в multiple dispatch не является причиной того, что Джулия работает так быстро, а аккуратным побочным эффектом, позволяющим сформулировать определенный код приятнее (где одиночная отправка ограничивает)

Я, вероятно, просто не понимаю, но я не уверен в различии, которое вы проводите. В Джулии «встроенный» и «время выполнения», похоже, несовместимы; встраивание выполняется во время вывода типа, т. е. во время компиляции. Множественная отправка используется для выбора подходящего метода для выводимых типов.

Путаница здесь в том, что "время компиляции" и "время выполнения" С++ нельзя сравнивать с Джулией. Codegen может произойти во время «выполнения», поэтому да, я думаю, что когда я делаю include("myscript.jl") , выполняется встраивание. И даже если «время выполнения» не подходит для этого с точки зрения C++, это «время выполнения».

И диспетчеризация по разным типам похожа на vtable, но более общая, не так ли?

Это заставляет меня задаться вопросом, должен ли я написать наши SubArrays для публикации --- кажется, у нас есть что-то новое здесь.

Это немного далеко от стандартных тем, но вы можете подумать о том, чтобы отправить их на JSS. Нам нужно больше статей Юлии.

Я был бы рад, если бы Тим написал сообщение в блоге, чтобы описать эту работу для начала, так как это поможет многим людям войти в курс дела. JSS — отличная идея, и, возможно, некоторые из фундаментальных работ, которые были проделаны во фреймах данных и дистрибутивах, тоже стоит написать? Я бы конечно с удовольствием прочитал.

Ну, что заставило меня подумать об этом, так это то, что большая часть этого уже написана: http://docs.julialang.org/en/latest/devdocs/subarrays/. Для публикации вы хотели бы углубиться в детали, но это затрагивает значительное количество основных моментов общей картины.

На вопрос, поднятый @stevengj о множественной отправке, я бы сказал, что без множественной отправки довольно сложно написать нашу базовую библиотеку в julia. Я говорю то, что уже всем здесь известно, и задаюсь вопросом, не является ли это убедительным примером по причинам, изложенным здесь.

Такие детали, как операции над числами и преобразование/продвижение, неразрывно связаны с множественной отправкой. Поскольку множественная диспетчеризация — это то, что по существу делает вывод типа в компиляторе способом, которым типы используются в коде, мы можем написать общую и быструю числовую базовую библиотеку. Процитирую сделанное вами утверждение - оно помогает разделить политику, выходящую из компилятора, и в библиотеки. Например, @JeffBezanson однажды показал мне, как спецификация Scheme тратит 1/3 своего места на числовые детали.

Многие интерпретируемые системы часто заканчивают тем, что имеют общие типы и проверяют типы своих объектов во время выполнения, чтобы принять решение о том, какой код выполнять. Затем они часто имеют отдельную реализацию на C/C++/Fortran в базовой библиотеке для каждого типа, что приводит к большой и сложной для отладки кодовой базе. Часто они генерируются с помощью внешней системы макросов, но все чаще использование шаблонов C++ позволяет избежать этой конкретной проблемы. В этих случаях по-прежнему остается проблема двух языков и вывода типов.

На каком-то уровне векторизация — это то, как многие научные языки амортизируют затраты на определение типов во время выполнения и выполнение соответствующего выбора кода. В Julia, благодаря сочетанию вывода типов, множественной диспетчеризации и универсального программирования, наши затраты на оба метода значительно ниже, что позволяет нам писать универсальный девекторизованный код — C без типов.

Одним из примеров является сравнение неравенства с MathConst (представляющее иррациональные числа) в PR #9198:

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

• FloatingPoint vs MathConst сравнивает поплавок с поплавком выше/ниже константы
• Rational{T} vs MathConst (для ограниченных целочисленных типов T ) находит ближайшее рациональное представление, представляемое типом; затем в зависимости от того, находится ли он выше или ниже истинного иррационального типа.

Что делает это возможным, так это легкий доступ к функциям Rational и BigFloat во время компиляции. Хотя можно было бы использовать что-то вроде препроцессора макросов, для этого потребовались бы по существу две реализации всех функций.

У меня есть небольшое обновление по этому вопросу. Документ теперь открыт для публики: https://github.com/JeffBezanson/phdthesis .

Сегодня я выпускаю своего рода черновик к установленному мной сроку. Это не так много сквозняков; многие части полностью отсутствуют. Я также не несу ответственности за все, что находится внутри комментариев TeX или присутствует только в истории прошлых версий :)

Все отзывы приветствуются! В частности, если у вас есть хорошие примеры кода julia, которые хорошо демонстрируют язык, особенно то, что было бы трудно сделать без него. Всегда ищите хорошие нетривиальные примеры множественной отправки.

Спасибо, что сделали это достоянием общественности. Я был удивлен, когда попытался перейти по ссылке, которую использовал SGJ, и наткнулся на 404.

Возможно, арифметика треугольной матрицы может быть примером полезности множественной отправки Джулии. Здесь UpperTriangular+UpperTriangular=UpperTriangular , но UpperTriangular+LowerTriangular=Matrix .

Мы также говорили о продвижении типов элементов. Мне нравится, что вы можете избежать продвижения по службе, когда в этом нет необходимости, например

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

Я не могу сказать, насколько это специфично для Джулии, но, как мы видели, оказалось, что по крайней мере Eigen не будет управлять продвижением, а потребует, чтобы типы элементов были стабильны при операции линейной алгебры.

Мы надеемся, что сейчас Джефф подходит к финальной стадии, поэтому отзывы и исправления к его тезису (см. вышеупомянутый репозиторий github) будут особенно приветствоваться сейчас.

Не стесняйтесь отправлять PR за опечатки, отсутствующие ссылки и т. д.

@stevengj Должны ли мы ожидать объявления графика защиты здесь?

да.

Я надеюсь, что у него уже есть работа в Массачусетском технологическом институте... (или где-нибудь еще, где он продолжит великолепную работу Джулии)... сейчас читает свою диссертацию... отличный материал, имхо!

@andreasnoack Немного эзотерично, но в любом случае забавно: определите тип кольца матрицы стрелок и примените факторизацию Холецкого от основания, чтобы увидеть, как выглядит структура факторизации Холецкого стрелочной матрицы матриц стрелок. https://gist.github.com/mschauer/c325ff89cd378fe7ecd6 ("A" Стрелочная матрица, "F" полная матрица, "L" Нижняя половина стрелки").

@ScottPJones спасибо!!

Дата защиты: среда, 13 мая, 13:00, штат D-463.

@JeffBezanson , вы планируете записать это через replay.csail.mit.edu?

... может быть, я лучше забуду об этом ... :)

Разве не для этого последний флажок?

Вы _действительно_ уверены, что должны сообщить адрес? На вас могут напасть фанаты, которые хотят подписанные экземпляры вашей диссертации! :ухмыляясь:

У меня уже есть билеты. Я слышал, что цена на черном рынке уже доходит до 800 долларов.

Stata D-463 не было там в мое время... (Я был там только в гостях у друзей и на Дне базы данных NE)... Будет ли он достаточно большим? Наверняка ему понадобится 10-250!

Официально D-463 вмещает 48 стульев. Если мы думаем, что этого будет недостаточно, мы можем подумать о том, чтобы получить комнату побольше.

Я серьезно не думаю, что вы действительно цените то, что вы сделали! Если бы пришли все ваши фанаты, возможно, 10-250 человек было бы недостаточно... Забронируйте Kresge сейчас!

Абстракция в технических вычислениях

• Кандидат наук: Джефф Безансон
• Научный руководитель: проф. Алан Эдельман
• Диссертационный комитет: проф. Стивен Джонсон, проф. Саман Амарасингхе, проф. Джерри Сассман
• Дата: среда, 13 мая 2015 г.
• Время: 13:00
• Местонахождение: кампус Массачусетского технологического института, 32-D463.

Среды программирования на основе _Array популярны для научных и технических вычислений. Эти системы состоят из встроенных библиотек функций в сочетании с языками высокого уровня для взаимодействия. Хотя библиотеки работают хорошо, широко распространено мнение, что сценарии на этих языках обязательно медленны и что только героические инженерные подвиги могут в лучшем случае частично решить эту проблему.

_Этот тезис утверждает, что действительно необходима более последовательная структура для этой функциональности. Чтобы найти его, мы должны спросить, что на самом деле представляют собой технические вычисления. Этот тезис предполагает, что этот тип программирования характеризуется упором на сложность операторов и специализацию кода, и что язык может быть спроектирован так, чтобы лучше соответствовать этим требованиям._

_Основная идея заключается в интеграции кода_ _выбора _ _с кодом__специализацией_ , _используя универсальные функции и вывод типа потока данных. Подобные системы могут страдать от неэффективной компиляции или от неуверенности в том, на чем специализироваться. Мы показываем, что достаточно мощная диспетчеризация на основе типов решает эти проблемы. Получившийся в результате язык, Julia, обеспечивает «объяснение путем устранения» в стиле Куайна многих продуктивных функций, ожидаемых пользователями технических вычислений.

Будут ли печатные копии его диссертации доступны для зрителей?

Возможно подписанные копии

Это то, на что я надеюсь... Я думаю, что смогу получить большие деньги на Ebay, продавая копию с автографом через 10-15 лет (когда они мне действительно понадобятся, чтобы оплатить обучение моих детей в колледже... особенно. если они идут туда, куда они сказали, что хотят идти... :ухмыляется: )

Удачи, Джефф!

Удачи! Если бы я был в этом районе, я был бы одним из фанатов, которых упоминает @ScottPJones.

@ScottPJones :+1:

Сломай ногу, Джефф!

Удачи, Джефф!

Удачи! @ДжеффБезансон

@JeffBezanson Удачи!!

Надеюсь, я смогу занять место.

удачи

Я сказал ему, что он должен был заказать 10-250!

отправлено из моего Айфона

13 мая 2015 г., в 11:53, Ичао Юй, [email protected] , написал:

@JeffBezanson Удачи!!

Надеюсь, я смогу занять место.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Удачи!

То же самое!

К счастью, я пришел достаточно рано, чтобы занять место... и я был прав (как обычно :ухмыляясь:) ему действительно нужно было забронировать номер побольше!

Поздравления

Фиксированный.

Еще один флажок не установлен. Лучше займись делом.

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

:недурно:

Поздравляем, доктор Безансон!

Поздравляю, Джефф!

+1

Браво

последний флажок теперь заполнен виски Kentucky Bourbon.

Поздравляем Джеффа!

В среду, 13 мая 2015 г., в 13:44, Майк Нолта, [email protected]
написал:

+1

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment-101772806 .

Поздравляем!

Поздравляем Джеффа! :пиво: :пиво: :smile:

Это замечательно! Поздравляю, Джефф. :фейерверк:

Отличные новости. Поздравляю, Джефф!

Поздравляем!

поздравляю

Вуп-вуп поздравляю Джеффа!

Поздравляем, доктор Безансон!

Спасибо за публикацию фото, @ScottPJones. @jiahao , я думаю, у тебя тоже есть несколько фотографий?

Поздравляю Джефф. Ваша работа, завершившаяся докторской диссертацией, повлияла на многих из нас. Это окажет и уже оказывает огромное влияние на научные вычисления! Раскачать!

поздравления.

Здорово!

Поздравляю Джефф!!

Фантастика, поздравляю!!

Поздравляем доктора Безансона!

Тезис, для тех, кто хотел бы взглянуть:

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

Поздравляю!

Поздравляем!

Поздравляем!

Поздравляю :+1:

Не знаю, почему GitHub решил повернуть все мои картинки, но вот они.

Видео церемонии закрытия выпуска: http://youtu.be/hGpLOZX6CEY

Алеф-ноль поздравляю тебя, Джефф! Если ты когда-нибудь будешь в Сиэтле, позволь мне угостить тебя поздравительным напитком. :)

Поздравляю Джеффа. Очень приятно отмечать вашу работу как сообщество.

Поздравляем!

@jiahao , возможно, стоит повторно запустить последний мир Джулии в качестве дополнительного материала для страницы благодарностей :)

Спасибо всем.

К сожалению, моя диссертация еще не закончена, но, надеюсь, скоро будет...

У меня есть еще пара фотографий, я отправлю их Джеффу после того, как проснусь (для его мамы, очень милой дамы!) _Доктор_ Безансон может разместить их здесь, если захочет...

Не выполнено??? Джерри просил вас удалить весь этот чертов «синтаксис» и позволить ему писать с s-выражениями?

@JeffBezanson , использующий Mac, — это не та картина, которую я когда-либо ожидал увидеть!

Ура!

Поздравления

Молодцы все ваши поклонники по эту сторону пруда.

Не выполнено??? Джерри просил вас удалить весь этот чертов «синтаксис» и позволить ему писать с s-выражениями?

Ты сделал это! Я не шучу. Но он согласится на дополнительный режим s-expr.

Я разговаривал с ним после презентации... ему понравились ваши материалы, но на самом деле его не волновал весь синтаксис... его _так_ много... он напомнил мне, насколько маленькое руководство по схеме :grinning: Когда он у меня был на 6.001 [первый семестр его преподавали], нам пришлось реализовать небольшой интерпретатор Scheme в MacLisp... поскольку Scheme был таким маленьким, это было вполне выполнимо...

и я уверен, что вы можете довольно быстро выбить это, с этой бутылкой бурбона для компании (если она еще осталась! ;-))

Говоря о длине руководства по схеме, это забавно: большой процент его посвящен документированию поведения чисел, тогда как в Джулии это определено в библиотеках. Потенциально Джулия может быть меньшим базовым языком, чем схема (если, конечно, вы не прикрепили к нему спецификацию LLVM).

За или против, слишком много внимания уделяется синтаксису! Также ознакомьтесь с разделом 7.1 http://www.schemers.org/Documents/Standards/R5RS/HTML/. Синтаксис схемы сложнее, чем люди думают!

Потенциально Джулия может быть меньшим базовым языком, чем схема (если, конечно, вы не прикрепили к нему спецификацию LLVM).

Да, у Юли хорошие кости!

Пришло время раскопать старый макрос @sexpr ?

Поздравляю с выпуском и с тем, что вы вытащили с Юлией!

:торт: Поздравляю!

Поздравляем @JeffBezanson!

поздравляю :)

:+1:

@бойерс! Давно не виделись!

скучаю по вам ребята :)

Поздравляем!

Просто вопрос: у PDF нет ни ссылок в ToC, ни просматриваемого указателя в метаданных PDF.
Почему выпускнику Массачусетского технологического института так сложно добавить \usepackage{hyperref} в свою преамбулу?

Это потому, что вы должны прочитать все, а не просто пропустить. ;-)

Но да, гиперссылка сделает это намного более доступным.

Я обещаю вам прочитать все, если вы добавите ссылки: P

Поздравляем. Свобода ждет.

Поздравляем, доктор Безансон!

@nicola-gigante, вы можете сделать запрос на включение : smile:.

Можем ли мы лоббировать награду за лучшую диссертацию?

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

Поздравление!!!

@jpfairbanks - хорошая идея! Тем не менее, его должен представить его научный руководитель... приставать к Алану Эдельману, я думаю...

Да, это требует номинации советника и 5 писем поддержки. На основе
этот выпуск, я думаю, по крайней мере 5 человек считают, что он этого заслуживает.

Ограничено ли это 5 письмами поддержки? Кроме того, реальное количество людей, считающих, что он этого заслуживает, как минимум на несколько порядков больше!

@JeffBezanson : Поздравляю!

@alanedelman : Я думаю, @jpfairbanks прав , Джефф должен быть номинирован на премию ACM Doctoral Dissertation Award .

@JeffBezanson Молодец и заслуженно!

@ScottPJones «Кроме того, должны быть включены не менее 3 и не более 5 сопроводительных писем от экспертов в этой области, которые могут предоставить дополнительные сведения или доказательства влияния диссертации».

Может быть, Джерри напишет ему (после того, как он добавил режим s-expr! :grinning:

Первая страница Hacker News :-) Поздравляю, Джефф.

@nicola-gigante Вы правы, я добавлю гиперссылку.

Спасибо всем еще раз. Вся ваша признательность является высшим призом.

@jiahao Это потому, что у них есть данные о вращении EXIF, о которых браузеры не заботятся. Большую часть времени. Chrome заботится о данных EXIF ​​только в том случае, если изображение является его собственным окном. Щелкните правой кнопкой мыши и «Открыть в новой вкладке», чтобы увидеть их правильную ориентацию.

Вы можете использовать средство удаления метаданных EXIF, чтобы снять это и повернуть их «правильным» образом.

+1 за номинацию на премию ACM Dissertation Award.

Крайний срок выдвижения кандидатур – 31 октября 2015 года.

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

Мне не нравится, что ACM требует передачи им авторских прав и исключительных прав на публикацию. В любом случае это по-прежнему ценно и престижно.

Поздравляю!

Эксклюзивные права на публикацию!?! У меня есть бабки на копию с автографом (или две... одну нужно продать на e-bay через 10-15 лет, другую оставить себе :ухмыляется:)... нужно получить ее, пока ее не заблокировали АКМ!
(Конечно, это, вероятно, означает, что он будет доступен в цифровой библиотеке ACM для членов)

как только диссертация передана мне на подпись, у меня есть все намерения
номинирования диссертации на различные награды :-)

Вс, 17 мая 2015 г., 8:49, Скотт П. Джонс, [email protected]
написал:

Эксклюзивные права на публикацию!?! У меня есть бабки на копию с автографом (или
два... один нужно продать на e-bay через 10-15 лет, другой оставить себе [image:
:ухмыляясь:])... надо получить это до того, как оно будет заблокировано ACM!
(Конечно, это, вероятно, означает, что он будет доступен на ACM.
цифровая библиотека для участников)

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment-102801616 .

Никаких комментариев от @JeffBezanson... Я _надеюсь_, он празднует (больше отметьте его последний пункт), и GJS не заперт его где-нибудь в комнате, пока он не заработает в режиме s-expr!

Поздравляем!

Поздравляем, @JeffBezanson!

(с опозданием) Поздравляю!

Обновление: только что отправил документ. Представленная версия https://github.com/JeffBezanson/phdthesis/tree/876be73a5aab9b034fac3eb9ea9d8f96713f786f .

Я уверен, что он несовершенен во многих отношениях. Ну что ж. Надеюсь, там нет ничего страшного.

Хороший. Поздравляю с получением докторской степени.

Поздравляю, Джефф! Большое достижение. Уверен, ты рад, что все закончилось.

Я уже обнаружил, что ваша диссертация заполняет некоторые пробелы в документации Джулии, так что она явно будет весьма полезной. Все документы приходят с изъянами; остальные из нас впечатлены сильными сторонами! Поздравляю!

И спасибо, что поделились этим!

Уот! Поздравляю с окончанием защиты и диссертации, и всей другой работы, которую они значат и представляют. Приятно иметь эту веху, чтобы признать все, чего вы достигли. Я надеюсь, вы гордитесь!

@JeffBezanson Я надеюсь, вы планируете взять несколько выходных, чтобы расслабиться и отпраздновать, или, возможно, вы планируете отпраздновать капитальный ремонт системы типов или что-то в этом роде. :-)

Приятно, что в новом pdf есть гиперссылка - для тех, кто хочет просмотреть. Мы также должны включить его в список публикаций Джулии.