1 ポイント 投稿者 GN⁺ 2024-06-02 | 1件のコメント | WhatsAppで共有
  • 高エネルギー物理のような大規模研究に必要な大量データ処理と科学分析を支援し、現在ROOTファイルには2エクサバイトを超えるデータが保存されている
  • Higgs粒子の発見にもROOTが使われており、実験データ分析で検証された実利用例を持つツールである
  • オープンソースとして自由に使用・修正でき、公開された開発プロセスを通じてユーザーからの貢献を受け入れている
  • 同梱されるC++インタープリタは迅速なプロトタイピングに適しており、Pythonの動的バインディングで全コンポーネントにアクセスできる
  • Jupyter Notebookにも対応し、C++・Pythonベースの分析をノートブック環境へ拡張でき、リリースや教育・ハッカソン関連の情報も継続的に公開されている

ROOTのデータ分析における役割

  • ROOTは大量データの処理と科学的分析を可能にするツールである

オープンソース開発と貢献

C++・Python・ノートブックベースの利用方法

ブログとリリース情報

  • 最近のブログ項目には、C++ドキュメンタリーのYouTube公開への招待、ROOTとC++ドキュメンタリーのトレーラー、ROOT Advanced Course 2026、3rd ROOT Hackathonに関する記事がある
  • 最新リリース一覧には次のバージョンが含まれている

1件のコメント

 
GN⁺ 2024-06-02
Hacker Newsのコメント
  • 昔を思い出す。素粒子物理の分野で働いていたときは ROOT をよく使っていて、愛憎入り混じる感じだった
    一方では技術的負債や独特の慣性が多かったが、他方では matplotlib のようなより「モダン」な選択肢より ROOT のほうが簡単にできることもかなりあった。たとえばヒストグラム、フィールドを持つオブジェクトを「列」に入れる高度に構造化されたデータ、x/y 配列を別々に確保せずに関数をそのまま描画する作業など
    直感的な オブジェクト指向 API もよかった。pandas/matplotlib のメソッドチェーン、[] 構文の濫用、いろいろな魔法のような挙動より、昔ながらの C++ や Java に近い感じで、エレガントではなく冗長だが、科学解析ではむしろ利点になり得る
    5年ほど前に離れたころ、ROOT は変化の途中で、古い CINT インタープリタを取り除き、clang ベースのコードベースへ移行していた。今は C++ や Python で Jupyter 上から解析を実行できるはずだし、コード品質もかなりよくなったと聞いている

    • ROOT のいちばんよい点は データの読み込み方式 だった。ディスクから列ベースで切り出して読む TTree は本当にいいアイデアで、卒業後に産業界へ移ってからも、同じように動くものをずっと探している
    • matplotlib はヒストグラム中心ではないからなのか、最近は RAM が十分あるからなのか、重なった点が多すぎて役に立たない 散布図 をよく見かける。見ていてつらい
    • みんな ROOT とは愛憎関係にある。ちょっと ストックホルム症候群 みたいでもある
    • Haskell もこういうものを作るのに向いているのか気になる
    • 最近は ChatGPT のおかげで、matplotlib のひどい API も以前ほど大きな問題ではない
  • 新しい解析で ROOT をデフォルトにする理由はあまりない。もっとユーザーフレンドリーでまともな選択肢である uproot などを使ったほうがいい
    レガシーなワークフローがある場合や、実験ごとに ROOT の上へカスタムパッチを大量に載せている場合はあるだろうが、物理解析だけを見ると、自分を苦しめる選択になり得る
    404 ページも気に入っている。なお、room 404 の話ではない
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • uproot へのよくある批判は、行ごとの計算が複雑になったときに柔軟性が低いという点。Python の for ループが遅すぎるからだ
      こういうときは Numba を使うか、うまく動く場合に限られるが、あるいは恥ずかしながら宣伝すると Julia を使うこともできる: https://github.com/JuliaHEP/UnROOT.jl
      素粒子物理で Julia を使うことに関する過去の HN 議論: https://news.ycombinator.com/item?id=38512793
  • 科学的発見に使われる 大規模ソフトウェアプロジェクト を見るのはすばらしい
    別の例として、LIGO では GStreamer で重力波を探した: https://lscsoft.docs.ligo.org/gstlal/

    • ここではむしろ逆に近い。CERN にデータ解析フレームワークが必要だったので、CERN が開発・保守・公開したものだ
      ただし、外部の人が実際に使うのがよい考えかはわからない。自分の経験は少し古いかもしれないが、かなり無骨で古びていた。CERN や素粒子物理の仕事での大きな利点は、事実上の標準なので内部コラボレーションがしやすいことだ
    • この2つはかなり違う例だ。ROOT は強力なデータ解析フレームワークだが、その強力さにもかかわらず、十分に汎用的で使いやすいものにできず、高エネルギー物理学の外にはほとんど出られなかった
      一方 GStreamer は設計が美しいプラットフォームで、アーキテクチャが優れているため、元の開発者たちが想像もしなかったようなまったく別のシナリオにも簡単に抽象化して再利用できる
    • すばらしくない点は、ROOT が大規模ソフトウェアプロジェクトの運営方法をまったく知らない人たちによって「設計」され、作られたことだ
      その痕跡は至るところに見える。巨大な モノリス なので、少しでも普通でないことをしようとすると延々と格闘しなければならない。頻繁に使わずに済んでいるのは幸いだが、まだある程度は触れている
    • 「重力波を LIGO で GStreamer を使って見つけた」って? 何だって?!
  • 個人的には、ROOT はあまりに多くのことをやろうとし、API 設計がよくなく、何より ライブラリとしての ROOTプログラムとしての ROOT が分離されていない
    グローバル状態が多く、人々は ROOT プログラムの流儀で使うべきだという前提がある。ROOT 6 はその一部を直し始めたが時間がかかっており、個人的には llvm と clang に深く依存しすぎたことでビルド時間がさらに延び、プロジェクトとして修正しにくくなったと思う
    長い間、入出力形式のドキュメントも貧弱で、実装も1つしかなかった
    今では groot、uproot、freehep、openscientist などのおかげで、ROOT 全体を持ち込まなくても ROOT データを読み書きできる。データにおける 相互運用性 は非常に重要だと思う。20年、30年後にもその唯一のデータを再び読めるという希望を持つには不可欠だ
    https://go-hep.org/x/hep/groot
    go-hep の主開発者です

    • uproot はいまだに TEfficiency の読み込み をきちんと実装できていないと理解しているが、正直残念だ
  • ああ、root……毎日 6 より前のバージョン を使わなくていいという事実に感謝するようになる

    • Root は、素粒子物理を勉強しないことにした理由の1つだった
    • インターフェースを壊してでも、ついに root をよくするという バージョン 7 をいまだに待っている。2016年ごろに初めて聞いた気がするが、本当に蒸発した約束のようだ
  • コンピュータサイエンスのバックグラウンドはないが優秀な物理学者たちが書いたコードを、夜遅くまでデバッグしていた記憶がよみがえる

    • 2013年ごろ、オンライン融資サイトで働いていたが、リスク予測モデルを作るために素粒子物理学者を雇っていた
      彼らはモデリングに ROOT を使い、Ruby でインターフェースを作っていたが、ソフトウェア工学の観点では 怪物 のようだった。それでも統計の観点ではかなりよかった
      Python エコシステムが盛り上がるずっと前で、R の機械学習パッケージも始まったばかりの時期だった
    • 2000行の main() が目に浮かぶ
  • Root が実験素粒子物理における膨大な作業の 中核 であるのは確かだが、新しい大学院生にとっては悪夢でもある
    素粒子物理に事実上深く組み込まれているので、近い将来変わるとは思えない

    • 今は pyroot と uproot があるので、新しい大学院生にも学びやすい選択肢ができていて、そこまで悪くはない
      問題はたいてい、実験サービスの一部として保守しなければならないレガシーコードにある
  • 自分が使っている Root の部分は、C++ インタープリタの Cling と Jupyter ノートブックの Xeus だ
    ある夜、benchmarkgames の最速の n-body を Xeus と Python 3 で比較してみた。同じ Binder インスタンスで Xeus は 15.58 秒、Python3 カーネルで最速の Python コードを動かすと 5 分かかった。出力はどちらの実行でも完全に同じだった
    このプログラムで動的 C++ 実行のオーバーヘッドを約 300% と見積もっても、Cling は非常に速い。SIMD やベクトル化は使わず、benchmarkgames のコードだけを使った。Cling は主に、C++ にコンパイルされる言語向けの高速な JIT 代替 として使っている

    • 自分のネイティブ Clojure 方言の JIT コンパイルに Cling を使っている: https://github.com/jank-lang/jank
      C++ を Clojure の世界へ持ち込み、Clojure と対話的プログラミングを C++ の世界へ持ち込もうとする試みだ
  • ソースコード: https://github.com/root-project

  • 「Eclipse IDE で CERN ROOT スクリプトと ROOT ベースのプログラムをデバッグ」だなんて
    なんてことだ、悪夢がよみがえる。ひどい環境でも 非凡なもの を作れることは確かに示している

    • Eclipse の話なのかどうか、よくわからない