Czy Julia ma jakąkolwiek nadzieję na pozostanie w społeczności statystycznej?

Niedawno przeczytałem post od R-Bloggerów, który zawiera link do tego postu na blogu od Johna Mylesa White'a na temat nowego języka o nazwie Julia . Julia korzysta z kompilatora „just-in-time”, który zapewnia niesamowity szybki czas działania i ustawia go na tym samym rzędzie wielkości co C / C ++ (ta sama kolejność , nie tak szybko). Ponadto wykorzystuje ortodoksyjne mechanizmy zapętlania, które znają ci z nas, którzy rozpoczęli programowanie w tradycyjnych językach, zamiast instrukcji R i operacji wektorowych.

R nie ustępuje w żaden sposób, nawet przy tak niesamowitych momentach od Julii. Ma szerokie wsparcie w branży i wiele wspaniałych pakietów do zrobienia wszystkiego.

Moje zainteresowania mają charakter bayesowski, wektoryzacja często nie jest możliwa. Z pewnością zadania seryjne muszą być wykonywane za pomocą pętli i wymagają intensywnych obliczeń przy każdej iteracji. R może być bardzo powolny w tych szeregowych zadaniach pętli, a C / ++ nie jest spacerem do pisania w parku. Julia wydaje się świetną alternatywą dla pisania w C / ++, ale jest w powijakach i brakuje jej wielu funkcji, które uwielbiam w R. Sensowne byłoby uczyć się Julii jako warsztatu statystyki obliczeniowej, jeśli uzyska wystarczające wsparcie od społeczności statystyk i ludzie zaczynają pisać przydatne pakiety dla tego.

Moje pytania są następujące:

1. Jakie cechy musi mieć Julia, aby mieć urok, który sprawił, że R stał się de facto językiem statystyki?

2. Jakie są zalety i wady uczenia Julii do wykonywania zadań o dużej mocy obliczeniowej, w porównaniu do nauki języka niskiego poziomu, takiego jak C / ++?

Myślę, że kluczem będzie to, czy biblioteki zaczną być tworzone dla Julii. Dobrze jest zobaczyć przykłady zabawek (nawet jeśli są to skomplikowane zabawki) pokazujące, że Julia wydmuchuje R z wody w zadaniach, w których R jest kiepski.

Ale źle wykonane pętle i ręcznie kodowane algorytmy nie są powodem, dla którego wiele osób, które znam R, używa R. Używają go, ponieważ do prawie każdego zadania statystycznego pod słońcem ktoś napisał dla niego kod R. R jest zarówno językiem programowania, jak i pakietem statystycznym - obecnie Julia jest tylko tym pierwszym.

Wydaje mi się, że można się tam dostać, ale istnieje znacznie więcej ustalonych języków (Python), które wciąż mają problemy z byciem użytecznymi zestawami narzędzi statystycznych.

Zgadzam się z wieloma innymi komentarzami. "Nadzieja"? Pewnie. Myślę, że Julia wiele się nauczyła z tego, co R, Python / NumPy / Pandas i inne systemy zrobiły dobrze i źle przez lata. Gdybym był mądrzejszy od siebie i chciałem napisać nowy język programowania, który w przyszłości byłby substratem dla środowiska programowania statystycznego, wyglądałby bardzo podobnie do Julii.

To powiedziawszy, minie 5 lat, zanim będzie można odpowiedzieć na to pytanie z perspektywy czasu. Na chwilę obecną Julii brakuje następujących krytycznych aspektów systemu programowania statystycznego, który mógłby konkurować z R dla codziennych użytkowników:

(lista aktualizowana z czasem ...)

• opcjonalnie zamówione typy czynników
• większość testów statystycznych i modeli statystycznych
• znajomość programowania / analizy możliwej do odtworzenia
• Rysowanie w klasie R, a nawet w Matlabie

Aby konkurować z R, Julia i dodatkowe pakiety statystyk będą musiały być wystarczająco czyste i wystarczająco kompletne, aby inteligentni nieprogramiści, twierdzą, że studenci nauk społecznych, mogliby z nich rozsądnie korzystać. Jest dużo pracy, aby się tam dostać. Może tak się stanie, może się skończy, może coś innego (R 3.0?) To zastąpi.

Aktualizacja:

Julia obsługuje teraz DataFrames z brakującymi danymi / NA, modułami / przestrzeniami nazw, formulatypami i model.matrixinfrastrukturą, kreśleniem (sortowaniem), obsługą baz danych (ale jeszcze nie z DataFrames) i przekazywaniem argumentów według słów kluczowych. Dostępna jest także obsługa IDE (Julia Studio), obsługa systemu Windows, niektóre testy statystyczne oraz obsługa daty i godziny.

Dla mnie jedną bardzo ważną rzeczą dla języka analizy danych jest posiadanie funkcji algebry kwerend / relacji z rozsądnymi wartościami domyślnymi i interaktywnym projektowaniem, a idealnie powinna to być wbudowana wersja tego języka. IMO, żaden język FOSS, którego używałem, nie robi tego skutecznie, nawet R.

data.frame jest bardzo niewygodna w pracy interaktywnej - na przykład drukuje całą strukturę danych podczas wywoływania, składnia $ jest trudna w programowaniu, kwerendy wymagają redundantnych odwołań (tj. DF[DF$x < 10]), łączenia i agregacja są niewygodne. Data.table rozwiązuje większość tych problemów, ale ponieważ nie jest częścią podstawowej implementacji, większość kodu R nie korzysta z jego udogodnień.

Pandy w pythonie cierpią z powodu tych samych błędów.

Te niedociągnięcia mogą wydawać się dziwne, ale te błędy kumulują się, a ostatecznie są znaczące łącznie, ponieważ ostatecznie kosztują dużo czasu.

Uważam, że jeśli Julia ma odnieść sukces jako środowisko analizy danych, należy poświęcić wysiłek na wdrożenie operatorów typu SQL (bez bagażu składni SQL) na typie danych tabeli przyjaznej dla użytkownika.

Mogę podpisać się pod tym, co powiedzieli Dirk i EpiGrad; jest jeszcze jedna rzecz, która sprawia, że ​​R jest unikalnym językiem w swojej niszy - system typów danych.

R's został specjalnie zaprojektowany do obsługi danych, dlatego jest wyśrodkowany na wektorach i ma takie rzeczy jak data.frame, czynniki, NA i atrybuty.
Typy Julii są z drugiej strony zorientowane na wydajność numeryczną, dlatego mamy skalary, dobrze zdefiniowane tryby przechowywania, związki i struktury.

Może to wyglądać łagodnie, ale każdy, kto kiedykolwiek próbował robić statystyki z MATLABem, wie, że to naprawdę boli.

Tak więc przynajmniej dla mnie Julia nie może zaoferować niczego, czego nie mogę naprawić za pomocą kilku-liniowego fragmentu C i zabija wiele naprawdę użytecznej ekspresji.

Widzę Julię zastępującą Matlaba, co byłoby ogromną usługą dla ludzkości.

Aby zastąpić R, musisz wziąć pod uwagę wszystkie rzeczy, o których wspominali Neil G, Harlan i inni, a także jeden duży czynnik, który moim zdaniem nie został rozwiązany: łatwa instalacja aplikacji i jej bibliotek.

W tej chwili możesz pobrać plik binarny R dla komputerów Mac, Windows lub Linux. Działa od razu z dużym wyborem metod statystycznych. Jeśli chcesz pobrać pakiet, jest to proste polecenie lub kliknięcie myszą. To po prostu działa.

Poszedłem pobrać Julię i to nie jest proste. Nawet jeśli pobierasz plik binarny, musisz mieć zainstalowany gfortran, aby uzyskać odpowiednie biblioteki. Pobrałem źródło i próbowałem, makeale nie powiodło się to bez naprawdę przydatnej wiadomości. Mam licencjat i magisterium z informatyki, więc mogłem się grzebać i sprawić, żeby działał, gdybym był tak skłonny. (Nie jestem.) Czy Joe Statistician to zrobi?

R ma nie tylko ogromny wybór pakietów, ale także dość wyrafinowany system, który automatycznie tworzy binaria aplikacji i prawie wszystkich pakietów. Jeśli z jakiegoś powodu musisz skompilować pakiet ze źródła, nie jest to wcale trudniejsze (o ile masz odpowiedni kompilator itp. Zainstalowany w systemie). Nie możesz zignorować tej infrastruktury, robić wszystko przez github i oczekiwać szerokiej adopcji.

EDYCJA: Chciałem wygłupiać się z Julią - wygląda ekscytująco. Dwa problemy:

1) Kiedy próbowałem zainstalować dodatkowe pakiety (zapomnij, jak nazywają się w Julii), nie powiodło się z niejasnymi błędami. Najwyraźniej mój Mac nie ma takiego narzędzia, jakiego się spodziewali. Nie tylko zawodzi, ale pozostawia rzeczy, które muszę ręcznie usunąć, w przeciwnym razie inne instalacje zakończą się niepowodzeniem.

2) Wymuszają określone odstępy w wierszu kodu. Nie mam przed sobą szczegółów, ale ma to związek z makrami i nie ma spacji między makrem a nawiasami otwierającymi argumenty. Tego rodzaju ograniczenie naprawdę mnie wkurza, ponieważ opracowałem formatowanie kodu przez wiele lat i języków i faktycznie umieszczam spację między nazwą funkcji / makra a nawiasem otwierającym. Rozumiem niektóre ograniczenia formatowania kodu, ale spacja w linii?

Język Julii jest całkiem nowy; jego czas w świetle punktowym można zmierzyć w tygodniach (chociaż czas jego rozwoju można oczywiście zmierzyć w latach). Teraz te tygodnie w świetle reflektorów były bardzo ekscytujące - patrz na przykład niedawna rozmowa w Stanford, gdzie „to dopiero się zaczęło” --- ale to, o co prosisz w zakresie szerszej infrastruktury i wsparcia dla pakietu, zajmie znacznie więcej zmaterializować.

Więc nadal używam R i uważam na rozwijające się alternatywy. W ubiegłym roku wiele osób poszło na gaga za Clojure; w tym roku Julia to nowy królujący smak. Zobaczymy, czy się przyklei.

Bruce Tate tutaj, autor Siedmiu języków w siedmiu tygodniach. Oto kilka myśli. Pracuję nad Julią do książki uzupełniającej. Oto moja opinia po kilku tygodniach gry.

W grę wchodzą dwie podstawowe siły. Po pierwsze, wszystkie języki mają żywotność. R zostanie zastąpiony któregoś dnia. Nie wiemy kiedy. Nowe języki mają bardzo trudny okres ewolucji. Kiedy nowy język ewoluuje, zwykle rozwiązuje on pewną przytłaczającą bolączkę.

Te dwie rzeczy są powiązane. Dla mnie zaczynamy widzieć motyw kształtujący się w takich językach jak R. Nie jest wystarczająco szybki i trudniejszy niż powinien. Ci, którzy mogą mieszkać w określonym przedziale wydajności i pozostać w ustalonych bibliotekach, mają się dobrze. Ci, którzy nie potrzebują więcej i zaczynają szukać więcej.

Chodzi o to, że zmieniają się architektury komputerów i aby z nich skorzystać, język i jego konstrukcje muszą być skonstruowane w określony sposób. Podejście Julii do współbieżności jest interesujące. Optymalizuje właściwą rzecz dla takiego języka: przejrzysta dystrybucja i wydajny przepływ danych między procesami. Kiedy używam Julii do typowych zadań, map i przekształceń itp., Po prostu wywołuję funkcje. Nie muszę się martwić o hydraulikę.

Dla mnie fakt, że Julia jest szybsza na jednym procesorze jest interesujący, ale nie przesadnie przeklęty dla R. Ciekawe jest dla mnie to, że ponieważ procesory w coraz większym stopniu zależą od wydajności wielordzeniowej, techniczne problemy obliczeniowe są prawie idealnie ustawione aby skorzystać z najlepszej możliwej korzyści, biorąc pod uwagę właściwy język.

Inną funkcją, która to pomoże, są makra. Tempo języka jest teraz bardzo intensywne. Makra pozwalają budować z większych, czystszych elementów. Patrzenie na biblioteki jest interesujące, ale nie pokazuje całego obrazu. Musisz spojrzeć na rozwój bibliotek. Trajektoria Julii jest tutaj dość trafna.

Clojure jest dla niektórych interesujący, ponieważ nie ma technicznego języka, który robi to, co może R, więc niektórzy szukają języka ogólnego, aby wypełnić tę pustkę. Jestem wielkim fanem. Ale Clojure jest dość poważnym odkształceniem mózgu. Clojure będzie tam dla programistów, którzy muszą wykonywać obliczenia techniczne. Nie będzie dla inżynierów i naukowców. Jest po prostu zbyt wiele do nauczenia się.

Więc dla mnie Julia lub coś w tym rodzaju absolutnie zastąpi R. To kwestia czasu.

Za każdym razem, gdy widzę nowy język, zadaję sobie pytanie, dlaczego nie można ulepszyć istniejącego języka.

Dużymi zaletami Pythona są

• bogaty zestaw modułów (nie tylko statystyki, ale i biblioteki rysujące, dane wyjściowe do pdf itp.)
• konstrukcje językowe, których ostatecznie potrzebujesz na dłuższą metę (konstrukcje zorientowane na obiekty, których potrzebujesz w dużym projekcie; dekoratory, zamknięcia itp., które upraszczają programowanie)
• wiele samouczków i duża społeczność wsparcia
• dostęp do mapreduce, jeśli masz dużo danych do przetworzenia i nie masz nic przeciwko płaceniu kilku groszy za uruchomienie ich w klastrze.

Aby wyprzedzić R, Julię itp., Python mógłby użyć

• opracowanie kompilacji just-in-time dla ograniczonego Pythona w celu zwiększenia prędkości na pojedynczym komputerze (ale mapreduce jest jeszcze lepszy, jeśli wytrzymasz opóźnienie)
• bogatsza biblioteka statystyczna

Julia wkrótce nie przejmie R. Sprawdź Microsoft R otwarty.

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

Jest to ulepszona wersja R, która automatycznie wykorzystuje wszystkie rdzenie komputera. To jest ten sam R, ten sam język, te same pakiety. Po zainstalowaniu program RStudio użyje go również w konsoli. Prędkość MRO jest jeszcze większa niż Julii. Robię dużo intensywnych obliczeń i korzystam z Julii ponad rok. Ostatnio przełączyłem się na R, ponieważ R ma lepszą obsługę, a RStudio to niesamowity edytor. Julia jest wciąż na wczesnym etapie i być może wkrótce nie dogoni Pythona lub R.

Poniższe prawdopodobnie nie zasługuje na odpowiedź, ale jest zbyt ważne, aby zostać pochowanym jako komentarz do odpowiedzi innej osoby ...

Nie słyszałem wiele o zużyciu pamięci, tylko o szybkości. Cała semantyka R. przechodząca przez wartość może być bolesna, i to była jedna krytyka języka (co jest odrębną kwestią od tego, ile świetnych pakietów już istnieje). Ważne jest dobre zarządzanie pamięcią, podobnie jak sposoby radzenia sobie z przetwarzaniem poza rdzeniem (np. Tablice lub zapytania mapowane w pamięci numpy lub format xdf Revolution Analytics). Podczas gdy kompilator JIT PyPy pozwala na pewne uderzające testy porównawcze w Pythonie, zużycie pamięci może być dość wysokie. Czy ktoś ma już doświadczenie z Julią i zużyciem pamięci? Wygląda na to, że w wersji „alfa” systemu Windows występują przecieki pamięci, które bez wątpienia zostaną naprawione, a ja wciąż czekam na dostęp do Linux-a, aby sam zagrać w ten język.

Myślę, że jest mało prawdopodobne, aby Julia kiedykolwiek zastąpiła R., z wielu wcześniej wspomnianych powodów. Julia jest zamiennikiem Matlaba, a nie zamiennikiem R. mają różne cele. Nawet po tym, jak Julia ma w pełni rozwiniętą bibliotekę statystyk, nikt nigdy nie uczyłby w niej klasy Wprowadzenie do statystyki.

Jednak dziedziną, w której może być niewiarygodny, jest język programowania zoptymalizowany pod kątem szybkości, który jest mniej bolesny niż C / C ++. Gdyby był bezproblemowo połączony z R (w stylu Rcpp), miałby mnóstwo zastosowania w pisaniu segmentów kodu o kluczowym znaczeniu dla szybkości. Niestety obecnie nie istnieje taki link:

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

Jestem początkującą Julią i jestem kompetentny. Do tej pory uważam Julię za interesującą zorientowaną na wydajność i kompatybilność.

Narzędzia GPU. Chciałbym użyć CUSPARSE do aplikacji statystycznej. Wyniki CRAN wskazują, że niewiele tam jest. Julia ma dostępne wiązania, które do tej pory wydają się działać płynnie.

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)

Narzędzia HPC. Można używać klastra interaktywnie z wieloma węzłami obliczeniowymi.

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

Kompatybilność z Python. Istnieje dostęp do ekosystemu python. Np. Łatwo było dowiedzieć się, jak odczytać dane z obrazowania mózgu:

import PyCall
@pyimport nibabel

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

Kompatybilność C. Poniżej przedstawiono losową liczbę całkowitą przy użyciu standardowej biblioteki C.

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

Prędkość. Myślałem, że zobaczę, jak pakiet Distribution.jl udoskonalił się w stosunku do rnorma R - który, jak zakładam, jest zoptymalizowany.

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

julia> @elapsed rand(F, 1000000)
0.03422067

W R:

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

Julia 1.0 właśnie wyszła z bardzo użytecznym IDE (Juno). Na imprezę wyszło nieco późno, ponieważ Python zdominował już Machine Learning, podczas gdy R nadal dominuje w każdym innym rodzaju analizy statystycznej. Biorąc to pod uwagę, Julia już zyskuje na znaczeniu w dziedzinie algorytmów finansowych i handlowych, ponieważ szybki czas programowania ORAZ wykonanie są koniecznością. Moim zdaniem, chyba że pojawi się inny język, który jest wyraźnie lepszy, awans Julii prawdopodobnie będzie wyglądał mniej więcej tak:

(1) Zaczyna jeść lunch MATLABA. Użytkownicy MATLAB lubią składnię MATLAB, ale nienawidzą prawie wszystkiego innego. Powolność, drogie licencje, bardzo ograniczone sposoby radzenia sobie ze złożonymi strukturami danych, które nie są macierzami. Pamiętam jeden cytat, w którym powiedziano: „Jeśli Julia zastąpi MATLAB, będzie to ogromna usługa dla ludzkości”. Użytkownicy MATLAB-a mogą bardzo szybko opanować Julię i będzie pod wrażeniem łatwości pisania kodu jakości, który robi o wiele więcej niż to, co potrafi MATLAB (Struktury, które można szybko umieścić w tablicach i szybko iterować?). Co więcej, naukowcy mogą stworzyć poważne narzędzia w Julii (niewielki zespół doktorantów napisał światowej klasy pakiet równań różniczkowych), co byłoby niemożliwe z MATLAB.

(2) Zaczyna przejmować badania metod numerycznych i symulacji. MIT zarzuca Julii, a społeczność badawcza słucha MIT. Symulacje numeryczne i nowe metody numeryczne są źle zdefiniowanymi problemami, które nie mają bibliotek. Tu świeci Julia jako język; jeśli nie ma dostępnych bibliotek, o wiele łatwiej jest napisać szybki kod jakości w Julii niż w jakimkolwiek innym języku. Będzie to język numeryczny / symulacyjny napisany przez matematyków dla matematyków (brzmi już podobnie do R?)

(3) Kolejny przełom w uczeniu maszynowym daje Julii przewagę. To jest trochę symbol wieloznaczny, który może się nie zdarzyć. TensorFlow jest świetny, ale bardzo trudno go zhakować. Python już zaczął pokazywać pęknięcia, a TensorFlow zaczął przyjmować Swift (z Julią dostającą wyróżnienie). Jeśli nastąpi kolejny przełom w uczeniu maszynowym, znacznie łatwiej będzie zaimplementować i zhakować pakiet Julia, taki jak Flux.jl.

(4) Julia zaczyna powoli doganiać R, co potrwa chwilę. Robienie statystyk w MATLAB-ie jest bolesne, ale Juila jest już daleko przed MATLAB-em w Distribution.jl. Faktem jest, że przepływy pracy R można łatwo przetłumaczyć na Julię. Jedyną prawdziwą zaletą R jest to, że jest tak wiele pakietów pisanych przez statystyków dla statystyków. Ten proces jest jednak również łatwy do wykonania w Julii. Różnica polega na tym, że Julia jest szybka do końca i nie musisz używać innego języka do wydajności (bardziej „poważne” pakiety R są napisane w językach takich jak C). Problem z R polega na tym, że pakiety napisane w R są zbyt wolne, aby obsłużyć duże zestawy danych. Jedyną alternatywą jest przetłumaczenie pakietów na inny język, co sprawia, że ​​programowanie w języku R jest wolniejsze niż Julia.

Interesuje mnie obietnica lepszej prędkości i łatwej równoległości przy użyciu różnych architektur. Z tego powodu z pewnością będę obserwować rozwój Julii, ale raczej nie będę go używać, dopóki nie będzie w stanie obsłużyć uogólnionych liniowych modeli mieszanych, ma dobry ogólny pakiet startowy, prosty język modelowy do budowania matryc projektowych, możliwości równoważne ggplot2 i szeroki zakres z algorytmów uczenia maszynowego.

Żaden statystyk nie może sobie pozwolić na fundamentalistyczne podejście do wyboru narzędzi. Wykorzystamy wszystko, co pozwala nam wykonać pracę w najbardziej efektywny sposób. Domyślam się, że będę jeszcze trzymać R przez kilka lat, ale byłoby miło być mile zaskoczonym.

Luksus NA w R nie przychodzi bez kar za wydajność. Jeśli Julia wspiera NA z mniejszą karą za wydajność, staje się interesująca dla części społeczności statystyk, ale NA nakładają również znaczną dodatkową pracę, gdy używają skompilowanego kodu z R.

Wiele pakietów w R opiera się na procedurach napisanych w starszych językach (C, Fortran lub C ++). W niektórych przypadkach skompilowane procedury opracowano poza R, a później wykorzystano jako podstawę dla pakietów bibliotek R. W innych procedurach najpierw zaimplementowano R, a następnie krytyczne segmenty przetłumaczono na język skompilowany, gdy stwierdzono brak wydajności. Julia będzie atrakcyjna, jeśli będzie można ją wykorzystać do implementacji równoważnych procedur. Istnieje możliwość zaprojektowania niskiego poziomu obsługi NA w sposób, który upraszcza obsługę NA w porównaniu z tym, co mamy teraz, gdy używamy R ze skompilowanym kodem.

Ogromna liczba bibliotek R reprezentuje wysiłki wielu użytkowników. Było to możliwe, ponieważ R zapewniał funkcje, które nie byłyby w inny sposób dostępne / niedrogie. Jeśli Julia ma być szeroko stosowana, potrzebuje grupy użytkowników, którzy uważają, że robi to, czego potrzebują o wiele lepiej niż alternatywy, które są warte wysiłku potrzebnego do dostarczenia bardzo podstawowych rzeczy (np. Grafika, klasy dat, NA itp.) ) dostępne z istniejących języków.

Będę z góry, nie mam doświadczenia z R, ale pracuję z wieloma ludźmi, którzy uważają, że jest to doskonałe narzędzie do analizy statystycznej. Moje doświadczenie związane jest z hurtownią danych, a ze względu na łatwy w dystrybucji Julię, ale bardziej standardowy model programowania, myślę, że może być bardzo interesującym substytutem części przekształcającej tradycyjnych narzędzi ETL, które generalnie wykonują zadanie bardzo słabo, większość nie ma możliwości łatwe tworzenie znormalizowanej transformacji lub ponowne wykorzystanie wyników transformacji już wykonanej na wcześniejszym zestawie danych. Obsługa ściśle zdefiniowanych i wpisywanych krotek wyróżnia się, jeśli chcę zbudować kostkę OLAP, która w zasadzie musi zbudować bardziej szczegółowe krotki (tabele faktów) z krotek już obliczonych, dzisiejsze narzędzia ETL nie mają o tym „elementów składowych” może pomóc, przemysł ten pracował nad tym problemem na różne sposoby w przeszłości, ale istnieją kompromisy. Tradycyjne języki programowania mogą pomóc, zapewniając centralnie zdefiniowane transformacje, a Julia mogłaby potencjalnie uprościć niestandardowe agregacje i dystrybucje typowe w bardziej złożonych systemach hurtowni danych.

Możesz także używać Julii i R. Istnieje interfejs Julia-to-R . Dzięki tym pakietom możesz grać z Julią, dzwoniąc do R, gdy tylko będzie potrzebna biblioteka.

Julia ma bez wątpienia każdą szansę, by stać się marzeniem zaawansowanych użytkowników statystyki, weź SAS, na przykład, jego moc leży w licznych procesach napisanych w C - Julia może dać ci procy z kodem źródłowym, z macierzami jak wbudowany typ danych rezygnujący z SAS / iml. Nie mam wątpliwości, że statystycy przybędą do Julii, gdy tylko dowiedzą się, co potrafi ten szczeniak.

O tak, Julia dość szybko wyprzedzi R. A głównymi przyczynami będą „makra”, 95% języka jest zaimplementowane w Julii, a jego bezszumowa, oszczędna składnia. Jeśli nie masz doświadczenia z językami typu lisp, być może jeszcze go nie rozumiesz, ale dość szybko zobaczysz, jak interfejs formuły R stanie się przestarzałym i brzydkim mechanizmem i zostanie zastąpiony wyspecjalizowanymi mikrojęzykami modelowania podobnymi do CL pętla makro. Dużym plusem jest również dostęp do referencji niskiego poziomu obiektu. Myślę, że R nadal nie dostrzegł, że ukrywanie wewnętrznych elementów przed użytkownikiem komplikuje, a nie upraszcza.

Jak teraz to widzę (mając za sobą lata intensywnego używania R i właśnie skończyłem czytać instrukcję Julii), głównymi wadami Julii w odniesieniu do R jest brak wsparcia dla strukturalnego dziedziczenia (było to zamierzone). System czcionek Julii jest mniej ambitny niż S4; obsługuje także wielokrotne wysyłanie i wielokrotne dziedziczenie, ale z haczykiem - istnieje tylko jeden poziom konkretnych klas. Z drugiej strony rzadko widzę hierarchie klas w R głębsze niż 3 poziomy.

Czas pokaże, ale będzie wcześniej, niż myśli większość użytkowników R. :)

Pierwszymi docelowymi przypadkami użycia Julii są problemy numeryczne. Zasadniczo można podzielić te dziedziny analizy i obliczeniowej nauki na naukę danych (na podstawie danych) i naukę symulacji (na podstawie modelu). Julia zajmuje się przede wszystkim przypadkami użycia symulacji naukowych. Zajmują się także przypadkami nauki o danych, ale wolniej. R nigdy nie będzie bardzo przydatny w nauce o symulacji, ale Julia będzie bardzo przydatna przez oba lata.

Musi mieć możliwość zastosowania dowolnej funkcji do dużych zestawów danych, które nie mieszczą się w pamięci w sposób przezroczysty dla użytkownika.
Obejmuje to co najmniej uruchamianie modeli efektów mieszanych, modeli przetrwania lub MCMC w zestawach danych, które mieszczą się na dysku, ale nie w pamięci. I jeśli to możliwe w zestawach danych dystrybuowanych na kilku komputerach.