以下、レビュー結果の翻訳です。
==
John MaddockとChristopher Kormanyosの多倍長演算ライブラリBoost.Multiprecisionが、賛成8票、反対1票、条件付き賛成1票で採択されました。
詳細
ほとんどのレビュアーは、Boostの多倍長演算ライブラリの第1歩として十分に良いだろうという評価をした。JohnとChrisは、やり残した作業がかなり残っていることに同意したように思う。しかし、1人のレビュアーが述べたように、JohnはBoostに関する優れた実績を持っており、またChrisは事前レビューでの開発やレビュープロセス、レビュー後の開発においてとても熱心に携わってくれた。これは、このライブラリにとって将来の良い予兆であるように思う。
私がノートをとったGoogleDocsには、議論の中でさまざまな人々が提起した問題を記載した。大きな問題となった部分を強調表示するつもりだ。さらなる詳細は以下の通り。
混合型演算
これは繰り返し議論された、同じファミリーの拡張精度型の相互運用性を許可するもので、私は扱いやすいと感じる。おそらく、現時点ではではBoost.MPLまたはBoost.Fusionに似たタグディスパッチシステムを使用でき、同じファミリ内のすべての算術型は同じタグを持っており、それによって同じタグを持つ混合タイプを許可する。ほとんどの型がユニークなタグを持っており(私はくわしく知らないが、算術演算の正確なデフォルト設定ができる？)、たとえば固定精度(とおそらく同じ固定小数点)型はすべて同じファミリーであるとして操作でき、traitクラスはさまざまな結果型を決定できるだろう。
混合型演算はだいぶトリッキーに見えるが、一部のユーザーが何らかの形でこれを望んでいるようだ。実際にそれを必要とするユースケースでは、間違いなく役立つ。
命名
いくつかのmp_プレフィックスを持つ識別子が、boost::mp名前空間で定義される冗長性について指摘があった。
縮小変換(narrowing conversion)
cpp_dec_floatは縮小変換で、丸めるのではなく、切り捨てる必要がある。
任意精度floatの基数2の実装は、基数10の実装を優先、推奨したほうがいいのではないだろうか。
これは一般的な変換を見直すべきというように聞こえるが、私は彼ら全員がどういう立場にいるかについて確信がある。可能であれば、縮小変換は暗黙的よりも明示的であるべきだ(それは精度の損失に関する保証がない)。これは、C++の組込み型からの発展である。
パフォーマンス
唯一の反対票を入れたPhilは、単純な固定精度を超えた整数型(たとえば128ビットや256ビット)が彼の希望するユースケースだったが、このライブラリのスコープ外であったことを嘆いた。たしかに、少なくても以前のMPのバージョンは、式テンプレートがパフォーマンスペナルティを与えるように見えた。理論的には、式テンプレートは生のバックエンドに相対的なパフォーマンスヒットを与えることはないはずだが、コンパイラがまだ対応できていないのかもしれない。いくつかのレビューは、ドキュメントにライブラリのスコープを明らかにすることを要求した。
フロントエンドを介したバックエンド動作の正則化(Regularization)／正規化(Normalization)
Edwardが指摘したように、いくつかの特殊ケースでは、バックエンドが異なる振る舞いをし、ジェネリックコンテキストの対応するフロントエンドが異なる動作をする場合がある。与えられたいくつかの例としては、ゼロ除算、無効な文字を含む文字列から変換があった。異なる部分を全て正則化／正規化する必要はないが、可能な限り多くを確認し、考慮し、ドキュメント化されなければならない。
データ構造とアルゴリズムの分離
これはリクエストされたものの、JohnとStevenは単に実用的でないということで維持している。私はあまりにも多くの特殊ケースがあることをまとめた。(1)実装が悪夢のようになり、(2)パフォーマンスに影響を与えないよう、非常に慎重な対処が必要になるだろう。これは数回話がでているので、たぶん誰かがこの可能性についてドキュメントに記載できるだろう。
レビューを提出し、議論に参加してくれた皆さんに感謝します。レビューに関して漏れや不正確な部分があったら知らせてください。
