[boost] [review] Multiprecision review results

Subject: [boost] [review] Multiprecision review results
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-08-04 17:58:26

Summary
--------
John Maddock and Christopher Kormanyos' Multiprecision library is ACCEPTED
for inclusion into Boost, with 8 YES votes, 1 NO vote, and 1 CONDITIONAL
vote.

Details
--------
Most reviewers noted that this was a sufficiently good first step toward
extended precision arithmetic for inclusion into Boost. I think John and
Chris will agree that there remains quite a bit of work left to do, but as
one reviewer noted, John has an excellent track record regarding Boost
development and Chris has been extremely dedicated during the pre-review
development, review process, and post-review development, so I think this
bodes well for the library's future.

I'm going to highlight what I perceive to be some of the bigger issues
raised by various individuals involved with in discussion, but I will share
all my notes via Google Docs [1], and of course even further details are
available in the mailing list archive. I note that many of the issues
raised during the review have already been addressed by John and Chris.

Mixed-Type Arithmetic
--------
This has come up over and over again, especially in the context of allowing
extended precision types within the same "family" to interoperate, which I
think is tractable. Removing my review manager hat for a moment, perhaps a
tag dispatching system similar to Boost.MPL or Boost.Fusion could be used,
where all arithmetic types within the same family have the same tag, and
hence only allow mixing types with the same tag. Most types will have a
unique tag (which, I don't know, could default precisely to the arithmetic
type?), but, e.g., Vicente's family of fixed-precision (and maybe even
fixed-point) types would all be identifiable as being in the same family,
and a traits class would determine the result types of the various
arithmetic operations.

Mixed-type arithmetic outside the above scope seems more tricky, but some
users seem to still desire this in some form. Actual desired use cases will
undoubtedly help here.

Naming
--------
Several commented on the redundancy of "mp_" prefix for identifiers already
residing the boost::mp namespace.

Narrowing Conversions
--------
cpp_dec_float should round rather than truncate on narrowing conversions.
Review manager hat off: I wonder if a radix-2 implementation of an
arbitrary precision float should ultimately be prioritized and recommended
over the present radix-10 implementation?

It sounds like conversions in general should be reviewed, but I'm entirely
sure myself where they all stand. If possible, narrowing conversions should
be explicit while others (that would guarantee no loss of precision) may be
implicit. This would be a departure from C++ builtin types.

Performance
--------
Phil, the lone NO vote, lamented that the scope of the library was
evidently beyond simple fixed-precision (e.g., 128-bit or 256-bit) integral
types, which is his desired use case. Indeed, at least in an earlier
version of MP, expression templates seemed to give a performance penalty
relative to using the raw back-end types; in theory, expression templates
should give no performance hit, but compilers just may not be there yet. In
any case, several reviewers requested that the scope of the library be
clarified up front in the documentation.

Regularization/Normalization of Back-End Behavior via Front-End
--------
As Edward pointed out, different back-ends generally have different
behavior on some "exceptional" cases, making use of the corresponding
front-ends in generic contexts at times cumbersome (specifically when the
generic context needs to handle said exceptional cases). A couple examples
given were division-by-zero and conversion from a string with invalid
characters. It is by no means *necessary* to regularize/normalize *all*
such differences, but as many as possible and practical should be
identified, considered, and documented.

Separation of Data Structures and Algorithms
--------
Though requested, John and Steven have maintained that this simply isn't
very practical. I've gathered that there are too many special cases that
(1) would make implementations a nightmare; and (2) would have be addressed
very carefully (i.e., in a likely not-very-readable way) to avoid any
performance hits. Since this has come up a few times, maybe something could
be said in the documentation about this.

Thanks to everyone who submitted reviews and participated in the
discussion. Let me know if I left out anything you feel is particularly
significant or inaccurate.

- Jeff

[1]
https://docs.google.com/document/d/19YgtWBQt0lpjJoJDOtAlScZAZyOwzbHimiYTi-g7bLw/edit