ジュリアは統計コミュニティに固執する希望を持っていますか？

最近、R-Bloggersからの投稿を読みました。この投稿は、Juliaという新しい言語に関するJohn Myles Whiteのこのブログ投稿にリンクしています。ジュリアは、ジャストインタイムコンパイラを活用して、非常に高速な実行時間を実現し、C / C ++と同程度の速度（同じ順序、等しく高速ではない）にします。さらに、Rのapplyステートメントとベクトル演算の代わりに、従来の言語でプログラミングを始めた私たちが慣れ親しんでいるオーソドックスなループメカニズムを使用します。

Rは、ジュリアのような素晴らしいタイミングでも、決して離れることはありません。業界での広範なサポートと、ほぼ何でもできる多数の素晴らしいパッケージがあります。

私の興味は、ベクトル化が不可能な場合が多いベイジアンです。確かに、シリアルタスクはループを使用して実行する必要があり、各反復で大量の計算が必要になります。これらのシリアルループタスクではRは非常に遅くなる可能性があり、C / ++は書くのに苦労しているわけではありません。JuliaはC / ++で書くことに代わる優れた選択肢のように見えますが、まだ初期段階であり、Rについて私が愛する多くの機能を欠いています。統計コミュニティから、人々はそれに役立つパッケージを書き始めます。

私の質問は次のとおりです。

1. Rを統計の事実上の言語にした魅力を得るために、ジュリアに必要な機能は何ですか？

2. C / ++のような低レベル言語を学習するよりも、計算量の多いタスクを行うためにジュリアを学習することの利点と欠点は何ですか？

鍵は、ジュリア向けにライブラリの開発を開始するかどうかだと思います。おもちゃの例（複雑なおもちゃであっても）を見るのは、ジュリアがタスクRで水からRを吹き飛ばすのがRが苦手であることを示すのは、すべて良いことです。

しかし、RやRを使用する人の多くがRを使用しているのは、不完全なループと手作業でコーディングされたアルゴリズムが原因ではありません。彼らはRを使用します。Rはプログラミング言語であり、統計パッケージでもあります-現在、ジュリアは前者のみです。

そこに到達することは可能だと思いますが、使用可能な統計ツールキットであることにまだ苦労しているはるかに確立された言語（Python）があります。

他の多くのコメントにも同意します。"望む"？承知しました。ジュリアは、RやPython / NumPy / Pandasやその他のシステムが長年にわたって善悪を行ってきたことから多くを学んだと思います。私が自分より賢く、将来統計開発環境の基盤となる新しいプログラミング言語を書きたいと思ったら、それはジュリアのように見えるでしょう。

これは、この質問に後から答えが出る可能性があるのは5年後だということです。現時点では、ジュリアには日常のユーザーのためにRと競合する可能性のある統計プログラミングシステムの次の重要な側面が欠けています。

（リストは時間とともに更新されます...）

• オプションで順序付けられた因子タイプ
• ほとんどの統計検定と統計モデル
• 読み書きのできるプログラミング/再現可能な分析サポート
• Rクラス、またはMatlabクラスのプロット

Rに対抗するには、Juliaとアドオンの統計パッケージは、社会科学の大学院生などの賢明な非プログラマーが合理的に使用できるように、十分にクリーンで完全である必要があります。そこに到達するための多くの仕事があります。たぶんそれは起こるでしょう、たぶんそれは燃えるでしょう、多分何か他のもの（R 3.0？）がそれに取って代わります。

更新：

Juliaは、データ/ NA、モジュール/名前空間、formulaタイプとmodel.matrixインフラストラクチャが欠落しているDataFrames 、プロット（sorta）、データベースサポート（まだDataFramesではない）、およびキーワードによる引数の受け渡しをサポートしています。また、IDE（Julia Studio）、Windowsサポート、いくつかの統計テスト、およびいくつかの日付/時刻サポートもあります。

私にとって、データ分析言語にとって非常に重要なことの1つは、妥当なデフォルトと対話型の設計を備えたクエリ/リレーショナル代数機能を使用することです。理想的には、これは言語の組み込みです。IMO、私が使用したFOSS言語では、Rでさえも、これを効果的に行いません。

data.frameはインタラクティブに操作するには非常に不格好です-たとえば、呼び出し時にデータ構造全体を出力します。$構文はプログラムでの操作が困難DF[DF$x < 10]です。クエリには冗長な自己参照（つまり）が必要です。Data.tableはこれらの煩わしさのほとんどを解決しますが、コア実装の一部ではないため、ほとんどのRコードはその機能を利用しません。

Pythonのパンダにも同じ障害があります。

これらのグリップはきびきびしているように見えるかもしれませんが、これらの障害は累積し、最終的には多大な時間を要するため、全体としては重大です。

Juliaがデータ分析環境として成功するには、ユーザーフレンドリーなテーブルデータ型でSQL型演算子（SQL構文の手荷物なし）を実装することに力を注ぐ必要があると思います。

DirkとEpiGradが言ったことに署名できます。しかし、Rをそのニッチでユニークな言語にするもう1つのこと、データ指向型システムがあります。

Rは特にデータを処理するために設計されたため、ベクター中心であり、data.frames、factors、NAs、attributesのようなものがあります。
一方、ジュリアの型は数値パフォーマンス指向であるため、スカラー、明確に定義されたストレージモード、共用体、および構造体があります。

これは無害に見えるかもしれませんが、MATLABで統計を実行しようとしたことがある人なら誰でも、それが本当に痛いことを知っています。

そのため、少なくとも私にとっては、数行のCチャンクでは修正できないものをJuliaは提供できず、非常に有用な表現力を殺してしまいます。

Matlabに取って代わるジュリアを見ることができます。これは人類にとって大きなサービスになるでしょう。

Rを置き換えるには、Neil G、Harlan、および他の人が言及したすべてのことに加えて、対処されていないと思われる1つの大きな要素、アプリケーションとそのライブラリの簡単なインストールを考慮する必要があります。

今、Mac、Windows、またはLinux用のRのバイナリをダウンロードできます。すぐに使用できる統計的方法の選択肢が豊富です。パッケージをダウンロードしたい場合は、簡単なコマンドまたはマウスクリックです。それはただ動作します。

ジュリアをダウンロードしましたが、簡単ではありません。バイナリをダウンロードした場合でも、適切なライブラリを取得するにはgfortranをインストールする必要があります。ソースをダウンロードしてみましmakeたが、実際に役立つメッセージが表示されずに失敗しました。私はコンピューターサイエンスの学部と大学院の学位を持っているので、気が向いたら、いじって仕事をすることができます。（私は違います。）Joe Statisticianはそうしますか？

Rには膨大なパッケージの選択肢があるだけでなく、アプリケーションとほとんどすべてのパッケージのバイナリを自動的に作成するかなり洗練されたシステムがあります。何らかの理由で、ソースからパッケージをコンパイルする必要がある場合、（システムに適切なコンパイラーなどがインストールされている限り）それほど難しくありません。このインフラストラクチャを無視することはできず、githubを介してすべてを実行し、広く採用されることを期待できます。

編集：私はジュリアにだまされたかった-それは刺激的に見えます。2つの問題：

1）追加のパッケージをインストールしようとしたときに（Juliaで呼ばれているものを忘れて）、不明瞭なエラーで失敗しました。明らかに私のMacには、彼らが期待していたようなメイクツールがありません。失敗するだけでなく、手動で削除する必要のあるものが残っているため、他のインストールが失敗します。

2）コードの行に特定の間隔を強制します。目の前に詳細はありませんが、マクロに関係しており、マクロと引数を開く括弧の間にスペースがありません。私は長年にわたってコードの書式設定と言語を開発しており、実際には関数/マクロ名と開き括弧の間にスペースを入れているので、この種の制限は本当に私を悩ませます。私が理解しているコードフォーマットの制限がいくつかありますが、行内の空白は？

ジュリア言語はかなり新しいです。スポットライトでの時間は数週間で測定できます（もちろん、開発時間は数年で測定できます）。今、スポットライトのそれらの週は非常にエキサイティングな週でした---たとえば「始まったばかり」のスタンフォードでの最近の講演をご覧ください---しかし、より広いインフラストラクチャとパッケージサポートに関してあなたが求めるものは、実現します。

だから私はRを使い続け、開発中の代替案に留意してください。昨年、多くの人々がClojureをめぐって行きました。今年のジュリアは、支配的な新しいフレーバーです。固着するかどうかを確認します。

ここでブルース・テイト、7週間の7つの言語の著者。ここにいくつかの考えがあります。私はフォローアップの本のためにジュリアに取り組んでいます。以下は、数週間プレイした後の私の意見です。

プレイには2つの基本的な力があります。まず、すべての言語には寿命があります。Rはいつか交換されます。いつかはわかりません。新しい言語の進化は非常に困難です。新しい言語が進化すると、通常、いくつかの圧倒的な問題点が解決されます。

これら2つのことは関連しています。私にとって、Rのような言語を中心にテーマが形になり始めています。それは十分に速くなく、必要以上に難しいものです。特定のパフォーマンスエンベロープ内に住み、確立されたライブラリ内にとどまることができる人は大丈夫です。これ以上必要としない人々、そして彼らはもっと探し始めています。

問題は、コンピューターアーキテクチャが変化していることです。これらを活用するには、言語とその構造を特定の方法で構築する必要があります。ジュリアの同時実行性は興味深いものです。このような言語に最適なものを最適化します：透過的な配布とプロセス間のデータの効率的な移動。Juliaを典型的なタスク、マップ、変換などに使用するとき、関数を呼び出しているだけです。配管について心配する必要はありません。

私にとって、Juliaが1つのプロセッサ上で高速であるという事実は興味深いですが、Rにとってはそれほどひどいことではありません。適切な言語が与えられれば、最大限の利点を活用できます。

それを実現する他の機能は、実際にマクロです。言語のペースは今まさに強烈です。マクロを使用すると、より大きくよりクリーンなビルディングブロックでビルドできます。図書館を見るのはおもしろいですが、全体像はわかりません。ライブラリの成長を調べる必要があります。ジュリアの軌跡はここにかなりスポットです。

Clojureは、Rができることを行う技術的な言語がないため、一部の人にとっては興味深いものです。私は実際に大ファンです。しかし、Clojureはかなり深刻な脳ゆがみです。Clojureは、テクニカルコンピューティングを行う必要があるプログラマのためにあります。エンジニアや科学者向けではありません。学ぶべきことが多すぎます。

だから私にとって、ジュリアまたはそのようなものは、いつかRを完全に置き換えるでしょう。時間の問題です。

新しい言語を見るたびに、なぜ既存の言語を改善できないのかを自問します。

Pythonの大きな利点は

• 豊富なモジュールセット（統計だけでなく、ライブラリのプロット、pdfへの出力など）
• 長い目で見れば必要になる言語構造（大きなプロジェクトで必要なオブジェクト指向の構造、開発を簡素化するデコレータ、クロージャなど）
• 多くのチュートリアルと大規模なサポートコミュニティ
• mapreduceにアクセスします。処理するデータが大量にあり、クラスター上で実行するために数ペニーを払ってもかまいません。

R、Juliaなどを追い抜くために、Pythonは

• 制限されたPython向けのジャストインタイムコンパイルを開発して、1台のマシンでより高速に処理できるようにします（ただし、遅延に耐えられる場合はmapreduceの方が優れています）
• より豊富な統計ライブラリ

ジュリアはすぐにRを引き継ぐことはありません。Microsoft R openをチェックしてください。

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

これは、コンピューターのすべてのコアを自動的に使用するRの拡張バージョンです。同じR、同じ言語、同じパッケージです。インストールすると、RStudioはコンソールでも使用します。MROの速度は、ジュリアよりも高速です。私は多くのヘビーデューティコンピューティングを行っており、Juliaを1年以上使用しています。Rのサポートが改善され、RStudioが素晴らしいエディターであるため、最近Rに切り替えました。ジュリアはまだ初期段階にあり、おそらくすぐにPythonやRに追いつくことはできません。

以下はおそらく答えに値するものではありませんが、他の誰かの応答に対するコメントとして埋めるにはあまりにも重要です...

メモリ消費についてはあまり言われていませんが、速度だけです。Rの値渡しのセマンティクス全体は苦痛を伴う場合があり、これは言語に対する1つの批判でした（これは、既に存在するすばらしいパッケージの数とは別の問題です）。アウトオブコア処理（numpyのメモリマッピングされた配列またはpytables、Revolution Analyticsのxdf形式など）を処理する方法があるため、適切なメモリ管理が重要です。）。PyPyのJITコンパイラーはいくつかの顕著なPythonベンチマークを可能にしますが、メモリ消費は非常に高くなる可能性があります。だから、誰もがジュリアとメモリ使用量の経験がありますか？Windowsの「アルファ」バージョンでメモリリークが発生しているように聞こえますが、間違いなく対処されますが、私はまだLinuxボックスにアクセスして自分で言語を再生するのを待っています。

前述の多くの理由から、JuliaがRを置き換えることはまずないでしょう。JuliaはMatlabの代替品であり、Rの代替品ではありません。彼らは異なる目標を持っています。ジュリアが完全に肉付けされた統計ライブラリを持っていたとしても、誰もその中に統計入門クラスを教えることはありません。

ただし、信じられないほどの可能性がある領域は、C / C ++よりも痛みが少ない、速度が最適化されたプログラミング言語です。Rにシームレスにリンクされていれば（Rcppのスタイルで）、速度が重要なコードセグメントの記述に大量の使用が見られます。残念ながら、現在そのようなリンクは存在しません：

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

私はジュリアの初心者であり、Rの能力があります。私がこれまでジュリアを面白いと思う理由は、パフォーマンスと互換性指向です。

GPUツール。統計アプリケーションにCUSPARSEを使用したいと思います。CRANの結果は、それほど多くないことを示しています。Juliaには、これまでスムーズに機能しているように見えるバインディングがあります。

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の互換性。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パッケージが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に耳を傾けます。数値シミュレーションと新しい数値手法は、ライブラリのない不明確な問題です。これは、言語としてのジュリアが輝く場所です。使用可能なライブラリがない場合、他の言語よりも高速な品質のコードをJuliaで作成する方がはるかに簡単です。それは数学者のために数学者によって書かれた数値/シミュレーション言語になります（まだRに似た音？）

（3）機械学習の別のブレークスルーは、ジュリアに優位性をもたらします。これは、発生しない可能性のあるワイルドカードです。TensorFlowは優れていますが、ハッキングするのは非常に困難です。Pythonはすでに亀裂を見せ始めており、TensorFlowはSwiftの採用を開始しています（Juliaは名誉ある言及を得ています）。別の機械学習のブレークスルーが発生した場合、Flux.jlのようなJuliaパッケージの実装とハッキングがはるかに簡単になります。

（4）ジュリアはゆっくりとRに追いつき始め、しばらく時間がかかります。MATLABで統計情報を表示するのは大変ですが、JuilaはすでにDistributions.jlを使用してMATLABをはるかに上回っています。実際、RワークフローはJuliaに簡単に変換できます。Rが持つ唯一の本当の利点は、統計学者のために統計学者によって書かれたパッケージが非常に多いという事実です。ただし、このプロセスはジュリアでも簡単に行えます。違いは、ジュリアはずっと高速であり、パフォーマンスのために別の言語を使用する必要がないことです（より「深刻な」RパッケージはCのような言語で書かれています）。Rの問題は、Rで記述されたパッケージが非常に遅いため、大量のデータを処理できないことです。唯一の選択肢は、パッケージを別の言語に翻訳して、Rでの開発をジュリアよりも遅いプロセスにすることです。

さまざまなアーキテクチャを使用して、速度を向上させ、並列化を容易にするという約束に興味があります。そのため、私は確かにジュリアの開発を見ますが、一般化された線形混合モデルを処理できるまで、それを使用することはほとんどありません。機械学習アルゴリズムから。

統計学者は、ツールの選択に対して原理主義的な態度を持つ余裕はありません。私たちは仕事を最も効率的に遂行できるようにするものなら何でも使います。私はまだ数年間Rに固執していると思いますが、うれしい驚きを感じるのはいいことです。

RのNAの豪華さは、パフォーマンスのペナルティーなしでは実現できません。Juliaがより小さなパフォーマンスペナルティでNAをサポートする場合、統計コミュニティのセグメントにとって興味深いことになりますが、NAはRでコンパイルされたコードを使用するときにかなりの余分な作業を課します。

Rのパッケージの多くは、レガシー言語（C、Fortran、またはC ++）で記述されたルーチンに依存しています。場合によっては、コンパイルされたルーチンはRの外部で開発され、後にRライブラリパッケージの基盤として使用されました。その他では、ルーチンは最初にRで実装され、次にパフォーマンスが不足していることが判明したときに重要なセグメントがコンパイルされた言語に翻訳されました。同等のルーチンの実装に使用できる場合、ジュリアは魅力的です。コンパイルされたコードでRを使用するときに、NAの処理を簡素化する方法でNAの低レベルサポートを設計する機会があります。

Rライブラリの膨大な数は、多くの多くのユーザーの努力を表しています。これが可能であったのは、Rが提供する機能であり、他の方法では利用できなかった/手頃な価格ではありませんでした。Juliaが広く使用されるようになる場合、非常に基本的なもの（グラフィック、日付クラス、NAなど）を提供するために必要な労力に値する代替手段よりもはるかに優れている必要があることを行うユーザーグループが必要です。 ）既存の言語から入手可能。

私は率直になりますが、Rの経験はありませんが、統計分析の優れたツールであると考える多くの人々と協力しています。私のバックグラウンドはデータウェアハウジングであり、Juliaの簡単に配布された、より標準的なプログラミングモデルのため、一般的に非常に貧弱な仕事をする従来のETLツールの変換部分の非常に興味深い代替品になると思います、ほとんどの方法はありません標準化された変換を簡単に作成するか、以前のデータセットで既に実行された変換の結果を再利用します。厳密に定義され型付けされたタプルのサポートは際立っています。すでに計算されたタプルからさらに詳細なタプル（ファクトテーブル）を構築する必要があるOLAPキューブを構築したい場合、今日のETLツールには「構築ブロック」がありません助けられる、この業界は過去にさまざまな手段でこの問題を回避してきましたが、トレードオフがあります。従来のプログラミング言語は、一元的に定義された変換を提供することで役立ちます。ジュリアは、より複雑なデータウェアハウスシステムで一般的な非標準の集約と配布を単純化する可能性があります。

JuliaとRを一緒に使用することもできます。あるジュリア・ツー・Rインターフェースが。このパッケージを使用すると、必要なライブラリがある場合はいつでもRを呼び出しながらJuliaを操作できます。

ジュリアは間違いなく統計パワーユーザーの夢になるすべてのチャンスを実現しました。SASを例にとると、Cで書かれた多数のprocに力があります。 SAS / imlを使用しない組み込みデータ型。統計学者がこの子犬ができることを理解したら、ジュリアに群がるのは間違いない。

そうそう、ジュリアはすぐにRを追い越します。そして主な理由は「マクロ」であり、言語の95％がジュリアで実装されており、そのノイズのない、par約的な構文です。Lispタイプの言語の経験がない場合はまだ理解できないかもしれませんが、R式インターフェースが時代遅れでいメカニズムになり、CLに似た特殊なモデリングマイクロ言語に置き換わる方法がすぐにわかりますループマクロ。オブジェクトの低レベル参照へのアクセスも大きなプラスです。Rは、ユーザーから内部を隠すことで、物事を単純化するよりも実際に複雑になるとはまだ思っていません。

私が今見ているように（Rを長年使用しており、Juliaマニュアルを読み終えたばかりです）、Rに関するJuliaの主な欠点は、構造継承のサポートではありません（これは意図的なものです）。Juliaの型システムはS4よりも野心的ではありません。また、複数のディスパッチと複数の継承もサポートしていますが、キャッチ付き-具体的なクラスのレベルは1つだけです。一方、Rのクラス階層が3レベルよりも深いことはめったにありません。

時間はわかりますが、ほとんどのRユーザーが考えるよりも早くなります:)

ジュリアの最初のターゲットユースケースは、数値の問題です。基本的に、これらの分析と計算科学の分野をデータサイエンス（データ駆動型）とシミュレーションサイエンス（モデル駆動型）に分けることができます。ジュリアは最初にシミュレーションサイエンスのユースケースを扱っています。また、データサイエンスのケースも扱っていますが、もっと遅いです。Rは、シミュレーションサイエンスにはあまり有用ではありませんが、ジュリアは2年後には両方に非常に有用になります。

ユーザーにとって透過的にメモリに収まらない大きなデータセットに任意の関数を適用できる必要があります。
これには、ディスクには収まるがメモリには収まらないデータセットで、少なくとも混合効果モデル、生存モデル、またはMCMCを実行することが含まれます。可能であれば、複数のコンピューターに分散されたデータセットで。