Re: [boost] [math toolkit] Formal Review today, April 11, through April 20

From: John Phillips (phillips_at_[hidden])
Date: 2007-04-25 11:29:56

Matthias Schabel wrote:
> 
> Here are some questions you might want to answer in your review:
> 	• 	What is your evaluation of the design?

   A very good design. Choices of when to use classes, member functions 
and free functions are well reasoned and well documented. Use flows 
sensibly from the structure of the library.

> 	• 	What is your evaluation of the implementation?

   Quite good, though I have a few nits to pick.
   Many of the special functions are implemented as rational 
approximations. I'm curious whether polynomial approximations were also 
tested. I know that in most cases it takes a higher degree polynomial 
approximation to reach similar accuracy, so the total operation count 
can benefit from rational approximations, however, not all operations 
are created equal. In most common modern architectures a divide takes 
about 10 times as long as a multiply or add. So, it may not be a savings 
to replace 5 multiply/adds  with 1 divide. Other factors such as 
processor pipelining make this a difficult question to answer without 
timing tests, so testing is needed to find the best mix. Unfortunately, 
I don't currently have the time to run the tests myself. Since this is a 
detail that is hidden from the user, later testing could lead to a 
change in the implementation without causing an issue.
   I'm also curious about the source for the coefficients in these 
expansions. I've looked at a couple using the Maple provided routines 
for producing minimax approximations and gotten somewhat different 
results. Rational coefficients via minimax is a known area where though 
errors are common (the problem is usually ill-posed in a formal sense), 
those errors almost always cancel out. Thus I doubt this will cause any 
problem for the quality of the approximation, but I am curious.
   In general, I'm pleased to see the level of attention given to 
numeric issues and the reasonable solutions provided.

> 	• 	What is your evaluation of the documentation?

   Again, my only issues are nits.
   The documentation is huge and thorough. It almost forms a framework 
for a couple of texts. There are some minor editing issues, but so far I 
have only found one relatively major one (in the PDF, at least). In the 
introduction you give a list of the included special functions that is 
very much shorter than the real list.
   Otherwise, it is readable, informative and reasonably complete.

> 	• 	What is your evaluation of the potential usefulness of the  library?

   Inferior solutions to this set of problems are currently in wide use 
in the computational science community. Given time for people to find 
out about and adopt these, I would expect wide use in this community. I 
don't feel qualified to talk about use in the business world.

> 	• 	Did you try to use the library?  With what compiler?  Did  you  
> have any problems?

   I used it with gcc 4.0.1 for a few small examples. I'd love to 
combine it with the accumulators library for an example implementation 
of the Kolmogorov-Smirnov test, but I haven't had time, yet.

> 	• 	How much effort did you put into your evaluation? A glance? A  
> quick reading? In-depth study?

   About 4 hours with the docs, 3 hours looking at the details of the 
numerics and an hour with code. It's worthy of far more time. I just 
don't have the time, yet. I plan to continue looking and hopefully run 
some timing tests, soon.

> 	• 	Are you knowledgeable about the problem domain?

   I'm reasonably knowledgeable. My academic work involves simulations, 
statistical analyzes and some special functions. I have also taught 
computational science courses.

> 
> And finally, every review should answer this question:
> 	• 	Do you think the library should be accepted as a Boost  library?

   Yes. I do. The authors deserve high praise for producing one of the 
best facilities of this kind available. People spend a lot of money to 
license far worse software.

                        John Phillips