On 6/8/2012 10:28 AM, Jeffrey Lee Hellrung, Jr. wrote:
Any review discussion should take place on the developers' list ( boost@lists.boost.org), and anyone may submit a formal review, either publicly to the entire list or privately to just myself.
As usual, please consider the following questions in your formal review:
This is my review of the multiprecision library. I am going to use the term "general type" to refer to either 'integer', 'rational number', or 'floating point' type no matter what the backend is.
What is your evaluation of the design?
The design is logical. I like the fact that various backends are supported and that there is always a Boost backend to fall back on for a general type. I also like it very much that future backends are also supported via the backend requirements.
What is your evaluation of the implementation?
I looked the implementation from the point of view as an end-user but did not look at the details. I did not have the chance to test the implementation so my comments are based on the doc. It seems very easy to use the implementation. The hardest part is that some of the backends have their own rules, which are not entirely consistent with other backends of the same general type ( integer, rational number, or floating point ). This does not occur very often but when it does the end-user has to be aware of it. These slight inconsistencies are documented but I would like to see an attempt to regularize them by the front-end, perhaps via a compile time trait. As a single example of this the gmp_int backend triggers a division by 0 signal when one tries to divide the integer by 0; the tom_int raises a hardward signal with a division by 0; the cpp_int throws a std::runtime_error with a division by 0. I would like to see some means by which I could use any integer backend and know that a std::runtime_error would be thrown by a division by 0. It would be nice if other partcularities could be regularized in a similar manner. This would make it little easier to use the library generically. The library allows conversions between values of a general type no matter what the backend. This is good. The library allows what I think of as widening conversions, from integer to rational or float, and from rational to float. This is good. Both follow the similar idea in C++ itself. In C++ one can do a narrowing conversion if a static_cast is used, otherwise a compiler error ensues. The document also explains that a narrowing conversion will produce a compiler error. Can a static_cast be used to do a narrowing conversion ? The introduction states that "mixing arithmetic operations using types of different precision is strictly forbidden". I was disappointed not to read any discussion of why this would be so. In C++ this is not the case with integer and floating point types. Considering that this library does allow conversons within the same general type and widening conversions it would seem that doing operations with different types could be technically allowed fairly easily, by converting all values in an operation to the largest type and/or greatest precision.
What is your evaluation of the documentation?
The doc is totally adeqate.
What is your evaluation of the potential usefulness of the library?
Tremendously important to C++. Although I am not a mathematician myself, my background in math and science suggests that a multiprecision library involving huge and/or highly accurate numbers is an absolute necesssity to serious mathematical and scientific calculations.
Did you try to use the library? With what compiler? Did you have any problems?
I did not have time to try it out with any compiler. I originally wanted to modify some of the tests in the library so I could try them out with the compilers I have, but the tests were too complicated for me to understand easily. I am going to try to cobble together some simple tests for myself during the upcoming week but i wanted to submit my review nonetheless before the period for it was over.
How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I put a good deal of effort attempting to understand the pluses and negatives of the design, and thinking about the problems involved.
Are you knowledgeable about the problem domain?
I am fairly knowledgeable about mathematics without being a mathematician or claiming expertise in any particular area of mathematics.
And, most importantly, please explicitly answer the following question:
Do you think the library should be accepted as a Boost library?
I think the library should be accepted as a Boost library. I do think more work needs to be done to make the library usable, but I have no doubt the authors of the library are capable of doing so.
Lastly, please consider that John and Christopher have compiled a TODO list [1] based on pre-review comments. Feel free to comment on the priority and necessity of such TODO items, and whether any might be show-stoppers or warrant conditional acceptance of the library.
I would like to see more work done in the two areas I mentioned: regularizing the backends and performing operations with different precisions. I do realize that accuracy is paramount when using the library, but in the tradition of C++ as long as the end-user knows any possible shortcoming of these two areas I think they should be allowed if technically feasible. Eddie Diener