黒木メモ

いくつか参考になりそうな Twitter 投稿を記録しておく.

ツリーのメモ: リーマン予想の簡単な数値的検証

Julia での object.method() スタイルの欠点

Note

以下のツリーをきちんと追いかける.

PyCall

Julia から使う Python の指定・設定

改めて試したとき (私の環境でインストールした) Julia が独自にインストールした Conda を使ってしまっていた. 別途インストールしている自分の Python と合わせたいので, Julia が使う Python のパスを指定した.

julia> ENV["PYTHON"] = "任意のpython.exeのフルパス(python.exeを含む)"
julia> ]
pkg> build PyCall

元に戻すのは次の通り.

julia> ENV["PYTHON"] = ""
julia> ]
pkg> build PyCall

リスト内包表記

このツリーのメモ. 適当に編集して見やすくする.

例えば [f(x) for x in X] はリスト内包表記ではないし(リストではなくVectorができる)、多くの場合に[ ]で囲まない (f(x) for x in X) の方がよい(遅延評価されるGeneratorができる)。

sum([f(x) for x in X])と書くのは、 [ ] で囲んでいるせいでVector=1次元配列が作られ、その分だけメモリアロケーションが発生するので非常に損である。[ ] で囲むのをやめてsum(f(x) for x in X)とした方がよい。さらにsum(f, X)がシンプル!

Y = []
for x in X
    push!(Y, sinpi(x))
end
Y

のようなコードを書くのもひどく損である。 YがAny型成分のVectorになり、大幅な速度的劣化を招く。 Y = sinpi.(X)の方がよい.

ただし、公式ドキュメントのPerformance Tipsには目を通して、したがっておいた方が無難。

問題の設定を変えたければ、グローバル変数に値を代入している行を書き変える。それを何度でも繰り返す。 手抜きのコードを気楽に書いてもよいことにするべきだと私は強く思っているのですが、わざわざ、高等教育でそういう効率の悪すぎるワークフローを教えるのはひどい。 シンプルで分かりやすい処方箋は ①問題を記述するパラメータ群は1つの変数probにまとめる。 ②問題を記述するパラメータ群が梱包された変数probをその問題を解くために使用される函数に常に引数として渡す。 ③問題を解く函数をsol = solve(prob)のように使えるようにしておく。 問題を記述するパラメータ群をまとめるためにstructを使ってもよいし、もっと気楽にTupleやNamedTupleを使ってもよい。 例えば、単振り子の問題を記述するパラメータ群をNamedTupleにprob = (g = 9.80665, l = 2.0)とまとめたりする。

入門直後のプログラミング言語だと、そもそもコードがどのように構文解釈されるかがよくわからない。 JuliaではREPLなどで、どのようにパースされるかを確認したいコードを :( ) で囲んだ結果を見ればよいです。 函数の仕様は多くの場合に ?函数名 で確認できる。doc stringは大事。

入門直後のプログラミング言語は何をやっているかイメージがつかめなくて苦労する。 Juliaではシンプルな函数を書いて次のように書くと色々分かります。

@code_warntype f(1.2)
@code_typed f(1.2)
@code_llvm f(1.2)
@code_native f(1.2)

パイプ

標準のパイプだと書けない描き方もマクロ版がある. 例えば Chain.

マクロなしでも次のような描き方はできる.

(1, 2, 3) |>
(((a, b, c),) -> a + b + c) |>
println

(1, 2, 3) |>
((a, b, c),) -> a + b + c |>
println

f((a, b, c)) = a + b + c
t = (1, 2, 3)
f(t)