Pull to refresh

Comments 20

Убрать бы неудачный наброс на python и было бы прекрасное введение в julia без наброса на python.
А мне кажется это сравнение неизбежно, иначе не совсем понятно, зачем вообще нужна Julia.
В первую очередь, Джулия — язык от математиков для математиков.
Для математиков это скорее Wolfram Mathematica, Maple или на крайний случай Matlab. A в Julia математик может много всего странного написать.

В этом то и проблема Julia, на мой взгляд. Для математиков она не так проста, как позиционируется. А инженеры предпочитают более выразительные инструменты.
Можно подумать в вольфраме хрень не пишут. А области применения мапля и джулии примерно перпендикулярны.
UFO just landed and posted this here

Так Агду тайпчекают, а не запускают с JIT-компилятором.

Чтобы сделать Matlab бесплатным там, где Octave не справляется
Если я понял правильно, то по идеологии «Julia» это тоже самое что и «Python + Numba», только язык более современный. Но стиль разработки научного кода не слишком то и различается. Мы сначала пишем прототип, а если нужна производительность расставляем типы, что позволяет выполнить эффективную JIT компиляцию.

Но вот тут то и кроется проблема для широкого применения языка. Если от Python сразу ожидают медленной скорости и знают приемы как ее преодолеть, то от Julia сразу ожидают высокой производительности. А это не всегда работает. Например вот в этой статье habr.com/ru/post/483864 реализация Python + Numba была в два раза быстрее реализации от Julia.

Таким образом мы имеем Python мир, в котором собрано уже все, что может быть в мире вычислений. Да и проблемы с производительностью уже в прошлом, по большому счету.

С другой стороны есть развивающийся мир Julia, в котором все вроде бы более красиво и чисто. Но… Автоматом все-равно быстро то не работает, нужно также думать как оптимизировать код. Да и библиотек маловато.

В результате под данным TIOBE Julia за 2019 год опустилась в рейтинге языков с #37 до #47 места, что грустно.
Таким образом мы имеем Python мир, в котором собрано уже все, что может быть в мире вычислений.

Тут «вычисления» как-то слишком широко получились. Численного анализа в питоне почти нет, если сравнивать с джулией.

Автоматом все-равно быстро то не работает, нужно также думать как оптимизировать код.

В питоне автоматом тоже ничего не работает, там надо или njit расставлять, или векторизовать, или типы прописыать.
Тут «вычисления» как-то слишком широко получились. Численного анализа в питоне почти нет, если сравнивать с джулией.
Ну как сказать… Вот, например, потрясающая библотека на Python quadpy, где собраны более 1500 методов численного интегрирования. Пока такого в Julia я не встречал. Или библиотека cvxopt, одна из важнейших библиотек для решения задач Конвексной оптимизации. Интересно, что реализация на Julia вызывает реализацию на Python через PyCall.
В питоне автоматом тоже ничего не работает, там надо или njit расставлять, или векторизовать, или типы прописыать.
Ну в питоне то к этому все готовы изначально. А вот Julia позиционируется двусмысленно. С одной стороны типы необязательны. Но если вы хотите быстрый код, но нужно писать уже по другому. Сделали бы тогда типы обязательными.
Например, я для питона не нашёл ни нормальных решаталей ДУ, ни крыловских методов.

Вот, например, потрясающая библотека на Python quadpy, где собраны более 1500 методов численного интегрирования

Признаюсь, понятия не имею, когда нужно столько вместо «обычных» квадратур. Наверное, ведут исследования, как улучшить Кленшоу-Кёртиса, но я этим не интересуюсь.

Интересно, что реализация на Julia вызывает реализацию на Python через PyCall.

Там же написано, что это интерфейс. Для джулии есть Convex, например.

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

Там и там придётся читать доки.
Там и там придётся читать доки.
Только доки по Python уже прочитаны и применены на практике. И в чем тогда смысл начинать все сначала (да еще и с не меньшими сложностями)?
Никакого. Поэтому мэтры до сих пор пишут на фортране77 и не парятся.
backpropagation и использовать в любом алгоритме, который тренируется градиентным спуском… Любая, самая безумная архитектура становится возможна.

Ну вот когда они правила хотя бы для stdlib допилят, тогда можно будет, наверное. Не STS AD, конечно, не умеет строки дифференцировать, но всё остальное почти как из коробки,
[...] для веб-сервисов — не очень. Применять Julia вместо Django [...]

Если речь идет именно про веб-сервисы, то Genie.jl вполне неплохо справляется. А Django для веб-сервисов — наоборот, слишком швейцарсконожен.

в Jupiter последнее not defined:
model = Chain(Dense(768, 128, relu), Dense(128, 10), softmax)
UndefVarError: Dense not defined

Stacktrace:
[1] top-level scope at In[6]:1

loss(x, y) = crossentropy(model(x), y) + sum(norm, params(model))
loss (generic function with 1 method)
optimizer = ADAM(0.001)
UndefVarError: ADAM not defined

Stacktrace:
[1] top-level scope at In[8]:1

Flux.train!(loss, params(model), data, optimizer)
UndefVarError: Flux not defined

Stacktrace:
[1] top-level scope at In[9]:1

model = Chain(x -> sqrt(x), x->x-1)
UndefVarError: Chain not defined

Stacktrace:
[1] top-level scope at In[10]:1

… что нужно, чтобы заработало?
З.Ы. Нашел.
Добавляем:
import Pkg; Pkg.add(«Flux»)
using Flux

P.P.S. Поправил и перечитал ваш кусок выше, не явно это вы и написали, указав что это библиотека Flux.jl
А в чем проблема писать на Julia веб-сервисы? Множественная диспечерезация и метапрограммирование там тоже полезны (можно вспомнить Common Lisp и Пола Грэма). Каких-то специализированных библиотек не хватает?
>а для веб-сервисов — не очень
А почему, собственно?
Sign up to leave a comment.