Julia có hy vọng gắn bó trong cộng đồng thống kê không?

Gần đây tôi đã đọc một bài đăng từ R-Bloggers, được liên kết với bài đăng trên blog này từ John Myles White về một ngôn ngữ mới gọi là Julia . Julia tận dụng một trình biên dịch đúng lúc mang lại cho nó thời gian chạy nhanh và đặt nó ở cùng một tốc độ với tốc độ như C / C ++ (cùng thứ tự , không nhanh bằng nhau). Hơn nữa, nó sử dụng các cơ chế lặp chính thống mà những người trong chúng ta bắt đầu lập trình trên các ngôn ngữ truyền thống đã quen thuộc, thay vì áp dụng các câu lệnh và hoạt động véc tơ của R.

R sẽ không biến mất bằng bất kỳ phương tiện nào, ngay cả với thời gian tuyệt vời như vậy từ Julia. Nó có hỗ trợ rộng rãi trong công nghiệp, và nhiều gói tuyệt vời để làm bất cứ điều gì.

Sở thích của tôi là Bayesian trong tự nhiên, nơi thường không thể vector hóa. Chắc chắn các tác vụ nối tiếp phải được thực hiện bằng cách sử dụng các vòng lặp và liên quan đến tính toán nặng nề ở mỗi lần lặp. R có thể rất chậm ở các tác vụ lặp nối tiếp này và C / ++ không phải là một cuộc dạo chơi trong công viên để viết. Julia có vẻ như là một sự thay thế tuyệt vời cho việc viết bằng C / ++, nhưng nó ở giai đoạn sơ khai và thiếu rất nhiều chức năng mà tôi yêu thích về R. Sẽ chỉ có ý nghĩa khi học Julia như một bàn làm việc thống kê tính toán nếu nó thu hút đủ sự hỗ trợ từ cộng đồng thống kê và mọi người bắt đầu viết các gói hữu ích cho nó.

Câu hỏi của tôi theo sau:

1. Julia cần có những tính năng gì để có được sức hấp dẫn khiến R trở thành ngôn ngữ thống kê thực tế?

2. Những lợi thế và bất lợi của việc học Julia để thực hiện các nhiệm vụ nặng về tính toán, so với học một ngôn ngữ cấp thấp như C / ++ là gì?

Tôi nghĩ chìa khóa sẽ là liệu các thư viện có bắt đầu được phát triển cho Julia hay không. Thật tốt và tốt khi thấy các ví dụ về đồ chơi (ngay cả khi chúng là đồ chơi phức tạp) cho thấy Julia thổi R ra khỏi nước trong các nhiệm vụ R rất tệ.

Nhưng các vòng lặp được thực hiện kém và các thuật toán mã hóa bằng tay không phải là lý do tại sao nhiều người tôi biết sử dụng R sử dụng R. Họ sử dụng nó vì gần như bất kỳ nhiệm vụ thống kê nào dưới ánh mặt trời, ai đó đã viết mã R cho nó. R vừa là ngôn ngữ lập trình vừa là gói thống kê - hiện tại Julia chỉ là ngôn ngữ cũ.

Tôi nghĩ có thể đến đó, nhưng có nhiều ngôn ngữ được thiết lập hơn (Python) vẫn phải vật lộn với các bộ công cụ thống kê có thể sử dụng được.

Tôi đồng ý với rất nhiều ý kiến ​​khác. "Mong"? Chắc chắn rồi. Tôi nghĩ Julia đã học được rất nhiều từ những gì R và Python / NumPy / Pandas và các hệ thống khác đã làm đúng và sai trong những năm qua. Nếu tôi thông minh hơn tôi và muốn viết một ngôn ngữ lập trình mới sẽ là nền tảng cho môi trường phát triển thống kê trong tương lai, nó sẽ trông rất giống Julia.

Điều này nói rằng, sẽ là 5 năm trước khi câu hỏi này có thể được trả lời trong nhận thức muộn màng. Ngay bây giờ, Julia thiếu các khía cạnh quan trọng sau đây của một hệ thống lập trình thống kê có thể cạnh tranh với R cho người dùng hàng ngày:

(danh sách được cập nhật theo thời gian ...)

• các loại yếu tố theo thứ tự tùy chọn
• hầu hết các bài kiểm tra thống kê và mô hình thống kê
• hỗ trợ phân tích lập trình / sao chép
• Âm mưu của lớp R, hoặc thậm chí lớp Matlab

Để cạnh tranh với R, Julia và các gói thống kê bổ trợ sẽ cần phải đủ sạch và đủ để những người không lập trình thông minh, nói rằng sinh viên tốt nghiệp ngành khoa học xã hội, có thể sử dụng nó một cách hợp lý. Có rất nhiều việc phải làm ở đó. Có lẽ nó sẽ xảy ra, có thể nó sẽ xì hơi, có thể thứ gì đó khác (R 3.0?) Sẽ thay thế nó.

Cập nhật:

Julia hiện hỗ trợ DataFrames với dữ liệu / NA, mô-đun / không gian tên, formulaloại và model.matrixcơ sở hạ tầng bị thiếu, vẽ sơ đồ (sắp xếp), hỗ trợ cơ sở dữ liệu (nhưng chưa cho DataFrames) và chuyển các đối số theo từ khóa. Hiện tại cũng có IDE (Julia Studio), hỗ trợ Windows, một số kiểm tra thống kê và hỗ trợ ngày / giờ.

Đối với tôi, một điều rất quan trọng đối với ngôn ngữ phân tích dữ liệu là có chức năng đại số truy vấn / quan hệ với mặc định hợp lý và thiết kế hướng tương tác, và lý tưởng nhất là ngôn ngữ này được tích hợp sẵn. IMO, không có ngôn ngữ FOSS mà tôi đã sử dụng thực hiện điều này một cách hiệu quả, thậm chí cả R.

data.frame rất khó để làm việc với tương tác - ví dụ: nó in toàn bộ cấu trúc dữ liệu theo lời gọi, cú pháp $ khó làm việc theo chương trình, truy vấn yêu cầu tự tham chiếu dự phòng (ví dụ, DF[DF$x < 10]), tham gia và tổng hợp rất khó xử. Data.table giải quyết hầu hết những phiền toái này, nhưng vì nó không phải là một phần của việc triển khai cốt lõi, hầu hết mã R không sử dụng các tiện ích của nó.

Gấu trúc trong trăn bị các lỗi tương tự.

Những sự kìm kẹp này có vẻ khó chịu, nhưng những lỗi này tích lũy và cuối cùng là rất đáng kể trong tổng hợp vì cuối cùng chúng tốn rất nhiều thời gian.

Tôi tin rằng nếu Julia thành công như một môi trường phân tích dữ liệu, phải nỗ lực để thực hiện các toán tử loại SQL (không có hành lý cú pháp SQL) trên kiểu dữ liệu bảng thân thiện với người dùng.

Tôi có thể ký theo những gì Dirk và EpiGrad nói; nhưng có một điều nữa làm cho R trở thành một lang duy nhất trong phân khúc thích hợp của nó - hệ thống định hướng dữ liệu.

R's được thiết kế đặc biệt để xử lý dữ liệu, đó là lý do tại sao nó tập trung vào vector và có các thứ như data.frames, các yếu tố, NA và các thuộc tính.
Mặt khác, các loại của Julia là định hướng hiệu suất số, do đó chúng tôi có vô hướng, chế độ lưu trữ được xác định rõ, các hiệp hội và cấu trúc.

Điều này có thể trông lành tính, nhưng tất cả mọi người đã từng cố gắng làm chỉ số với MATLAB đều biết rằng điều đó thực sự gây tổn thương.

Vì vậy, ít nhất là đối với tôi, Julia không thể cung cấp bất cứ điều gì mà tôi không thể sửa chữa với một đoạn C vài dòng và giết chết rất nhiều biểu cảm thực sự hữu ích.

Tôi có thể thấy Julia thay thế Matlab, đó sẽ là một dịch vụ khổng lồ cho nhân loại.

Để thay thế R, bạn cần xem xét tất cả những điều mà Neil G, Harlan và những người khác đã đề cập, cộng với một yếu tố lớn mà tôi không tin đã được giải quyết: dễ dàng cài đặt ứng dụng và thư viện của nó.

Ngay bây giờ, bạn có thể tải xuống bản nhị phân của R cho Mac, Windows hoặc Linux. Nó hoạt động ra khỏi hộp với một lựa chọn lớn các phương pháp thống kê. Nếu bạn muốn tải xuống một gói, đó là một lệnh đơn giản hoặc nhấp chuột. Nó chỉ hoạt động.

Tôi đã đi tải Julia và nó không đơn giản. Ngay cả khi bạn tải xuống tệp nhị phân, bạn phải cài đặt gfortran để có được các thư viện thích hợp. Tôi đã tải xuống nguồn và cố gắng makevà nó đã thất bại mà không có thông điệp thực sự hữu ích. Tôi có bằng đại học và bằng tốt nghiệp về khoa học máy tính, vì vậy tôi có thể chọc ngoáy và làm cho nó hoạt động nếu tôi rất có khuynh hướng. (Tôi không phải.) Joe Statistician sẽ làm điều đó?

R không chỉ có nhiều lựa chọn gói, nó còn có một hệ thống khá tinh vi, tạo ra các nhị phân của ứng dụng và gần như tất cả các gói, tự động. Nếu, vì một số lý do, bạn cần biên dịch một gói từ nguồn, điều đó thực sự không khó khăn nữa (miễn là bạn có một trình biên dịch thích hợp, v.v., được cài đặt trên hệ thống của bạn). Bạn không thể bỏ qua cơ sở hạ tầng này, thực hiện mọi thứ thông qua github và mong đợi áp dụng rộng rãi.

EDIT: Tôi muốn đánh lừa với Julia - có vẻ thú vị. Hai vấn đề:

1) Khi tôi thử cài đặt các gói bổ sung (quên những gì chúng được gọi trong Julia), nó đã thất bại với các lỗi tối nghĩa. Rõ ràng máy Mac của tôi không có một công cụ giống như họ mong đợi. Nó không chỉ thất bại mà còn để lại những thứ nằm xung quanh mà tôi phải xóa thủ công nếu không các cài đặt khác sẽ thất bại.

2) Họ buộc khoảng cách nhất định trong một dòng mã. Tôi không có các chi tiết trước mặt, nhưng nó phải liên quan đến các macro và không có khoảng cách giữa macro và dấu ngoặc đơn mở các đối số của nó. Loại hạn chế đó thực sự làm tôi bực mình, vì tôi đã phát triển định dạng mã của mình qua nhiều năm và ngôn ngữ và tôi thực sự đặt một khoảng trắng giữa tên hàm / macro và dấu ngoặc đơn mở. Một số hạn chế định dạng mã tôi hiểu, nhưng khoảng trắng trong một dòng?

Ngôn ngữ Julia khá mới; đó là thời gian trong ánh sáng tại chỗ có thể được đo bằng tuần (mặc dù thời gian phát triển của nó dĩ nhiên có thể được đo bằng năm). Bây giờ những tuần đó trong ánh sáng tại chỗ là những tuần rất thú vị --- ví dụ như cuộc nói chuyện gần đây tại Stanford, nơi "nó mới bắt đầu" --- nhưng những gì bạn yêu cầu về cơ sở hạ tầng rộng hơn và hỗ trợ gói sẽ mất nhiều thời gian hơn cụ thể hoá.

Vì vậy, tôi tiếp tục sử dụng R, và chú ý đến các lựa chọn thay thế đang phát triển. Năm ngoái, rất nhiều người đã tham gia trò chơi Clojure; Julia năm nay là hương vị mới trị vì. Chúng tôi sẽ xem nếu nó dính.

Bruce Tate ở đây, tác giả của Bảy ngôn ngữ trong bảy tuần. Dưới đây là một vài suy nghĩ. Tôi đang làm việc trên Julia cho cuốn sách tiếp theo. Sau đây chỉ là ý kiến ​​của tôi sau một vài tuần chơi.

Có hai lực lượng cơ bản đang chơi. Đầu tiên, tất cả các ngôn ngữ có tuổi thọ. R sẽ được thay thế một ngày nào đó. Chúng tôi không biết khi nào. Ngôn ngữ mới có một thời gian cực kỳ khó phát triển. Khi một ngôn ngữ mới phát triển, nó thường giải quyết một số điểm đau đớn áp đảo.

Hai điều này có liên quan. Đối với tôi, chúng ta bắt đầu thấy một chủ đề hình thành xung quanh các ngôn ngữ như R. Nó không đủ nhanh, và nó khó hơn nó cần phải có. Những người có thể sống trong một phong bì hiệu suất nhất định và ở trong các thư viện thành lập là tốt. Những người không thể cần nhiều hơn và họ bắt đầu tìm kiếm nhiều hơn.

Vấn đề là, kiến ​​trúc máy tính đang thay đổi, và để tận dụng lợi thế của chúng, ngôn ngữ và cấu trúc của nó cần phải được xây dựng theo một cách nhất định. Julia tham gia đồng thời là thú vị. Nó tối ưu hóa điều đúng đắn cho một ngôn ngữ như vậy: phân phối minh bạch và chuyển động hiệu quả của dữ liệu giữa các quy trình. Khi tôi sử dụng Julia cho các nhiệm vụ, bản đồ và biến đổi điển hình và tương tự, tôi chỉ gọi các hàm. Tôi không phải lo lắng về hệ thống ống nước.

Đối với tôi, việc Julia nhanh hơn trên một bộ xử lý là điều thú vị, nhưng không gây hại quá nhiều cho R. Điều thú vị đối với tôi là vì các bộ xử lý phụ thuộc nhiều hơn vào đa lõi cho hiệu năng, các vấn đề máy tính kỹ thuật chỉ nằm ở vị trí lý tưởng để tận dụng lợi thế tốt nhất có thể, đưa ra ngôn ngữ phù hợp.

Các tính năng khác sẽ giúp điều đó xảy ra thực sự là macro. Tốc độ của ngôn ngữ chỉ là dữ dội ngay bây giờ. Macro cho phép bạn xây dựng với các khối xây dựng lớn hơn, sạch hơn. Nhìn vào các thư viện là thú vị nhưng không nói lên toàn bộ bức tranh. Bạn cần nhìn vào sự phát triển của các thư viện. Quỹ đạo của Julia có khá nhiều điểm ở đây.

Clojure thú vị với một số người vì không có ngôn ngữ kỹ thuật nào làm được những gì R có thể, vì vậy một số người tìm đến một ngôn ngữ có mục đích chung để lấp đầy khoảng trống đó. Tôi thực sự là một fan hâm mộ lớn. Nhưng Clojure là một chứng bệnh não khá nghiêm trọng. Clojure sẽ có mặt cho các lập trình viên cần làm máy tính kỹ thuật. Nó sẽ không dành cho các kỹ sư và nhà khoa học. Có quá nhiều thứ để học.

Vì vậy, với tôi, Julia hoặc một cái gì đó giống như nó sẽ hoàn toàn thay thế R một ngày nào đó. Đó là vấn đề thời gian.

Mỗi lần tôi nhìn thấy một ngôn ngữ mới, tôi lại tự hỏi tại sao một ngôn ngữ hiện tại không thể được cải thiện.

Ưu điểm lớn của Python là

• một bộ mô-đun phong phú (không chỉ thống kê, mà còn vẽ các thư viện, xuất ra pdf, v.v.)
• các cấu trúc ngôn ngữ mà cuối cùng bạn cần trong thời gian dài (các cấu trúc hướng đối tượng bạn cần trong một dự án lớn; trang trí, đóng cửa, v.v ... giúp đơn giản hóa sự phát triển)
• nhiều hướng dẫn và một cộng đồng hỗ trợ lớn
• truy cập vào mapreduce, nếu bạn có nhiều dữ liệu cần xử lý và đừng ngại trả một vài đồng xu để chạy nó trên một cụm.

Để vượt qua R, Julia, v.v., Python có thể sử dụng

• phát triển trình biên dịch đúng lúc cho Python bị hạn chế để cung cấp cho bạn nhiều tốc độ hơn trên một máy (nhưng mapreduce vẫn tốt hơn nếu bạn có thể chịu được độ trễ)
• một thư viện thống kê phong phú hơn

Julia sẽ không tiếp quản R rất sớm. Kiểm tra Microsoft R mở.

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

Đây là phiên bản nâng cao của R tự động sử dụng tất cả các lõi của máy tính của bạn. Đó là cùng R, cùng ngôn ngữ, cùng gói. Khi bạn cài đặt nó, RStudio cũng sẽ sử dụng nó trong bảng điều khiển. Tốc độ của MRO thậm chí còn nhanh hơn Julia. Tôi làm rất nhiều công việc điện toán nặng và đã sử dụng Julia hơn một năm. Tôi đã chuyển sang R gần đây vì R có hỗ trợ tốt hơn và RStudio là một trình chỉnh sửa tuyệt vời. Julia vẫn đang ở giai đoạn đầu và có thể không bắt kịp Python hoặc R rất sớm.

Những điều sau đây có lẽ không xứng đáng là một câu trả lời, nhưng điều quá quan trọng là bị chôn vùi như một bình luận cho phản hồi của người khác ...

Tôi chưa nghe nói nhiều về tiêu thụ bộ nhớ, chỉ là tốc độ. Toàn bộ ngữ nghĩa của R là giá trị truyền qua có thể gây đau đớn và đây là một chỉ trích về ngôn ngữ (đây là một vấn đề riêng biệt với bao nhiêu gói lớn đã tồn tại). Quản lý bộ nhớ tốt rất quan trọng, vì có nhiều cách để xử lý việc xử lý ngoài lõi (ví dụ: mảng bộ nhớ hoặc pytables được ánh xạ của bộ nhớ nump , hoặc định dạng xdf của Revolution Analytics). Trong khi trình biên dịch JIT của PyPy cho phép một số điểm chuẩn Python nổi bật, mức tiêu thụ bộ nhớ có thể khá cao. Vì vậy, có ai có kinh nghiệm với Julia và sử dụng bộ nhớ chưa? Âm thanh như có rò rỉ bộ nhớ trên phiên bản Windows "alpha" sẽ không còn nghi ngờ gì nữa, và tôi vẫn đang chờ truy cập vào hộp Linux để tự chơi với ngôn ngữ này.

Tôi nghĩ rằng Julia sẽ không bao giờ thay thế R, vì nhiều lý do đã được đề cập trước đây. Julia là người thay thế Matlab, không phải người thay thế R; họ có những mục tiêu khác nhau Ngay cả sau khi Julia có một thư viện thống kê đầy đủ, không ai có thể dạy một Giới thiệu về lớp Thống kê trong đó.

Tuy nhiên, một lĩnh vực mà nó có thể đáng kinh ngạc là ngôn ngữ lập trình được tối ưu hóa tốc độ ít gây đau đớn hơn C / C ++. Nếu nó được liên kết liền mạch với R (theo kiểu Rcpp), thì nó sẽ thấy rất nhiều công dụng trong việc viết các đoạn mã quan trọng về tốc độ. Thật không may, hiện tại không có liên kết như vậy tồn tại:

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

Tôi là một người mới chơi Julia, và tôi có năng lực. Những lý do tôi thấy Julia thú vị cho đến nay là hiệu suất và khả năng tương thích theo định hướng.

Công cụ GPU. Tôi muốn sử dụng CUSPARSE cho một ứng dụng thống kê. Kết quả CRAN cho thấy không có nhiều ngoài đó. Julia có các ràng buộc có sẵn mà dường như hoạt động trơn tru cho đến nay.

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)

Công cụ HPC. Người ta có thể sử dụng một cụm tương tác với nhiều nút tính toán.

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

Tương thích Python. Có quyền truy cập vào hệ sinh thái python. Ví dụ: Thật đơn giản để tìm hiểu cách đọc dữ liệu hình ảnh não:

import PyCall
@pyimport nibabel

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

C tương thích. Sau đây tạo ra một số nguyên ngẫu nhiên bằng cách sử dụng thư viện chuẩn C.

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

Tốc độ. Nghĩ rằng tôi sẽ thấy gói Distribut.jl hoàn hảo chống lại rnorm của R - mà tôi cho là được tối ưu hóa.

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

julia> @elapsed rand(F, 1000000)
0.03422067

Trong R:

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

Julia 1.0 vừa ra mắt với một IDE rất có thể sử dụng (Juno). Nó xuất hiện hơi muộn với nhóm vì Python đã thống trị Machine Learning, trong khi R tiếp tục thống trị mọi loại phân tích thống kê khác. Điều đó đang được nói, Julia đã trở nên nổi bật trong lĩnh vực tài chính và thuật toán giao dịch vì thời gian phát triển nhanh VÀ thực thi là bắt buộc. Theo tôi, trừ khi một ngôn ngữ khác xuất hiện rõ ràng tốt hơn, sự nổi bật của Julia có thể sẽ trông giống như thế này:

(1) Nó bắt đầu ăn bữa trưa của MATLAB. Người dùng MATLAB thích cú pháp MATLAB nhưng ghét mọi thứ khác. Sự chậm chạp, giấy phép đắt tiền, những cách rất hạn chế để đối phó với các cấu trúc dữ liệu phức tạp không phải là ma trận. Tôi nhớ một câu trích dẫn mà người ta nói rằng "Nếu Julia thay thế MATLAB, đó sẽ là một dịch vụ khổng lồ cho nhân loại". Người dùng MATLAB có thể thành thạo Julia rất nhanh và sẽ bị ấn tượng bởi việc viết mã chất lượng dễ dàng hơn nhiều so với những gì MATLAB có thể làm (Các bước nhanh đến mức bạn có thể đặt vào mảng và lặp lại nhanh chóng?). Không chỉ vậy, các nhà nghiên cứu có thể tạo ra các hộp công cụ nghiêm túc trong Julia (một nhóm nhỏ sinh viên tiến sĩ đã viết một gói phương trình vi phân đẳng cấp thế giới) mà không thể có với MATLAB.

(2) Nó bắt đầu tiếp quản nghiên cứu trong các phương pháp số và mô phỏng. MIT đang bỏ lại sức nặng của mình đằng sau Julia và cộng đồng nghiên cứu lắng nghe MIT. Mô phỏng số và phương pháp số mới là những vấn đề không rõ ràng không có thư viện. Đây là nơi Julia như một ngôn ngữ tỏa sáng; nếu không có thư viện, việc viết mã chất lượng nhanh trong Julia sẽ dễ dàng hơn nhiều so với bất kỳ ngôn ngữ nào khác. Nó sẽ là một ngôn ngữ số / mô phỏng được viết bởi các nhà toán học cho các nhà toán học (âm thanh tương tự R chưa?)

(3) Một bước đột phá khác trong Machine Learning xảy ra mang lại lợi thế cho Julia. Đây là một chút ký tự đại diện có thể không xảy ra. TensorFlow là tuyệt vời, nhưng nó cực kỳ khó để hack. Python đã bắt đầu hiển thị các vết nứt và TensorFlow đã bắt đầu áp dụng Swift (với Julia nhận được một đề cập danh dự). Nếu một đột phá học máy khác xảy ra, việc thực hiện và hack trong gói Julia như Flux.jl. sẽ dễ dàng hơn nhiều.

(4) Julia bắt đầu từ từ bắt kịp R, sẽ mất một lúc. Thực hiện các số liệu thống kê trong MATLAB là điều khó khăn, nhưng Juila đã đi trước MATLAB với Distribut.jl. Thực tế là, quy trình làm việc R có thể dễ dàng dịch sang Julia. Lợi thế thực sự duy nhất mà R có được là có rất nhiều gói được viết bởi các nhà thống kê cho các nhà thống kê. Tuy nhiên, quá trình này cũng dễ thực hiện ở Julia. Sự khác biệt là Julia rất nhanh và bạn không phải sử dụng ngôn ngữ khác để thực hiện (các gói R "nghiêm túc" hơn được viết bằng các ngôn ngữ như C). Vấn đề với R là các gói được viết bằng R quá chậm để xử lý các tập dữ liệu lớn. Thay thế duy nhất là dịch các gói sang ngôn ngữ khác khiến cho quá trình phát triển trong R trở nên chậm hơn Julia.

Tôi quan tâm đến lời hứa về tốc độ tốt hơn và song song dễ dàng bằng cách sử dụng các kiến ​​trúc khác nhau. Vì lý do đó, tôi chắc chắn sẽ theo dõi sự phát triển của Julia nhưng tôi không thể sử dụng nó cho đến khi nó có thể xử lý các mô hình hỗn hợp tuyến tính tổng quát, có gói bootstrap chung tốt, ngôn ngữ mô hình đơn giản để xây dựng ma trận thiết kế có khả năng tương đương với ggplot2 và phạm vi rộng từ các thuật toán học máy.

Không có nhà thống kê nào có thể đủ khả năng để có thái độ cơ bản đối với việc lựa chọn công cụ. Chúng tôi sẽ sử dụng bất cứ điều gì cho phép chúng tôi hoàn thành công việc một cách hiệu quả nhất. Tôi đoán là tôi sẽ gắn bó với R trong vài năm nữa, nhưng thật tuyệt khi được ngạc nhiên.

Sự sang trọng của NA's in R không đến nếu không có hình phạt về hiệu suất. Nếu Julia ủng hộ NA với một hình phạt hiệu suất nhỏ hơn thì nó sẽ trở nên thú vị đối với một bộ phận của cộng đồng thống kê, nhưng NA cũng áp đặt thêm công việc đáng kể khi sử dụng mã được biên dịch với R.

Nhiều gói trong R dựa vào các thói quen được viết bằng các ngôn ngữ cũ (C, Fortran hoặc C ++). Trong một số trường hợp, các thường trình biên dịch được phát triển bên ngoài R và sau đó được sử dụng làm cơ sở cho các gói thư viện R. Trong các trường hợp khác, các thói quen được thực hiện đầu tiên trong R và sau đó các phân đoạn quan trọng được dịch sang ngôn ngữ được biên dịch khi thiếu hiệu năng. Julia sẽ hấp dẫn nếu nó có thể được sử dụng để thực hiện các thói quen tương đương Có cơ hội thiết kế hỗ trợ cấp thấp cho NA theo cách đơn giản hóa việc xử lý NA đối với những gì chúng ta hiện có khi sử dụng R với mã được biên dịch.

Số lượng lớn các thư viện R đại diện cho nỗ lực của nhiều người dùng. Điều này là có thể bởi vì R cung cấp các khả năng không có sẵn / giá cả phải chăng. Nếu Julia được sử dụng rộng rãi, nó cần một nhóm người dùng tìm thấy nó làm những gì họ cần tốt hơn nhiều so với các lựa chọn thay thế đáng để nỗ lực cung cấp những thứ rất cơ bản (ví dụ: đồ họa, lớp ngày, NA, v.v. ) có sẵn từ các ngôn ngữ hiện có.

Tôi sẽ lên trước, tôi không có kinh nghiệm với R, nhưng tôi làm việc với nhiều người nghĩ rằng đó là một công cụ tuyệt vời để phân tích thống kê. Nền tảng của tôi là về kho dữ liệu và do mô hình lập trình chuẩn của Julia dễ phân phối hơn, nhưng tôi nghĩ nó có thể là một sự thay thế rất thú vị cho phần biến đổi của các công cụ ETL truyền thống thường làm công việc rất kém, hầu hết không có cách nào dễ dàng tạo một biến đổi được tiêu chuẩn hóa hoặc sử dụng lại các kết quả của một biến đổi đã được thực hiện trên tập dữ liệu trước đó. Sự hỗ trợ cho các bộ dữ liệu được xác định và đánh máy chặt chẽ nổi bật, nếu tôi muốn xây dựng một khối OLAP về cơ bản cần xây dựng các bộ dữ liệu chi tiết hơn (các bảng thực tế) từ các bộ dữ liệu đã được tính toán, các công cụ ETL ngày nay không có 'khối xây dựng' để nói về điều đó có thể giúp đỡ, ngành công nghiệp này đã làm việc xung quanh vấn đề này thông qua các phương tiện khác nhau trong quá khứ, nhưng có sự đánh đổi. Các ngôn ngữ lập trình truyền thống có thể giúp bằng cách cung cấp các phép biến đổi được xác định tập trung và Julia có khả năng đơn giản hóa các tập hợp và phân phối không chuẩn trong các hệ thống kho dữ liệu phức tạp hơn.

Bạn cũng có thể sử dụng Julia và R cùng nhau. Có giao diện Julia-to-R . Với gói này, bạn có thể chơi với Julia trong khi gọi R bất cứ khi nào có thư viện cần thiết.

Julia chắc chắn đã có mọi cơ hội để trở thành một người thống kê ước mơ trở thành sự thật, lấy ví dụ về SAS, sức mạnh của nó nằm ở vô số procs được viết bằng C - những gì Julia có thể làm là cung cấp cho bạn các procs với mã nguồn, với ma trận như một kiểu dữ liệu được tích hợp sẵn với SAS / iml. Tôi không có nghi ngờ rằng các nhà thống kê sẽ đổ xô đến Julia một khi họ nắm được những gì chú chó con này có thể làm.

Ồ vâng, Julia sẽ vượt qua R khá nhanh. Và những lý do chính sẽ là "macro", 95% ngôn ngữ được triển khai ở Julia và cú pháp phân tích tiếng ồn, không có tiếng ồn của nó. Nếu bạn chưa có kinh nghiệm với loại ngôn ngữ không thể hiểu được, nhưng bạn sẽ thấy khá nhanh giao diện công thức R sẽ trở thành một cơ chế lỗi thời và xấu xí, và sẽ được thay thế bằng ngôn ngữ mô hình hóa chuyên biệt giống với CL macro vòng lặp. Truy cập vào các tham chiếu cấp thấp của một đối tượng cũng là một điểm cộng lớn. Tôi nghĩ rằng R vẫn không hiểu rằng việc ẩn nội bộ khỏi người dùng thực sự phức tạp hơn là đơn giản hóa mọi thứ.

Như tôi thấy bây giờ (đã sử dụng R nhiều năm phía sau và vừa đọc xong hướng dẫn sử dụng Julia), nhược điểm chính của Julia đối với R là không hỗ trợ cho kế thừa cấu trúc (điều này là có chủ ý). Hệ thống loại của Julia ít tham vọng hơn S4; nó cũng hỗ trợ nhiều công văn và nhiều kế thừa, nhưng với một nhược điểm - chỉ có một cấp độ cụ thể. Mặt khác, tôi hiếm khi thấy hệ thống phân cấp lớp trong R sâu hơn 3 cấp độ.

Thời gian sẽ trả lời, nhưng sẽ sớm hơn hầu hết người dùng R nghĩ :)

Các trường hợp sử dụng mục tiêu đầu tiên của Julia là các vấn đề về số. Về cơ bản, bạn có thể chia các lĩnh vực khoa học phân tích và tính toán này thành khoa học dữ liệu (hướng dữ liệu) và khoa học mô phỏng (hướng mô hình). Julia đang đối phó với các trường hợp sử dụng khoa học mô phỏng đầu tiên. Họ cũng đang xử lý các trường hợp khoa học dữ liệu, nhưng chậm hơn. R sẽ không bao giờ rất hữu ích cho khoa học mô phỏng, nhưng Julia sẽ rất hữu ích cho cả hai trong một vài năm.

Nó cần có khả năng áp dụng bất kỳ chức năng nào cho các bộ dữ liệu lớn không phù hợp với bộ nhớ trong suốt cho người dùng.
Điều đó bao gồm ít nhất là chạy các mô hình hiệu ứng hỗn hợp, mô hình sinh tồn hoặc MCMC trên các bộ dữ liệu phù hợp với đĩa nhưng không phải trên bộ nhớ. Và nếu có thể trên các tập dữ liệu được phân phối trên một số máy tính.