Есть ли у Юлии надежда остаться в статистическом сообществе?

Я недавно прочитал сообщение от R-Bloggers, которое связывалось с этим сообщением в блоге от Джона Майлса Уайта о новом языке под названием Джулия . Джулия пользуется преимуществом компилятора, работающего точно в срок, который дает ему быстрое время выполнения и ставит его на тот же порядок скорости, что и C / C ++ (тот же порядок , но не такой быстрый). Кроме того, он использует ортодоксальные циклические механизмы, с которыми знакомы те из нас, кто начал программирование на традиционных языках, вместо операторов R и векторных операций.

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

Мои интересы байесовского характера, где векторизация часто невозможна. Конечно, последовательные задачи должны выполняться с использованием циклов и включать в себя тяжелые вычисления на каждой итерации. R может быть очень медленным в этих задачах с последовательным циклом, а C / ++ - это не прогулка в парке, чтобы писать. Джулия кажется отличной альтернативой написанию на C / ++, но она находится в зачаточном состоянии и ей не хватает многих функций, которые мне нравятся в R. Было бы разумно изучать Джулию как инструментальные средства вычислительной статистики, если бы она получила достаточную поддержку из сообщества статистики и люди начинают писать полезные пакеты для него.

Мои вопросы следуют:

1. Какими особенностями должна обладать Джулия, чтобы иметь очарование, делающее R фактическим языком статистики?

2. Каковы преимущества и недостатки обучения Джулии выполнению сложных вычислительных задач по сравнению с изучением языка низкого уровня, такого как C / ++?

Я думаю, что ключ будет в том, начнут ли разрабатывать библиотеки для Джулии. Хорошо видеть примеры игрушек (даже если это сложные игрушки), показывающих, что Джулия выдувает R из воды на заданиях, в которых плохо.

Но плохо выполненные циклы и алгоритмы с ручным кодированием - это не то, почему многие из моих знакомых, использующих R, используют R. Они используют его, потому что для почти любой статистической задачи под солнцем кто-то написал код R для него. R - это и язык программирования, и пакет статистики - в настоящее время Юлия только первая.

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

Я согласен со многими другими комментариями. «Надежда»? Конечно. Я думаю, что Джулия многому научилась из того, что R и Python / NumPy / Pandas и другие системы делали правильно и неправильно за эти годы. Если бы я был умнее, чем я, и хотел бы написать новый язык программирования, который в будущем станет основой для среды разработки статистики, он будет очень похож на Джулию.

Тем не менее, пройдет 5 лет, прежде чем на этот вопрос можно будет ответить задним числом. На данный момент у Юлии отсутствуют следующие критические аспекты системы статистического программирования, которые могли бы конкурировать с R для повседневных пользователей:

(список обновляется с течением времени ...)

• факультативно упорядоченные типы факторов
• большинство статистических тестов и статистических моделей
• грамотное программирование / поддержка воспроизводимого анализа
• R-класс, или даже черчение класса Matlab

Чтобы конкурировать с R, Джулия и пакеты дополнительных статистических данных должны быть достаточно чистыми и достаточно полными, чтобы умные непрограммисты, скажем, аспиранты по социальным наукам, могли разумно использовать его. Там чертовски много работы, чтобы добраться туда. Может быть, это произойдет, может быть, это будет шипеть, может быть, что-то еще (R 3.0?) Заменит это.

Обновить:

Julia теперь поддерживает DataFrames с отсутствующими данными / NA, модулями / пространствами имен, formulaтипами и model.matrixинфраструктурой, построением графиков (sorta), поддержкой базы данных (но пока не DataFrames) и передачей аргументов по ключевым словам. Также теперь есть IDE (Julia Studio), поддержка Windows, некоторые статистические тесты и поддержка даты / времени.

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

С data.frame очень сложно работать в интерактивном режиме - например, при вызове он распечатывает всю структуру данных, с синтаксисом $ сложно работать программно, запросы требуют избыточной собственной ссылки (т. е. DF[DF$x < 10]), соединения и агрегация неудобны. Data.table решает большинство этих неприятностей, но поскольку он не является частью базовой реализации, большая часть кода R не использует его возможности.

Панды в питоне страдают от тех же недостатков.

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

Я считаю, что если Джулия преуспеет в качестве среды анализа данных, необходимо приложить усилия для реализации операторов типа SQL (без багажа синтаксиса SQL) в удобном для пользователя типе данных таблицы.

Я могу подписаться под тем, что сказали Дирк и ЭпиГрад; но есть еще одна вещь, которая делает R уникальным языком в своей нише - система ориентированных на данные типов.

R специально разработан для обработки данных, поэтому он ориентирован на вектор и имеет такие вещи, как data.frames, факторы, NA и атрибуты.
Типы Юлии, с другой стороны, ориентированы на числовую производительность, поэтому у нас есть скаляры, четко определенные режимы хранения, объединения и структуры.

Это может выглядеть мягко, но каждый, кто когда-либо пытался делать статистику с MATLAB, знает, что это действительно больно.

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

Я вижу, как Джулия заменит Матлаба, что станет огромной услугой для человечества.

Чтобы заменить R, вам нужно учесть все, что упомянули Нил Дж, Харлан и другие, плюс еще один важный фактор, который, я не думаю, был учтен: простая установка приложения и его библиотек.

Прямо сейчас вы можете скачать двоичный файл R для Mac, Windows или Linux. Это работает из коробки с большим выбором статистических методов. Если вы хотите скачать пакет, это простая команда или щелчок мышью. Это просто работает.

Я пошел, чтобы загрузить Джулию, и это не просто. Даже если вы загружаете бинарный файл, вам нужно установить gfortran, чтобы получить нужные библиотеки. Я скачал исходный код и попытался, makeи это не помогло без действительно полезного сообщения У меня есть бакалавр и ученая степень в области компьютерных наук, поэтому я мог бы возиться и заставить его работать, если бы я был так склонен. (Я не.) Джо Статистик сделает это?

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

РЕДАКТИРОВАТЬ: Я хотел дурачиться с Джулией - это выглядит захватывающим. Две проблемы:

1) Когда я попытался установить дополнительные пакеты (забыли, как они называются в Julia), это не получилось из-за неясных ошибок. Очевидно, у моего Mac нет такого инструмента, как они ожидали. Мало того, что он терпит неудачу, но он оставляет вещи, которые я должен удалить вручную, иначе другие установки не удастся.

2) Они заставляют определенный интервал в строке кода. У меня нет подробностей передо мной, но это связано с макросами и отсутствием пробела между макросом и скобками, открывающими его аргументы. Такое ограничение действительно беспокоит меня, так как я разработал форматирование кода в течение многих лет и языков, и я фактически помещаю пробел между именем функции / макроса и открывающей скобкой. Некоторые ограничения форматирования кода, я понимаю, но пробел в строке?

Язык Юлии довольно новый; время в точечном освещении можно измерять неделями (хотя время его разработки, конечно, можно измерять годами). Теперь эти недели в центре внимания были очень захватывающими - посмотрите, например, на недавнюю беседу в Стэнфорде, где «это только что началось», - но то, что вы просите в плане более широкой инфраструктуры и поддержки пакетов, займет гораздо больше времени. материализовать.

Так что я бы продолжал использовать R и помнить о разработке альтернатив. В прошлом году много людей пошли вразрез с Clojure; В этом году Юлия - это новый аромат. Посмотрим, торчит ли он.

Брюс Тейт, автор книги «Семь языков за семь недель». Вот несколько мыслей. Я работаю над Юлией для продолжения книги. Следующее - только мое мнение после нескольких недель игры.

В игре две фундаментальные силы. Во-первых, у всех языков есть продолжительность жизни. R будет заменен когда-нибудь. Мы не знаем когда. Новые языки развиваются чрезвычайно трудно. Когда новый язык развивается, он обычно решает какую-то непреодолимую болевую точку.

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

Дело в том, что компьютерные архитектуры меняются, и чтобы воспользоваться ими, язык и его конструкции должны быть построены определенным образом. Взятие Джулии на параллелизм интересно. Он оптимизирует правильную вещь для такого языка: прозрачное распределение и эффективное перемещение данных между процессами. Когда я использую Джулию для типичных задач, карт и преобразований и тому подобного, я просто вызываю функции. Мне не нужно беспокоиться о сантехнике.

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

Другая особенность, которая поможет этому случиться, - это действительно макросы. Язык сейчас очень интенсивный. Макросы позволяют создавать более крупные и чистые строительные блоки. Смотреть на библиотеки интересно, но не рассказывать всей картины. Вам нужно посмотреть на рост библиотек. Траектория Джулии в значительной степени здесь.

Clojure интересен для некоторых, потому что нет технического языка, который делает то, что может R, поэтому некоторые обращаются к языку общего назначения, чтобы заполнить этот пробел. Я на самом деле большой поклонник. Но Clojure - довольно серьезное искажение мозга. Clojure будет там для программистов, которые должны заниматься техническими вычислениями. Это не будет для инженеров и ученых. Там слишком много, чтобы учиться.

Так что для меня Юлия или что-то в этом роде заменит R когда-нибудь. Это вопрос времени.

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

Большие преимущества Python

• богатый набор модулей (не только статистика, но и графические библиотеки, вывод в pdf и т. д.)
• языковые конструкции, которые вам в конечном итоге понадобятся (объектно-ориентированные конструкции, которые вам нужны в большом проекте; декораторы, замыкания и т. д., которые упрощают разработку)
• множество учебных пособий и большое сообщество поддержки
• доступ к mapreduce, если у вас есть много данных для обработки и вы не возражаете заплатить несколько копеек за запуск их в кластере.

Чтобы обогнать R, Джулию и т. Д., Python мог бы использовать

• разработка своевременной компиляции для ограниченного Python, чтобы дать вам больше скорости на одной машине (но mapreduce все же лучше, если вы можете выдержать задержку)
• более богатая статистическая библиотека

Джулия не примет R очень скоро. Проверьте Microsoft R открыть.

https://mran.revolutionanalytics.com/open/

Это расширенная версия R, которая автоматически использует все ядра вашего компьютера. Это тот же R, тот же язык, те же пакеты. Когда вы установите его, RStudio также будет использовать его в консоли. Скорость MRO даже быстрее, чем у Юлии. Я много работаю в тяжелых условиях и использую Джулию больше года. Я недавно переключился на R, потому что R имеет лучшую поддержку, а RStudio - отличный редактор. Джулия все еще находится на ранней стадии и, возможно, не догонит Python или R очень скоро.

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

Я не много слышал о потреблении памяти, просто скорость. Вся семантика R, передаваемая по значению, может быть болезненной, и это была одна критика языка (это отдельная проблема от того, сколько замечательных пакетов уже существует). Важное значение имеет хорошее управление памятью, а также способы работы с обработкой вне ядра (например, сопоставление массивов или таблиц в памяти numpy или формат xdf Revolution Analytics).). В то время как JIT-компилятор PyPy допускает некоторые впечатляющие тесты Python, потребление памяти может быть довольно высоким. Итак, у кого-нибудь еще есть опыт работы с Юлией и использованием памяти? Похоже, что в «альфа» версии Windows есть утечки памяти, которые, без сомнения, будут устранены, и я все еще жду доступа к Linux-боксу, чтобы самому поиграть с этим языком.

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

Тем не менее, область, в которой это может быть невероятно, - это язык программирования с оптимизированной скоростью, который менее болезненен, чем C / C ++. Если бы он был беспрепятственно связан с R (в стиле Rcpp), то он мог бы найти массу полезного для написания критичных по скорости сегментов кода. К сожалению, в настоящее время такой ссылки не существует:

https://stackoverflow.com/questions/9965747/linking-r-and-julia

Я новичок Джулии, и R компетентен. Пока что я нахожу Джулию интересной, она ориентирована на производительность и совместимость.

Инструменты GPU. Я хотел бы использовать CUSPARSE для статистического приложения. Результаты CRAN показывают, что там не так много. У Юлии есть привязки, которые пока работают без сбоев.

using CUSPARSE
N = 1000
M = 1000
hA = sprand(N, M, .01)
hA = hA' * hA
dA = CudaSparseMatrixCSR(hA)
dC = CUSPARSE.csric02(dA, 'O') #incomplete Cholesky decomp
hC = CUSPARSE.to_host(dC)

Инструменты HPC. Можно использовать кластер в интерактивном режиме с несколькими вычислительными узлами.

nnodes = 2
ncores = 12    #ask for all cores on the nodes we control
procs = addprocs(SlurmManager(nnodes*ncores), partition="tesla", nodes=nnodes)
for worker in procs
    println(remotecall_fetch(readall, worker, `hostname`))
end

Совместимость с Python. Есть доступ к экосистеме питона. Например, было легко узнать, как читать данные визуализации мозга:

import PyCall
@pyimport nibabel

fp = "foo_BOLD.nii.gz"
res = nibabel.load(fp)
data = res[:get_data]();

С совместимостью. Следующее генерирует случайное целое число, используя стандартную библиотеку C.

ccall( (:rand, "libc"), Int32, ())

Скорость. Думаю, я увижу, как пакет Distributions.jl против R rnorm - который, я полагаю, оптимизирован.

julia> F = Normal(3,1)
Distributions.Normal(μ=3.0, σ=1.0)

julia> @elapsed rand(F, 1000000)
0.03422067

В R:

> system.time(rnorm(1000000, mean=3, sd=1))
   user  system elapsed 
  0.262   0.003   0.266 

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

(1) Он начинает есть обед MATLAB. Пользователям MATLAB нравится синтаксис MATLAB, но они ненавидят почти все остальное. Медлительность, дорогостоящие лицензии, очень ограниченные способы работы со сложными структурами данных, которые не являются матрицами. Я помню одну цитату, в которой говорится, что «если Юлия заменит MATLAB, это будет огромной услугой для человечества». Пользователи MATLAB могут быстро овладеть навыками в Julia, и их поразит простота написания качественного кода, который делает гораздо больше, чем может сделать MATLAB (быстрые структуры, которые можно помещать в массивы и быстро выполнять итерации?). Мало того, что исследователи могут сделать серьезные наборы инструментов в Юлии (небольшая команда студентов-докторов наук написала пакет дифференциальных уравнений мирового класса), что было бы невозможно с MATLAB.

(2) Он начинает принимать исследования в области численных методов и моделирования. Массачусетский технологический институт оказывает поддержку Джулии, а исследовательское сообщество слушает его. Численное моделирование и новые численные методы - плохо определенные задачи, которые не имеют библиотек. Это где Юлия как язык сияет; если нет доступных библиотек, гораздо проще написать быстрый качественный код на языке Julia, чем на любом другом языке. Это будет язык чисел / симуляции, который пишется математиками для математиков (звучит похоже на R еще?)

(3) Произошел еще один прорыв в машинном обучении, который дает Юлии преимущество. Это немного подстановочный знак, который может не произойти. TensorFlow великолепен, но взломать его крайне сложно. Python уже начал показывать трещины, а TensorFlow начал использовать Swift (Джулия получила похвальное упоминание). Если произойдет очередной прорыв в машинном обучении, его будет проще реализовать и взломать в пакете Julia, таком как Flux.jl.

(4) Джулия начинает медленно догонять R, что займет некоторое время. Выполнение статистики в MATLAB является болезненным, но Juila уже намного опережает MATLAB с Distributions.jl. Дело в том, что рабочие процессы R могут быть легко переведены на Джулию. Единственным реальным преимуществом R является тот факт, что статистиками написано так много пакетов для статистиков. Этот процесс, однако, также легко сделать в Юлии. Разница в том, что Джулия работает быстро и вам не нужно использовать другой язык для повышения производительности (более «серьезные» R-пакеты написаны на таких языках, как C). Проблема с R заключается в том, что пакеты, написанные на R, слишком медленные, чтобы обрабатывать большие наборы данных. Единственная альтернатива - перевести пакеты на другой язык, что делает разработку на R более медленным процессом, чем Julia.

Меня интересует обещание лучшей скорости и легкого распараллеливания с использованием разных архитектур. По этой причине я, конечно, буду наблюдать за развитием Julia, но вряд ли буду использовать его, пока он не сможет обрабатывать обобщенные линейные смешанные модели, у него есть хороший универсальный пакет начальной загрузки, простой язык моделей для построения матриц проектирования, эквивалентный ggplot2 и широкий диапазон из алгоритмов машинного обучения.

Ни один статистик не может позволить себе иметь фундаменталистское отношение к выбору инструментов. Мы будем использовать все, что позволяет нам выполнять работу наиболее эффективно. Я предполагаю, что я буду придерживаться R еще несколько лет, но было бы приятно быть приятно удивленным.

Роскошь NA в R не обходится без штрафов за производительность. Если Юлия поддерживает NA с меньшим снижением производительности, то это становится интересным для сегмента сообщества статистики, но NA также требует значительных дополнительных усилий при использовании скомпилированного кода с R.

Многие из пакетов в R используют подпрограммы, написанные на унаследованных языках (C, Fortran или C ++). В некоторых случаях скомпилированные подпрограммы были разработаны вне R и позже использовались как основа для пакетов библиотеки R. В других процедурах сначала были реализованы на R, а затем критические сегменты переводились на скомпилированный язык, когда производительность была признана недостаточной. Джулия будет привлекательна, если ее можно будет использовать для реализации эквивалентных подпрограмм. Существует возможность спроектировать низкоуровневую поддержку NA таким образом, чтобы упростить обработку NA по сравнению с тем, что мы имеем сейчас при использовании R со скомпилированным кодом.

Огромное количество библиотек R представляет усилия многих пользователей. Это стало возможным, потому что R предоставил возможности, которые иначе были бы недоступны / недоступны. Чтобы Джулия стала широко использоваться, ей нужна группа пользователей, которые считают, что она делает то, что им нужно, гораздо лучше, чем альтернативы, которые стоят усилий, необходимых для предоставления самых простых вещей (например, графики, классов дат, NA и т. Д.). ) доступно на существующих языках.

Я буду честен, у меня нет опыта работы с R, но я работаю с большим количеством людей, которые считают, что это отличный инструмент для статистического анализа. Я имею опыт работы с хранилищами данных, и из-за легко распространяемой, но более стандартной модели программирования Джулии, я думаю, это может быть очень интересной заменой части преобразования традиционных инструментов ETL, которые, как правило, делают работу очень плохо, большинство из них не имеют возможности легко создавать стандартизированное преобразование или повторно использовать результаты преобразования, уже выполненного в предыдущем наборе данных. Выделяется поддержка строго определенных и типизированных кортежей, если я хочу построить куб OLAP, который в основном должен создавать более подробные кортежи (таблицы фактов) из уже рассчитанных кортежей, у сегодняшних инструментов ETL нет «строительных блоков», чтобы говорить об этом. может помочь, в прошлом эта отрасль обходила эту проблему различными способами, но есть и компромиссы. Традиционные языки программирования могут помочь, предоставляя централизованно определенные преобразования, и Джулия потенциально могла бы упростить нестандартные агрегации и распределения, распространенные в более сложных системах хранилищ данных.

Вы также можете использовать Джулию и R вместе. Есть интерфейс Julia-to-R . С этими пакетами вы можете играть с Джулией, вызывая R всякий раз, когда у нее есть библиотека, которая будет необходима.

У Джулии, без сомнения, есть все шансы стать мечтой опытных пользователей статистики, например, SAS, ее мощь заключается в многочисленных процессах, написанных на C - Джулия может дать вам пакеты с исходным кодом, с матрицами в виде встроенный тип данных без SAS / iml. Я не сомневаюсь, что статистики стекаются к Джулии, как только они поймут, на что способен этот щенок.

О да, Джулия довольно быстро обгонит R. И основными причинами будут «макросы», 95% языка реализовано на языке Julia, и его бесшумный, экономный синтаксис. Если у вас нет опыта работы с языками типа lisp, вы, возможно, еще не понимаете его, но вы очень быстро увидите, как интерфейс формулы R станет устаревшим и уродливым механизмом и будет заменен специализированными микроязыками моделирования, похожими на CL макрос цикла. Доступ к низкоуровневым ссылкам на объект также является большим плюсом. Я думаю, что R до сих пор не понял, что скрытие внутренних элементов от пользователя на самом деле усложняет, а не упрощает.

Как я вижу это сейчас (имея годы интенсивного использования R и только что прочитав руководство Джулии), главные недостатки Джулии в отношении R - отсутствие поддержки структурного наследования (это было преднамеренно). Система типов Юлии менее амбициозна, чем S4; он также поддерживает множественную диспетчеризацию и множественное наследование, но с уловкой - существует только один уровень конкретных классов. С другой стороны, я редко вижу иерархию классов в R глубже, чем 3 уровня.

Время покажет, но это будет быстрее, чем думает большинство пользователей R :)

Первые целевые случаи использования Юлии - это численные проблемы. По сути, вы можете разбить эти области анализа и вычислительной науки на науку о данных (управляемая данными) и науку о моделировании (управляемую моделью). Юлия в первую очередь имеет дело со случаями использования науки моделирования. Они также имеют дело со случаями науки о данных, но более медленно. R никогда не будет очень полезен для науки моделирования, но Джулия будет очень полезна для обоих через пару лет.

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