Чи є у Юлії надія на присутність у статистичному співтоваристві?

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

R нікуди не піде, навіть з такими приголомшливими таймінгами від Джулії. Він має широку підтримку в промисловості та численні чудові пакети, які можна робити майже будь-що.

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

Мої запитання випливають:

1. Які особливості потрібно мати Юлії, щоб мати привабливість, яка зробила R фактичною мовою статистики?

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

Я думаю, ключовим буде те, чи почнуть розробляти бібліотеки для Юлії чи ні. Все добре і добре бачити приклади іграшок (навіть якщо це складні іграшки), що показують, що Джулія видуває R з води при виконанні завдань R погано.

Але погано виконані цикли та закодовані вручну алгоритми - це не те, чому багато людей, яких я знаю, які використовують R, використовують R. Вони використовують його, оскільки майже для будь-якого статистичного завдання під сонцем хтось написав R-код для цього. R є і мовою програмування, і пакетом статистики - в даний час Юлія є лише першою.

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

Я погоджуюся з багатьма іншими коментарями. "Надія"? Звичайно. Я думаю, що Джулія багато чого навчилась із того, що R та Python / NumPy / Pandas та інші системи робили правильно та неправильно протягом багатьох років. Якби я розумніший за мене, і хотів написати нову мову програмування, яка була б підґрунтям для статистичного середовища розвитку в майбутньому, це було б дуже схоже на Юлію.

Це сказало, пройде 5 років, перш ніж на це питання можна буде відповісти заднім числом. На даний момент Джулії бракує таких критичних аспектів системи статистичного програмування, яка могла б конкурувати з R для щоденних користувачів:

(список оновлюється з часом ...)

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

Щоб конкурувати з програмами R, Julia та додатковими статистичними пакетами, необхідно мати достатньо чисту та повну, щоб розумні непрограмісти, скажімо, студенти з соціальних наук, могли розумно її використовувати. Добіг, щоб дістатися туди. Можливо, це станеться, можливо, воно зіпсується, а може, щось інше (R 3.0?) Замінить це.

Оновлення:

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

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

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 і очікувати широкого прийняття.

EDIT: Мені хотілося обдурити Юлію - це виглядає захоплююче. Дві проблеми:

1) Коли я спробував встановити додаткові пакети (забудьте, як їх називають у Джулії), це не вдалось із незрозумілими помилками. Очевидно, що в моєму Mac немає інструменту, подібного до виготовлення, який вони мали. Він не тільки не виходить з ладу, але й залишає речі, що лежать навколо, що я маю вручну видалити, або інші встановлення вийдуть з ладу.

2) Вони примушують певний пробіл у рядку коду. У мене немає деталей перед собою, але це пов'язано з макросами та відсутністю пробілу між макросом та дужкою, що відкриває свої аргументи. Таке обмеження насправді клопоче мене, оскільки я розробляв форматування коду протягом багатьох років та мов, і я фактично розміщую пробіл між назвою функції / макросу та вхідними дужками. Я розумію якісь обмеження щодо форматування коду, але пробіл у рядку?

Мова Джулії досить нова; час у світлі плями можна виміряти тижнями (навіть якщо час його розвитку можна, звичайно, виміряти в роках). Зараз ці тижні у світлі спокою були дуже хвилюючими тижнями --- дивіться, наприклад, нещодавню розмову в Стенфорді, де "вона нещодавно почалася" ---, але те, що ви просите в плані більш широкої інфраструктури та підтримки пакетів, займе набагато більше часу матеріалізуватися.

Тож я б продовжував використовувати R і пам’ятати про розвиваючі альтернативи. Минулого року багато людей пішли на гагу над Clojure; цього року панує новий аромат Джулії. Ми побачимо, чи приклеїться.

Брюс Тейт тут, автор семи мов через сім тижнів. Ось кілька думок. Я працюю над Джулією над книгою-підручником. Далі - лише моя думка після кількох тижнів гри.

У грі є дві основні сили. По-перше, всі мови мають тривалість життя. 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

Я новачок Джулії, і я компетентний. Причини, які я вважаю Julia цікавими поки що, орієнтовані на продуктивність та сумісність.

Інструменти 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 сумісність. Далі генерується випадкове ціле число, використовуючи стандартну бібліотеку C.

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

Швидкість. Думав, я побачу, як пакет Distributions.jl виконаний проти Rnorm R - який я вважаю оптимізованим.

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) Він починає перебирати дослідження чисельних методів та моделювання. MIT кидає свою вагу за Юлією, а науково-дослідна спільнота слухає MIT. Числові моделювання та нові числові методи - це неправильно визначені проблеми, у яких відсутні бібліотеки. Ось тут Юлія як мова світить; якщо в бібліотеці немає бібліотеки, писати швидку якість у Джулії набагато простіше, ніж будь-яку іншу мову. Це буде числова / імітаційна мова, яку математики написали для математиків (звук схожий на R ще?)

(3) Трапляється ще один прорив у машинному навчанні, який надає Юлії перевагу. Це трохи підстановка, яка може не статися. TensorFlow чудовий, але його зламати надзвичайно важко. Python вже почав демонструвати тріщини, а TensorFlow почав приймати Swift (Юлія отримала почесну згадку). Якщо відбудеться ще один прорив машинного навчання, буде набагато простіше реалізувати та зламати пакет Julia, такий як Flux.jl.

(4) Юлія починає повільно наздоганяти R, що займе певний час. Ведення статистики в MATLAB болісно, ​​але Джуйла вже випереджає MATLAB з дистрибуцією.jl. Справа в тому, що робочі потоки R можна легко перевести на Julia. Єдиною реальною перевагою R є те, що так багато пакунків написані статистиками для статистиків. Цей процес, однак, також легко зробити в Джулії. Різниця полягає в тому, що Джулія швидко просувається вниз і не потрібно використовувати іншу мову для виконання (більш "серйозні" R-пакети написані такими мовами, як C). Проблема з R полягає в тому, що пакети, написані на R, занадто повільні, щоб обробляти великі набори даних. Єдина альтернатива - перекласти пакунки на іншу мову, роблячи розвиток в R більш повільним процесом, ніж Юлія.

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

Жоден статистик не може дозволити собі фундаменталістське ставлення до вибору інструментів. Ми будемо використовувати все, що дозволяє нам зробити роботу найбільш ефективно. Я здогадуюсь, що я буду триматися з R ще кілька років, але було б приємно здивуватися.

Розкіш НС в R не обходиться без штрафних санкцій. Якщо Джулія підтримує НС з меншим покаранням продуктивності, то це стане цікавим для сегменту статистичної спільноти, але НС також накладають значну додаткову роботу при використанні складеного коду з R.

Багато пакетів на R покладаються на підпрограми, написані застарілими мовами (C, Fortran або C ++). У деяких випадках складені процедури розроблялися за межами R і пізніше використовувалися як основа для пакетів R бібліотеки. В інших підпрограми спочатку були реалізовані в R, а потім критичні сегменти були переведені на компільовану мову, коли продуктивність виявилася недостатньою. Julia буде привабливою, якщо її можна буде використовувати для реалізації еквівалентних процедур. Існує можливість спроектувати підтримку NA на низькому рівні таким чином, щоб спростити обробку NA над тим, що ми маємо при використанні R зі складеним кодом.

Велика кількість бібліотек R представляє зусилля багатьох багатьох користувачів. Це було можливо, оскільки R забезпечило можливості, які інакше не були доступними / доступними. Якщо Джулія стане широко використовуватися, їй потрібна група користувачів, які вважають, що вони роблять те, що їм потрібно набагато краще, ніж альтернативи, на які варто докласти зусиль, необхідних для постачання дуже основних речей (наприклад, графіки, класів дат, НС тощо). ) доступні з існуючих мов.

Я буду випереджати, я не маю досвіду роботи з R, але працюю з великою кількістю людей, які вважають, що це відмінний інструмент для статистичного аналізу. Моє переконання полягає у зберіганні даних, і завдяки легко розповсюдженій, але більш стандартній моделі програмування Джулії, я думаю, що це може бути дуже цікавою заміною для перетворення частини традиційних інструментів ETL, які, як правило, роблять цю роботу дуже погано, у більшості немає способу легко створювати стандартизоване перетворення або повторно використовувати результати перетворення, вже виконані на попередньому наборі даних. Підтримка чітко визначених і набраних кортежів виділяється, якщо я хочу створити куб OLAP, який в основному потребує створення більш детальних кортежів (таблиць фактів) з уже розрахованих кортежів, сьогоднішні інструменти ETL не мають "будівельних блоків", щоб говорити про це. може допомогти, ця галузь у минулому займалася цим питанням різними способами, але є компроміси. Традиційні мови програмування можуть допомогти, забезпечивши перетворення централізовано, і Юлія може потенційно спростити нестандартні агрегації та розподіли, поширені в складніших системах сховищ даних.

Ви також можете використовувати Julia та R разом. Є інтерфейс Julia-to-R . За допомогою цих пакетів ви можете грати з Джулією під час виклику R, коли у нього є бібліотека, яка потрібна.

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

О так, Юлія наздожене R досить швидко. І головними причинами будуть "макроси", 95% мови реалізовано в Джулії, і її безшумний, парсимонічний синтаксис. Якщо у вас немає досвіду роботи з типом мов lisp, ви можете його ще не зрозуміти, але ви досить швидко побачите, як інтерфейс формули R стане застарілим і потворним механізмом, і замінить його спеціалізованим моделюванням мікро-мов, схожих на CL цикл макросу. Доступ до посилань на об'єкт низького рівня - також великий плюс. Я думаю, що R все ще не зрозумів, що приховування внутрішніх даних від користувача насправді ускладнює, ніж спрощує речі.

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

Час покаже, але це буде швидше, ніж думає більшість користувачів R :)

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

Потрібно мати можливість застосовувати будь-яку функцію до великих наборів даних, які не поміщаються на пам’яті прозоро для користувача.
Це включає щонайменше запущені моделі змішаних ефектів, моделі виживання або MCMC на наборах даних, які вміщуються на диску, але не в пам'яті. І по можливості на наборах даних, що поширюються на декількох комп'ютерах.