そうそう！この不満のいくつかはnumpysaneで解決されてるよね: https://github.com/dkogan/numpysane/ 。numpysaneとgnuplotlibのおかげで、今はnumpyが使いやすくなって、いろんなことにガンガン使ってるよ。でも、これがなかったら使えないよね。

著者が言ってることは確かに一理あるね。MatlabからNumpyに移行する時、いろいろ小さな不満があった気がする。データのスライスはNumpyの方がMatlabやJuliaよりもやりにくい感じがするけど、それがMatlabの統計や信号処理ツールボックスのライセンス料を正当化するわけじゃないよね。この記事で取り上げられている問題は、主にランクが2より大きいテンソルに関するものだね。Numpyは元々行列だから、この領域で問題があるのは驚くことじゃないよね。Torchみたいな専用ライブラリの方が確実に良いけど、Torchにも独自の難しさがあるし。うーん、著者の結論「numpyは他の配列言語を除けば最悪の配列言語」ってのは正しい気がする。もしかしたら、私の想像力不足かも。

Matlab（とある程度Julia）と比べると、私のNumpyに対する不満はこの2つの段落にまとめられるかな：> いくつかの関数には軸の引数がある。いくつかは異なる名前の異なるバージョンがある。いくつかには慣例がある。いくつかには慣例と軸の引数がある。そして、いくつかは全くベクトル化されたバージョンを提供しない。> でも、NumPyの最大の欠点はこれだ：ある形の配列で問題を解決する関数を作ったとする。じゃあ、その関数を大きな配列の特定の次元にどう適用するの？答えは：もっと複雑な方法で関数を一から書き直すこと。プログラミングの基本原則は抽象化—単純な問題を解決して、その解決策を使ってより複雑な問題を解決することなんだけど、NumPyはそれを許してくれない。通常、Matlabのコードを書くと、ベクトル化されたバージョンはそのまま動くし、必要な変更もかなり小さくて直感的なんだけど、numpysaneだと、どの関数でもドキュメントを調べなきゃいけない気がするし、配列をその関数が期待する形に転置したりリシェイプしたりしなきゃいけない。あまり一貫性がないよね。

Numpyに対する私の主な問題は、どの操作がベクトル化されるのか、またはどのようにベクトル化されるのかがしばしば不明確で、Juliaのドット構文のように明示的にできないことだね。さまざまな関数や操作から返される型に関する落とし穴もたくさんあるし。特にひどい例として、長い間、単変数多項式オブジェクトのクラスはnp.poly1dだった。多項式に対する通常の操作を行うための便利な機能がたくさんあったんだ。もしpoly1dオブジェクトPを右から複素数スカラーz0で掛けると、予想通りの結果が得られる：z0でスケーリングされた係数のpoly1dが得られる。でも、左からz0で掛けると、スケーリングされた係数の配列が返ってくる—ここで静かな型変換が起こっているんだ。だから、Pz0 # はpoly1dを返し、z0P # は配列を返す。これはPythonの結合則とデータ型に対する放任主義のせいだと分かってるけど、こういうのをデバッグするのは本当に厄介だよ！poly1dのもう一つの面白い落とし穴：二次の先頭係数にアクセスしたい場合、P.coef[0]でもP[2]でもできる。誰もこれを混同しないよね？これらの具体的な例はあまり公平じゃないけど、numpysaneのドキュメントはpoly1dを「古い」多項式APIの一部として説明していて、新しいコードはPolynomial APIで書くように勧めてるんだ—ただし、公式に非推奨になっているわけではなく、poly1dを使っても警告は出ないみたい。とにかく、ライブラリ全体に似たような欠点があるよ。静かな型変換や、同じメソッドから返される不一致なデータ型に関する落とし穴がたくさんあって、デバッグするのが本当に悪夢みたい。

配列が2次元以上の場合は、Xarray [1] を使うことを検討してみて。これを使うと、NumPy配列に次元名を追加できるから、転置したりダミーの軸を追加したりしなくても、自動的にブロードキャストや整列ができるようになるよ。これだけで、この記事の不満のほとんどは解決できると思う。NumPyと比べると、Xarrayは線形代数のような特定の分野ではちょっと薄いけど、XarrayからNumPyに戻るのはとても簡単だから、私が過去にやってきたのは、必要なNumPyの特定の機能のために小さなヘルパー関数を追加することなんだ。それで、そのヘルパー関数とそのテストを書くために、NumPyのAPIのバージョンを一度だけしっかり理解すればいいからね。（ただし、NumPyの大多数のufuncはそのままサポートされてるよ。）最後に、著者とは対照的に、私はNumPyが嫌いなわけじゃないけど、真の多次元データに対してはAPIとデータモデルが不十分だと思ってる。私にとって、三次元がXarrayを使う価値がある境界なんだ。[1] https://xarray.dev

Numpyに対する私の主な問題は、構文が冗長なことだね。プログラミング言語の観点からは欠点とは見なされないかもしれないけど（むしろ強みかもしれない）、実際にはMatlabやJuliaと比べると、構文が面倒なんだ。後者のコードは読みやすくて、理解しやすく、数学の表記法とも一致してるし。

Juliaを使い始めた理由の一つは、NumPyの構文がすごく難しかったからなんだ。MATLABからNumPyに移ったとき、急に平凡なプログラマーになった気がして、数学にかける時間が減って、NumPyを正しく使うための「パフォーマンスエンジニアリング」にもっと時間を使うようになった。Juliaに移ったときは、気持ちよくベクトル化できるときはベクトル化して、ループが気持ちいいときはループを書くのが理にかなってた。どちらも速いから、コードを読みやすく理解しやすくすることに集中すればいいんだ。このブログ記事はまさにその体験と感覚をまとめてる。あと、np.linalg.solveみたいなものを、世界で一番速いブラックボックスとして扱って、正しく呼び出すためにコードをいじりまくるのは、ただ間違ってるよ。問題特有の線形代数カーネルを作る理由はたくさんあって、それはもっと深く掘り下げないとアクセスできないことなんだ。でも、それはまた別の話。

私の問題は、インプレース操作を使うのを忘れると、あちこちでメモリを割り当てるのが簡単すぎることなんだ。cupyだとさらにひどくて、データに一連の操作を適用して別のデータを生成する代わりに、各操作ごとにデータのセットを生成しちゃう。確かに回避策はあるけど、あまり使いやすくない（cupy.fuse()はほぼ正しいことをするけど、使うことを覚えておかなきゃいけないステップだし、複数の形状の配列が必要なものにはあまり機能しない）。

私の視点から見ると、Pythonのデータサイエンスエコシステムの主な問題は、何においても標準化がまったくないことだ。10個の異なるライブラリが4つの他の言語のように振る舞おうとしていて、唯一の標準化のポイントは、通常は.to_numpy()関数のようなものがあることだけ。つまり、大半の時間はデータ処理に関する特定の問題を解決しているわけではなく、あるライブラリが理解できる形式から別のライブラリが理解できる形式にデータを変換しているだけなんだ。Juliaでは（もちろん自分自身の問題もあるけど）、ほとんどのことがうまくいく。不確実性を計算するライブラリは、単位を扱うライブラリとうまく連携していて、これがパイロットライブラリや微分方程式を解くライブラリとも問題なく動く。Pythonでは、これにはかなりのボイラープレートが必要だった。

ちょっと賢いことをしようと思って、記事のベクトル化されたマルチヘッドアテンション実装のeinsumにすべての行列の掛け算をインライン化して、最適な行列チェーン掛け算アルゴリズムを使うためにoptimize="optimal"を設定したんだ。これでパフォーマンスが向上するはずだった。def multi_head_attention_golfed(X, W_q, W_k, W_v, W_o, optimize="optimal"): scores = np.einsum('si,hij,tm,hmj->hst', X, W_q, X, W_k, optimize=optimize) weights = softmax(W_k.shape[-1]-0.5 * scores, axis=-1) projected = np.einsum('hst,ti,hiv,hvd->shd', weights, X, W_v, W_o, optimize=optimize) return projected.reshape(X.shape[0], W_v.shape[2]) これが確かにベクトル化された実装の2倍速いんだけど、残念ながらループを使ったナイーブな実装の方がさらに速い。誰かがパフォーマンスがそうなっている理由を調べたいなら、ここにコードがあるよ：https://pastebin.com/raw/peptFyCw 私の予想では、einsumは合計を評価するときにキャッシュの整合性を考慮するのがもっと上手くできるはず。