[review] Multiprecision review results

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-g7...

Many thanks Jeff for managing the review!
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.
As noted in a recent post - the cost of wrapping a native type inside mp_number should be close to zero now *when expression templates are off*. When ET's are turned on, this will always IMO be slower, consider an operator returning an expression template - it's basically returning a pair of references (and larger objects still for more complex expressions), where as say a wrapped integer is actually returning a smaller cheaper to copy object in that case. So for a wrapped integer, returning the result by value will always win out, and that's before you even consider the cost of unpacking the expression template. So, basically reserve expression templates for objects that are either large and/or allocate memory: I'll try to make that clearer in the docs. ~~~~ I have an open question for you all: I was planning on working on cpp_int performance next, and trying to improve the computation geometry use cases. Obviously that pushes back a potential release. The alternative is to address all the issues relating to the front end first, and aim for an earlier first release. Which would folks prefer? Regards, John.

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Sunday, August 05, 2012 9:41 AM To: boost@lists.boost.org Subject: Re: [boost] [review] Multiprecision review results
Many thanks Jeff for managing the review!
+1
I have an open question for you all: I was planning on working on cpp_int performance next, and
trying to
improve the computation geometry use cases. Obviously that pushes back a potential release. The alternative is to address all the issues relating to the front end first, and aim for an earlier first release. Which would folks prefer?
My 2p - Go for an early release. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

Obviously that pushes back a potential release. The alternative is to address all the issues relating to the front end first, and aim for an earlier first release. Which would folks prefer?
Early release please Keith Burton _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thank you very much for managing the review, Jeff.
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 <snip> 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? <snip> Yes. In my opinion, a radix-2 implementation of the boost-licensed floating-point back-end with enhanced efficiency, greater maximum digit count and sensible rounding policies is very high on my to-do list. cpp_dec_float is my main contribution to Boost.Multiprecision, and I am primarily responsible for this. I would, however, like to find one or more developers who have knowledge in this domain to assist with a potential cpp_bin_float. It's just too much work for one person and, quite frankly, there are a few trouble spots that I don't know how to deal with yet. Please also note that I can not begin working on cpp_bin_float until autumn or winter at the earliest. Thanks again to everyone who contributed to the review. Best regards, Chris.

Jeffrey Lee Hellrung, Jr. wrote:
John Maddock and Christopher Kormanyos' Multiprecision library is ACCEPTED for inclusion into Boost
Excellent! Congratulations John and Christopher! This is a major C++ milestone, given the previous faltering or aborted attempts. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (7)
-
Christopher Kormanyos
-
Jeffrey Lee Hellrung, Jr.
-
John Maddock
-
Keith Burton
-
Michael Goldshteyn
-
Paul A. Bristow
-
Stewart, Robert