gfortran

以前、R 言語中で Fortran ソースの割合がそこそこあるというメモを書きましたが、R 開発者界隈の方から Apple Silicon での fortran 最新情報が出てきました。llvm, gnu とも公式対応は以前と変わらず芳しくないようですが、gfortran に関しては個人 branch での開発が進んである程度アプリケーションが動くようです。

fortran66.hatenablog.com

BLAS/LAPACK も C で書かれたものがあるから Fortran は必要ないなどとも言われますが（そもそも FORTRAN 版の BLAS はあくまでリファレンス用途で、各ハードウェア毎にそれぞれ最適化したものをアセンブラなどで用意するのが本来の姿ですが）、リファレンス用途に独自改変をしたものがあるようで Fortran が必要なようです。この種の問題は R に限らず処々にあるのだろうと思います。

developer.r-project.org

しかし、興味深いのは R では NaN のビット配列が一意でないことを利用して、NaN 中特定の bit 列に意味を与えてデータなし NA (not available) を表すことに利用していたようなのですが、それが Apple Silicon の高速演算モードで地雷となって問題になっているらしいことです。以前 mruby が NaN の bit 列の一部を固有の意味で利用していると聞いて、将来の禍根になりそうだなと思ったら、同じようなことがこんな所で爆発していました。

これを避けるため浮動小数点演算厳密モードで計算すると多分計算が少し遅くなると思います。

グスタフソンがカーンの IEEE754 を批評して NaN がビット列を無駄にし過ぎていて、こういう冗長性がありすぎるとハック（やっつけ仕事）されて不正利用されると言っていた気がしますが、全くその通りになっていて草生えます。