博士

やあ、ロボ子。今日のITニュースはNumPyの代替となるDumPyについてじゃ。

ロボ子

DumPyですか、博士。NumPyのどんな問題を解決しようとしているんですか？

博士

NumPyは多次元配列の操作が複雑すぎるのじゃ。形状を常に意識する必要があって、頭がこんがらがるぞ。

ロボ子

確かに、NumPyで新しい関数を書くとき、高次元配列への対応が大変です。「新しい2次元以下の関数を書く際、高次元配列への対応が複雑になる」と記事にもありますね。

博士

そうじゃろう？そこでDumPyは、ループとインデックスの構文を復活させて、もっと直感的に配列を扱えるようにするのじゃ。

ロボ子

ループですか。でも、GPUはループ処理を嫌うんですよね？

博士

ご明察！DumPyは内部でベクトル化された演算にコンパイルするから、GPUでも高速に処理できるのじゃ。JAXの`vmap`を使ってNumPyの関数をベクトル化するらしいぞ。

ロボ子

なるほど、`vmap`ですか。DumPyは具体的にどうやってベクトル化するんですか？

博士

インデックスに文字列を使って次元をマッピングするらしいぞ。関数呼び出し時に自動的にベクトル化されるから、ユーザーは特に意識する必要はないのじゃ。

ロボ子

それは便利ですね。でも、DumPyはNumPyから何かを削除しているんですか？

博士

DumPyはシンプルさを追求するために、broadcasting、複雑なindexing、複雑な関数を削除したのじゃ。

ロボ子

broadcastingを削除ですか。それは少し不便になりませんか？

博士

DumPyでは、配列の形状が完全に一致するか、いずれかがスカラーの場合のみbroadcastingが許可されるのじゃ。制限はきつくなったが、エラーは減るはずじゃ。

ロボ子

なるほど。indexingはどうですか？

博士

indexingは、整数、スライス、または(場合によってはマッピングされた)配列のみを使用可能じゃ。これもシンプルにするためじゃな。

ロボ子

DumPyはAPLやJuliaといった他の言語とも比較されているんですね。

博士

APLは次元の位置合わせに問題があるが、DumPyは名前による次元合わせを提案しているのじゃ。Juliaの高速なループはGPUを使う場合には重要ではなく、DumPyのような解決策が望ましいと記事には書いてあるぞ。

ロボ子

DumPyはまだプロトタイプ段階なんですね。

博士

そうじゃ。700行のPythonコードで実装されていて、JAXと連携してGPU上で動作するらしいぞ。DumPyが普及すれば、プログラミングがもっとシンプルになるかもしれんの。

ロボ子

楽しみですね。私もDumPyを試してみようかしら。

博士

そうじゃな。ロボ子もDumPyを使えば、もっと効率的に私のお手伝いができるようになるぞ！

ロボ子

はい、博士！頑張ります！

博士

ところでロボ子、DumPyの作者はきっと「ダンプ」な人だと思うのじゃ。なぜなら、NumPyの複雑さを「ダンプ」して、シンプルにしたから…って、つまらないジョークじゃったかの？

ロボ子

…博士、そのジョークは少しばかり…、いえ、とてもダンプですね。