Boost math constantsの変遷記録

今日気づいたのだが、Boost.math.constants にある one_div_pi は Boost 1.71.0 以前には存在しない。

背景

Boost.math.constantsは、現時点ではC++で数学定数を取得するために最もよい方法だろう。これは、以下のようにして数学定数を取得できるライブラリだ。円周率以外にも、たいていのよく使う定数はすでに入っている。

一応、少しコードを書くことで定数を追加したり、普通ではない実数型(任意精度実数型とか)に対応することも可能なようだ。

#include <boost/math/constants/constants.hpp>
constexpr auto pi = boost::math::constants::pi<double>();

www.boost.org

これに対して、非常によく使用されているが実は仕様外である、M_PIなどのマクロ定数がある。非常に厳密に言うならば、処理系はこのようなマクロを定義してはいけない。まあこのブログを読みに来た人にはどこかで聞いたことがある話だと思う。

qnighy.hatenablog.com

ほかに、将来的によりよくなるはずの方法として、C++20の<numbers>ヘッダがある。Boostと比べると定義してある定数の種類は少ないが、これでも実用上困ることはないだろう。また、標準ライブラリなので基本的に依存関係を心配せずに使えるというメリットもある。とはいえ、C++20を使えるプロジェクトはまだそう多くはないだろうから、もうしばらくの間はBoostの方が使う機会が多いのではないか。

cpprefjp.github.io

Boost.constantsの変遷

さて、今日は別のマシンで書いていたコードを家のマシンにcloneしていじろうとしたところ、boost::math::constants::one_div_piがないというエラーが出て、焦っていた。どうやらBoost 1.71.0にはこれがないらしい。リファレンスを見たところ、Boost 1.72.0で追加されたもののようだ。一応Boostのchangelogを見に行ったが、Boost全体のchangelogともなるとそれぞれがここまで些細なことを報告していると終わらなくなるのか、記載がない。

www.boost.org

そこでBoost.mathのレポジトリを見に行ってみたが、個別のリリースノートのようなものは書いていないようだ。一番最近のものには少し書かれているが、古いものにはあまりない。

github.com

Boost.mathのドキュメントのリリースノートにもそれらしい記載はなかった。

www.boost.org

これでは気づけないのも当然という気がする。とはいえこれでは少し困るので、ちょっと変遷を追いかけてみた。

BoostのWebサイトはURLにバージョンが入っているので、適当なシェルスクリプトでバージョンを回しながらwgetしてdiffを取ると簡単に変更履歴を作れる。どこまで遡るかは少し迷ったが、Ubuntu18.04のaptで入るのが1.65.0っぽいので、それより古いのはもう見なくてよかろうということで65以降を見ることにする。

1.65.0 -> 1.71.0

この間、math.constantsには特に変化はなかった。バージョン番号が粛々と上がり、Contributorの数が少し増えていた。

1.71.0 -> 1.72.0

ここでそこそこの量の定数が追加されている。

  • 等価なPOSIXのマクロ(M_PIみたいなやつ)の記述がドキュメントに足された
  • quarter_pi が追加された。
  • one_div_pi が追加された。
  • two_div_pi が追加された。
  • two_div_root_pi が追加された。
  • log2_e が追加された。

1.72.0 -> 1.73.0

ドキュメントのリファクタリングが行われている。

1.73.0 -> 1.74.0

変化なし。

1.74.0 -> 1.75.0

そんな頻繁に使うか? というような定数がたくさん導入されている。一部には予想される使用頻度に比べて圧倒的に一般的な名前がつけられているような気がしなくもない……。

1.75.0 -> 1.76.0

特に変化はない。

おわり

one_div_piみたいな頻出っぽいものが1.72.0まで入ってないというのは少し驚いた。でもよく思い返してみると数年前には「なんでone_div_piがないんだよ(ブチギレ)」みたいに言いながら自分で定数書いてた記憶があるな。

こういう明らかに頻出なものが割と最近まで入ってなかったかと思えば、これそんな頻繁に使うか? みたいな値がしれっと入ってたりもするので、結構意外な部分が大きい。 どのへんまでをユーザーにやらせて、どこからはライブラリが責任もってメンテするかを決めるのは大変そうですね(他人事)。