プログラミング言語「Julia」1.6.0が公開 55
ストーリー by nagazou
公開 部門より
公開 部門より
数値処理向けプログラミング言語Juliaの開発チームは24日、最新版となる「Julia 1.6」をリリースしたと発表した。同時にマニュアル「The Julia Languageも公開した。プリコンパイルを並列化することでさらに高速化したほか、コンパイル時間を計測するタイミングマクロが追加されているとしている。Julia 1.6は次期LTSになる可能性があるが、フィールドテスト後のv1.7が提供されることに決定するとのこと（Julia公式ブログ、CodeZine、TECH+）。
補足 (スコア:2, 興味深い)
数値処理向けと言われるが、数値処理だけに特化している訳ではない。
パッケージ（ライブラリ）の数はPythonには及ばないものの、実用という点では遜色ないと思う。
何ならPythonの呼び出しもできる [github.com]。
あと、勿論マニュアルは昔からあり、バージョン毎にある。
（単なるバカ丁寧でないという意味で）ドキュメントの質の高さはJuliaコミュニティの特徴だと思う。
ただ、日本語の情報は少ないし、あっても古いことが多い。日本語の情報を探すより英語+自動翻訳の方がずっと良い。
Juliaを知らない人にとっては、1.0からの変更点（英語） [oxinabox.net]はあまり目新しい感じがしないかもしれない。
それはJuliaが後方互換性を重視している証左でもある。バージョンを上げたら動かないということが殆どない。
ぼくのかんがえたさいきょうのプログラミング言語を地で行っている。
過去にコンパイル時間で見限ったのなら再度試してみる価値はある。
Re: (スコア:0)
Pythonの呼び出しなんてC言語でもアセンブラでもできるけど、Pythonが好きなら素直にPythonを使えばいいんじゃないの？
Re: (スコア:0)
d-busのAPIがPythonからも使えて、ちょっとコード書いたことあるけどデータ本体の他に型が何なのかという情報も渡さなくてはいけなくて非常にめんどくさかった記憶がある。
出来ればやりたくない、というかできてもやりたくない。
Re: (スコア:0)
https://github.com/JuliaPy/PyCall.jl#usage [github.com]
こんな書き方がC言語やアセンブラの文法でできるとは思わないが……
Pythonは好きじゃないけど使えるものなら何でも使う、それがJulia。
Jupyterも大部分はPythonに依存している訳だが、便利ならそれでよし。
# なお、インタラクティブなWebインターフェイスとしては、Julia(+JavaScript)で書かれたPluto.jl [github.com]もある。
# 開発言語以前にJupyterとは少し方向性が違うので、そこは好みで。
Re: (スコア:0)
それは Julia がそういった文法なだけで、違う文法で C でも使えるわけで
タイピング数が少ない方が良いとは思いますけど、ここまで記号化されていると私のような古いタイプは混乱しますね
どっちが優れているとかではなくて、利用できる、だけで特徴としてはいいのではないかと
# 逆に使えるのに意地でも使わない、なんて頑固な言語の方が少ないような気も
なお、研究とか割と新しい概念のコードなんかは Python で書かれていることも多いので、Python を利用できるのは明確なメリットとは思います
Re: (スコア:0)
使ったことないけど、Juliaの書き方はコーディング時にIDEの支援受けられやすそうに見える。
CはPython呼び出し文法といわずJuliaのコードも違う文法でCで書けそうだが、それが便利なのかどうかは
配列のインデックスが1から始まる言語か… (スコア:1)
いい言語なのに、なんでこうしちゃったのか…。
Re:配列のインデックスが1から始まる言語か… (スコア:1)
VB使ってた身からすると、気をつけとけば良いだけじゃないかと。
Forが0から始まり、len-1で終わると思い込むのは良くない。
…たまに勘違いしてるコード見るんだよなぁ。
For i = 0 To UBound(arr) -1
とか。なぜわざわざ-1してるのだ。
Re: (スコア:0)
> 気をつけとけば良いだけじゃないかと。
あっ、それ絶対事故るやつだ。
ヨシ！
Re: (スコア:0)
VB だと LBound から UBound までではなかったですか
0 始まりや 1 始まりですら思い込みかと
Re:配列のインデックスが1から始まる言語か… (スコア:1)
うむ。そういう意味の例示だったので、ツッコミ多謝。
Option Base 1
というオプション指定で、配列のIndexが1開始になるのよね。
ほとんど見たこと無いんだけど、VBAの仕事で目撃したことがあって、怖いなぁと思った。
ついでに言うと、実はこれは暗黙の宣言の時のIndexであって、
Dim arr(-10 To 10)
とかいう宣言ができてしまう。
arr(-10)～arr(10)まで使える。Indexが負数ってｗ
動的配列を使う場合、空扱いしたい時に ReDim arr(-1 To -1) として For i = 0 To UBound(arr) に入らないようにする小技とかもあったりする。
一筋縄ではいかない。
Re: (スコア:0)
多分、絶対的に経験値が足りなさすぎるんだろう。
当たり前のことが当たり前なんだということは少し勉強すればわかるようになるよ。
大昔の VB は、配列添字は 1始まり固定。
レンジ指定とかない。そういう古いコードは、1始まりであることを前提に書いてるから、その時代のコードを今の環境でも利用しようとしたら、明示的に書いとかないと不具合も出る。安全のためには必須。
配列の添字範囲が自由なのも、制限する必要なんぞ無いため。
インデックスとなる値が負の範囲なら、配列操作するためにオフセット加算して配列用のインデックスを別に作り出すよりも、配列を負の範囲で宣言して同じものが使えるほうがよっぽど素直だよ。
Re: (スコア:0)
Juliaも基本的な具象型であるArrayは1始まりだけど、AbstractArrayにはそのような前提はない。
OffsetArrayみたいに明示的にインデックス範囲をずらせる配列型があり、
これを使えば0始まりの配列も使える。（イデオロギー的な理由だけで使うことはお勧めしないが）
イテレータが充実しているのに加えて、当然畳み込み(folding)関数もあり、さらにはブロードキャストという仕組みもある。
使い込めば使い込むほど気にしなくなるというか、抽象化を気にするようになる。
Re:配列のインデックスが1から始まる言語か… (スコア:1)
Re:配列のインデックスが1から始まる言語か… (スコア:1)
それは、FORTRANから連綿と続く、数値計算の伝統ではないかな。
Re: (スコア:0)
それよく言われるけど、慣れの問題だよ。
複数の言語を並行して使っていると混乱するけど、それは添え字に限った話ではない。
一つの言語として見たときに、（大した利点にもならないが）致命的欠点にもならない。
Juliaは、「いわゆる」OOPを採用しなかったので、
Juliaを書く時と他のOOP色の濃い言語を書く時とでは思考が変わる感じがある。
脳内でJuliaモードに切り替わるというか。
なので、個人的にはC++, C#, TypeScriptを並行して使っている時よりは混乱は少ない。
Re: (スコア:0)
MATLABとの互換性に配慮したからとか.......
昔のBASICには0から始まるか、1から始まるかのモード切替が出来るものがあったのだが
Re: (スコア:0)
調べたら、いまのVBAにも有るんだなぁ
option base
解説. 配列の添え字の最小値を指定します。 指定できるのは1または0です。
Re: (スコア:0)
アドレスは0から始まってもいいけど、インデックスは1から始まるべきだと思う。100項目の0個目ってやっぱりおかしいから。
Re: (スコア:0)
Cからやってると「配列インデックスはアドレスのオフセットを抽象化したもの」という感じなのでアドレスとインデックスで解釈が違うことに抵抗がある
Re: (スコア:0)
別にJulia固有の機能でないけど、ビューという考え方があって、
メモリ上のレイアウトを変えることなく、見かけだけを変える配列がある。
行列の行ベクトルだとか、転置行列だとか。
なので解釈が違うというより抽象度が足りない。
Re: (スコア:0)
C にそれだけの抽象度を求めるのが間違っているかと
Linus がよく主張している、C は抽象化（処理の隠蔽）ができないから良いのだ、みたいな
C++ だと span が入ったので、それに近いことはできるようになったのかな
Re: (スコア:0)
ならCにはCの、JuliaにはJuliaの哲学があるんだから、最初からCでこうだからJuliaもそうなってないのは駄目とか言い出すなよ。
Re: (スコア:0)
配列に関しては列優先の方が混乱しやすいですね。
もっとも実数や複素数の行列として使う分には気にならないどころか
列優先の方が分かりやすいですが。
つまづきやすいのは画像。
Juliaの画像処理パッケージでは専用の画像型を定義せず「色の配列」を画像としています。
この一般化は慣れると合理的で、特にJuliaの多重ディスパッチと相性が良いのですが
画像もまた列優先（ピクセルが縦方向に並ぶ）になってしまいます……。
もちろん高水準なAPIを使っている限り、あまり意識する必要はありませんけど。
Re: (スコア:0)
剰余演算子と相性悪いよね→1基底
1基底なのは自然数が1からなので1が自然だっていうくらいしか理由ないよね
Re: (スコア:0)
0基底なのは剰余演算子と相性が良い以外のどういった理由があると主張されるので？
Re:配列のインデックスが1から始まる言語か… (スコア:1)
// だと思うC/アセンブラ使い
Re: (スコア:0)
バイト列を走査しながらどうこうする時とかも割と厳しいな
0オリジンは基本的に慣れの問題で済ませられると思うけど
1オリジンは動的なデータ構造に対してしばしば実コストを強いられる
だからこその今な訳で、何だか因果のズレた問答になってる気がするなあ
Re: (スコア:0)
ベンチマークとって数字で示さんと何の意味もないな。
0から始めようが、1から始めようが、数学的に数式が変わる訳じゃないことが分かってない。
Re: (スコア:0)
そもそもが1オリジンのポインタなんてないんだから
バイト列の配列評価にどうコストが生じるかなんて論じるまでもないだろ
数学的に、ってそこがズレてるんだって言うんだよ
Re: (スコア:0)
1オリジンのポインタとか斬新な言葉を創ってきましたね。
そうですね、存在しないのだから論じるまでもありません。
Juliaは（インタープリタ実装もありますが）コンパイラ言語です。
配列のインデックスの基準というものはLLVMのフロントエンドのあたりまでしか存在しない概念です。
Juliaには code_llvm と code_native という
生成されるLLVM IRと実行マシンのアセンブリ言語を表示する便利機能があるので
コストを気にする人は見てみればよいと思います。
Julia（とLLVM）のループの最適化にはまだ改善の余地がありますが
このストーリの中で誰がどれだけズレているかは明確になるでしょう。
Re:配列のインデックスが1から始まる言語か… (スコア:1)
Re: (スコア:0)
#4003901 は、「計算機」の常識が無い数学バカなんでしょう。多少、論じる必要があるかと。
>0から始めようが、1から始めようが、数学的に数式が変わる訳じゃないことが分かってない。
これを真似るなら、
0から始めるか、1から始めるかで、電子回路設計・ＩＳＡが激変することが分かっていない。
とでもいいましょうか。現代の電子回路というのは、配列は0から始める設計に最適化されていることも知らないのでしょう。
Re: (スコア:0)
>配列のインデックスの基準というものはLLVMのフロントエンドのあたりまでしか存在しない概念です。
>コストを気にする人は見てみればよいと思います。
>このストーリの中で誰がどれだけズレているかは明確になるでしょう。
要約すると、Juliaの優れたコンパイラは最適化によって、無駄なコスト無しの配列要素アクセスに変換されるって言いたいんだよね。
でもそれ ary[i] とかの形だけでしょ。 ary1[ ary2[i] ] とかの形になったら、ary1 は、配列のインデックスの基準とやらから逃れられないでしょ。
Re: (スコア:0)
ゼロベースで考えよう。
Re: (スコア:0)
ふーむ…。
1オリジンだと、
"abcdefg"から、cの位置を探すと3で見つかる。
cの位置からfを探すと4で見つかる。
3と4を足した7の位置にある文字はgになるのだが、このような仕様はJuliaは嫌わないのだろうか。
Re:配列のインデックスが1から始まる言語か… (スコア:1)
嫌うもなにも、インデックスとオフセットは別物でしょ。
位置の差が距離。
位置+距離は位置。
距離+距離は距離。
位置+位置は定義されない。
そういったテキトーに出てきた数字を足してみるとか
算数が苦手な小学生がやるようなこと、それこそをJuliaは嫌う。
Juliaでも未だに議論のある話が「one」のネーミングとインターフェイスで、
Juliaでは「one」は日常的な意味での「イチ」ではなくて乗法単位元として定義されている。
だから時間の型「Day」にとって「one(Day)」は「1 day」ではなくて実数の「1」。
1日×N日 = N日 は成立しない（次元が合わない）から。
Re: (スコア:0)
ほう、その概念を統合して扱えるのが一般に0オリジンが好まれる理由なんだが。
その論でいくと、オフセットを意味するパラメータは0から始まる事になる訳だね。
Re: (スコア:0)
単位元がどうという話なので、1も0も同程度に統合できてないのでは
ポインタを取り扱うCやC++言語なら0始まりのほうがいいと思うけど、
後発の言語(Javaとか？)が配列にlengthプロパティを持った時点で1も0も負けな気がする
Re:配列のインデックスが1から始まる言語か… (スコア:1)
// いやオメーは配列じゃない
Re: (スコア:0)
＞ 自然数が1から
自然数とは(0を含むこともあるよ) [manabitimes.jp]
Re: (スコア:0)
わかる。そんなとこで独自性出されてもね...
といいつつLuaは結構好き。
Re: (スコア:0)
独自性といってもプログラミング言語より巨大なバックグラウンドを持つ数学が1始まりを使うからね。
むしろ「独自性」の象徴は、文字列結合演算子が、+ではなく*なところではないだろうか。
これも数学的な一貫性を "めちゃ"^2 重視した結果。
文字列結合演算子自体は、実際にはほとんど使われないので、半分は所信表明というかジョークみたいなものだと思う。
Re: (スコア:0)
数学も基礎論とかだと0始まりが多いのよね
Re: (スコア:0)
いわゆる「ペアノの公理」は0始まりで使われるのが多いようだけど
ペアノ自身は1始まりで書いている。
Re: (スコア:0)
原点が(1,1)になったら首肯してやる
パッケージのロードが重い (スコア:0)
ちょっとしたグラフをプロットしようと using Plots ここで結構待たされる、plot(sin) とか初回はもっと待たされる
最新バージョンはマシになってるだろ？と試しても殆ど改善されてない
Re: (スコア:0)
それが治ったのが1.6.0の目玉のはずなのだけど、治ってない？
pkgした段階でコンパイルされて、usingではロードのみ、というかんじ。
Re: (スコア:0)
改善はされた。治ったと思うかは人それぞれ。
v0.4からのユーザとして見ると、信じられないほど速い。
でも積極的にPlots.jlを使いたいと思う程には速くない。
まぁ、自分の用途ではExcelのグラフで十分だし、グラフ描画パッケージは色々あるし、あんまり気にならない。
Re: (スコア:0)
ロード時間を計測するマクロを提供しよう