[math toolkit] Formal Review today, April 11, through April 20
The formal review of the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang, begins today, April 11 and ends April 20. The library and documentation may be downloaded from the Boost Vault: http://www.boost-consulting.org/vault/index.php? &direction=0&order=&directory=Math%20-%20Numerics The Math Toolkit is divided into three interrelated components : 1) a reasonably comprehensive set of statistical distributions 2) a set of high quality special functions 3) tools needed to implement special functions Because this library subsumes a wide range of material, I anticipate that not all reviewers will feel comfortable reviewing the entirety of the library. In order to expand the potential reviewer and increase overall participation, partial reviews of one or more of the three components described above are encouraged. As this is a primarily numerical library, quality of implementation, both correctness and efficiency, is critical. The authors have provided an extensive set of tests, but, as always, more eyes catch more bugs. Attention paid to these areas by reviewers is particularly welcome. Your comments may be brief or lengthy, as long as they provide sufficient basis for the Review Manager to assess your evaluation of the library. Relevant areas include interface/design, implementation, relevance to Boost, etc... If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: • What is your evaluation of the design? • What is your evaluation of the implementation? • What is your evaluation of the documentation? • What is your evaluation of the potential usefulness of the library? • Did you try to use the library? With what compiler? Did you have any problems? • How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? • Are you knowledgeable about the problem domain? And finally, every review should answer this question: • Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Review comments can be sent to the developer list, the user list, or directly to me if you don't wish to comment publicly. Thank you in advance for your time and work on this review. Matthias Schabel Review Manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
Matthias Schabel wrote:
The formal review of the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang, begins today, April 11 and ends April 20. The library and documentation may be downloaded from the Boost Vault:
http://www.boost-consulting.org/vault/index.php? &direction=0&order=&directory=Math%20-%20Numerics
The Math Toolkit is divided into three interrelated components :
1) a reasonably comprehensive set of statistical distributions 2) a set of high quality special functions 3) tools needed to implement special functions
I thought we had relegated the tools down to an implementation detail for now in order to keep the review manageable? Of course all comments are welcome.... John.
The Math Toolkit is divided into three interrelated components :
1) a reasonably comprehensive set of statistical distributions 2) a set of high quality special functions 3) tools needed to implement special functions
I thought we had relegated the tools down to an implementation detail for now in order to keep the review manageable? Of course all comments are welcome....
I'm happy to narrow the scope - naturally, comments on the implementation are still welcome, but I will treat them in that light in assembling comments at the end. Also, to simplify tracking of the discussion, I would like to request/remind commentators to include "[math toolkit]" in the subject line of posts. Matthias
On 4/11/07, Matthias Schabel <boost@schabel-family.org> wrote:
The formal review of the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang, begins today, April 11 and ends April 20. The library and documentation may be downloaded from the Boost Vault:
http://www.boost-consulting.org/vault/index.php? &direction=0&order=&directory=Math%20-%20Numerics
The Math Toolkit is divided into three interrelated components :
1) a reasonably comprehensive set of statistical distributions 2) a set of high quality special functions 3) tools needed to implement special functions
My first (and probably only, as it is not my area) comment is that it shouldn't just be called 'The Math Toolkit". 'Math' is much much too big to fit into a single toolkit. This toolkit seems to be geared towards statistics, so should be labeled as such. I see the directory is called 'Math - Numerics', so maybe that label should be used throughout (including header files, namespaces, etc). Tony
Matthias Schabel wrote:
The formal review of the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang, begins today, April 11 and ends April 20. The library and documentation may be downloaded from the Boost Vault:
That timetable is more than a little unfortunate, as it clashes with the next C++ committee meeting next week, and the ACCU conference this week (at the same venue). Several potential reviewers will be on the road for the whole duration, and hopefully a couple of the library authors too! I'm not going to ask for an extension yet, but don't be surprised if you get that request late next week! -- AlisdairM
AlisdairM wrote:
Matthias Schabel wrote:
The formal review of the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang, begins today, April 11 and ends April 20. The library and documentation may be downloaded from the Boost Vault:
That timetable is more than a little unfortunate, as it clashes with the next C++ committee meeting next week, and the ACCU conference this week (at the same venue). Several potential reviewers will be on the road for the whole duration, and hopefully a couple of the library authors too!
I'm not going to ask for an extension yet, but don't be surprised if you get that request late next week!
For my own selfish reasons (I REALLY REALLY want to review this library, but I'm also leaving town on business for the next two weeks), I would concur that holding the review during the C++ Committee meeting week is bad. But, maybe I'll be able to find some time to do a partial review anyway ... :-) -- ------------------------------------------------------------------------------- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------
The formal review of the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang, begins today, April 11 and ends April 20. The library and documentation may be downloaded from the Boost Vault:
That timetable is more than a little unfortunate, as it clashes with the next C++ committee meeting next week, and the ACCU conference this week (at the same venue). Several potential reviewers will be on the road for the whole duration, and hopefully a couple of the library authors too!
I'm not going to ask for an extension yet, but don't be surprised if you get that request late next week!
For my own selfish reasons (I REALLY REALLY want to review this library, but I'm also leaving town on business for the next two weeks), I would concur that holding the review during the C++ Committee meeting week is bad. But, maybe I'll be able to find some time to do a partial review anyway ...
:-)
I'm happy to extend the review period, but there are two potential problems : 1) the GUID review is slated to start April 23rd. I don't expect that there would be significant crosstalk between these two reviews, but it doesn't seem to be the norm to have two reviews running concurrently. 2) I will be on vacation from April 20th-27th. On second thought, since, as review manager I don't really have to do much until the end of the review, I would be fine having the review run until the 27th. That would give me the weekend to digest posts... I'll inquire with the review wizards as to whether it would be acceptable to have some overlap between this review and the GUID review. Matthias
There have been a number of requests to extend the review period for the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang due to conflicts with various meetings attended by a sizable number of potential reviewers of this library. For this reason, we have extended the review to run through April 27th. Your friendly Review Manager - Matthias
Here is my review of the Math Toolkit library:
What is your evaluation of the design?
Intuitive and easy to use.
What is your evaluation of the implementation?
No opinion.
What is your evaluation of the documentation?
Excellent.
What is your evaluation of the potential usefulness of the library?
Extremely useful for those of us who use statistics.
Did you try to use the library? With what compiler? Did you have any problems?
I tried the library with VC++ 7.1. No problems.
How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I downloaded, compiled and tested the library. I wrote and tested a piece of code that did some statistical tests with real data (gene expression data from the plant Arabidopsis Thaliana.) I may have spent two hours on this.
Are you knowledgeable about the problem domain?
I'm a mathematician, and I work in bioinformatics, a field that makes heavy use of statistics. So I'm qualified to evaluate the statistics part of the library. I have less experience with special functions, so this review is only about the statistics part.
Do you think the library should be accepted as a Boost library?
Yes, absolutely. This is an important and very well written library. I will use it in my future work. -- Johan Råde
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
John Phillips wrote:
• 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.
I admit that so far I've paid very little attention to speed: other than to try and make sure it's not actually awful ;-) There's a lot of scope for optimising both the rational and polynomial function evaluation, but that's a research project in it's own right and rather platform specific. For the approximations I always tried to use the least number of terms possible, my experience is that polynomial approximation works wonders up to a few digits, but beyond that you often get no more accurate no matter how many terms you pile on: depends a lot on the function of course. However, I believe almost all the approximations can be improved on, it really depends how much time you're prepared to spend thrashing around trying to find the darn things!
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.
Right, there's good literature supporting the idea that coefficients can be in error without necessarily adversely effecting the result. The important thing is to test the approximation to make sure there are no ill-conditioned areas (the coefficients can give a theoretically good solution, but the resulting rational function may be un-computable at fixed precision). In the Bessel functions Xiaogang took his coeffiecients from Hart's, "Computer Approximations" (the accuracy is limited to about 20 digits). For the special functions that are mine, I devised the approximations myself using my own Remez code (which actually seemed like a good idea at the time!). My Remez code is stilla little hairy, but I've tested against a few published minimax solutions for trivial functions like exp and got excellent agreement, so I'm pretty sure it's giving good results. That's allowed me to push the approximations to 128-bit (35-digit) precision, which I believe is pretty much unique - I don't know of anyone else publishing coefficients to that accuracy at this time. I suspect some of these approximations can be improved upon, but as ever it's a case of how much time and effort you're prepared to invest. I haven't had a chance to push the Bessel function approximations to 128-bit precision either :-(
• 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
What was the issue? Thanks.
the introduction you give a list of the included special functions that is very much shorter than the real list.
Will fix.
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.
Thank you! John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Phillips Sent: 25 April 2007 16:30 To: boost@lists.boost.org Subject: Re: [boost] [math toolkit] Formal Review today, April 11, through April 20
. 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,
Since my most significant contribution has probably been 'nit-nurse', I'd be grateful for a detailed list of nitlets that you noted in reading, or even what you vaguely remember being wrong - I've read it enough times for my eyes to glaze over ;-)
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.
As John has noted, we have been adding to the code (for example the Pareto distribution as requested) but the documentation hasn't quite kept up. When we've got a list of minor nits to squash, we will have a fuller update. (The production of the pdf from Quickbook is harder than the html - indeed the whole process isn't as smooth as one would like, and we'd like the graphs to be in SVG rather than jpegs, and to use MathML for equations etc). We'd also like to add more examples - user contributions will be most welcome. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
This is partial review of math toolkit.
What is your evaluation of the design?
Very good: Intuitive, easy to use, efficient and extensible. There is just one tiny detail of the design which might be worth a discussion, though it seems to be primarily a matter of taste: The naming of the "estimate_xxx" functions and their placement as static methods in the distribution classes. - When statisticians talk about estimating parameters of a distribution they usually mean fitting the distribution to a particular sample, for instance by means of maximum likelihood estimation (at least, that's my impression). Hence I find the naming of the static "estimate_" methods in the distribution classes a little bit unfortunate. Instead of estimate_degrees_of_freedom I would prefer find_minimum_sample_size, instead of estimate_lower_bound_on_p maybe something like confidence_interval_lower_bound_for_p (which I also find more descriptive), etc. - Apart from estimate_alpha and estimate_beta for the beta distribution, the "estimate_" functions generally serve a purpose in the context of a statistical model, not just a particular distribution. Take for example the "estimate_degrees_of_freedom" method of the student t distribution. The statistical context in which one would need the function is an i.i.d. normally distributed sample with a mean and variance estimated through the standard sample estimators. In principle one could come up with arbitrarily many statistical models and applicable "estimate" methods, and their placement into one of the classes might well be ambiguous. - It might be preferable to keep these functions separate from the distribution classes, for example, making the "estimate_degrees_of_freedom" method of the t distribution a free function "find_minimum_sample_size_for_standard_t_test". Naming would obviously not be easy, but that is also because currently the names mainly reflect the parameter and the distribution which are involved in the computation.
What is your evaluation of the implementation?
I did not evaluate the implementation, though the documentation suggests a very competent implementation. The documentation makes also clear that the authors' primary focus was on numerical accuracy, which is comforting to know.
What is your evaluation of the documentation?
Excellent: well written and very comprehensive. The discussion of the used algorithms (including references) and accuracy bounds from empirical tests is one of the best features. A nice complementary feature to the statistical examples would be a table or listing that translates between statistical tests/practices and their implementation using the toolkit, which could summarize the examples and could go beyond the examples by providing a reference for further tests, etc. At the end of this email I list some minuscule issues in the introduction to the statistical part of the library.
Do you think the library should be accepted as a Boost library?
Yes. This is a library that fills an important gap and might be the beginning of an even more comprehensive math library within Boost. Best regards, Stephan Some minor issues in the documentation: I find the second paragraph in the tip "Random numbers that approximate Quantiles of Distributions" in the "Statistical Distributions Overview" misleading. In general the difference in purposes of Boost.Random and Math toolkit has not much to do with accuracy. Could the tip "Random variates and distribution parameters" in the "Statistical Distributions Overview" be moved after the first example "f(k; n, p)"? [There's also a separate redundant section "Random Variate and Distribution Parameters". "Discrete Probability Distributions" is a duplicate, too.] Nitpicking: For which distribution may "Mathematically, the random variate [may] take an (+ or -) infinite value" (still in "Statistical Distributions Overview")? Certain functions like the CDF may still make sense for infinity, but usually variates (realizations of the variable) can't be infinite. At the beginning of the example "Calculating confidence intervals on the mean with the Students-t distribution" the i.i.d. normal assumption should be stated before introducing the confidence interval. Similar comments apply to the other examples. In the example "Testing a sample mean for difference from "true" mean" the wording is a little bit lax from a statistical point of view. One doesn't "accept" the null hypothesis, one can only "not reject" it, just as one can't "reject" the alternative hypothesis. The output should be worded in terms of rejection or non-rejection of the null hypothesis in the two-sided or one-sided t-tests. Similar comments apply to the other examples.
Paris (U.E.), le 27/04/2007 Bonsoir I am posting a very short review now, and hopefully a longer one (answering the questions I did not have time for tonight) later in the day. In the interest of full disclosure, I should add that while I appear among the authors of this package, this is only due to the fact that I was responsible for a very small kernel of the current proposal, which I needed for another library. In more ways than one, my input was just a grain of sand, and the current proposal is a resulting pearl! I therefore believe I can post a review here without being both judge and jury. In article <92623D3D-1781-45AB-8DF6-0B1E5AB82409@schabel-family.org>, Matthias Schabel <boost@schabel-family.org> wrote:
The formal review of the Math Toolkit, submitted by John Maddock, Paul Bristow, Hubert Holin, and Xiaogang Zhang, begins today, April 11 and ends April 20. The library and documentation may be downloaded from the Boost Vault:
http://www.boost-consulting.org/vault/index.php? &direction=0&order=&directory=Math%20-%20Numerics
The Math Toolkit is divided into three interrelated components :
1) a reasonably comprehensive set of statistical distributions 2) a set of high quality special functions 3) tools needed to implement special functions
Because this library subsumes a wide range of material, I anticipate that not all reviewers will feel comfortable reviewing the entirety of the library. In order to expand the potential reviewer and increase overall participation, partial reviews of one or more of the three components described above are encouraged. As this is a primarily numerical library, quality of implementation, both correctness and efficiency, is critical. The authors have provided an extensive set of tests, but, as always, more eyes catch more bugs. Attention paid to these areas by reviewers is particularly welcome.
Your comments may be brief or lengthy, as long as they provide sufficient basis for the Review Manager to assess your evaluation of the library. Relevant areas include interface/design, implementation, relevance to Boost, etc... If you identify problems along the way, please note if they are minor, serious, or showstoppers.
Here are some questions you might want to answer in your review: What is your evaluation of the design?
The basic premise of being able to work generically is preserved with the current design, unlike with what has been put forward for the same field in C, and this is, in my opinion, HUGELY important. As well, when there is need for it, specialized, non-generic versions sometimes exists (such as for the beta function). This is a best of both world situation. As other reviewers have noted, some methods may perhaps not be the most accurate (though this is rather open to debate) for some of the functions offered here, and it is certain that other methods of computations will be found, in time. As well, sometimes a *Quick* and dirty implementation is more useful than a careful, precise, one. This is one of the fundamental dilemma of the field. The choice made here, as I understand, is to favor accuracy, and definitely is one I prefer. Still, to address the need of the other possible users, perhaps a policy parameter could have been used. As no library I know has actually gone so far and implemented such an approach, this can absolutely not be held against the authors or the library. It can, at best, represent an idea for the further evolution of the library as could be interval computation, another occasional (if not exactly frequent) request.
What is your evaluation of the implementation?
(to be detailed later)
What is your evaluation of the documentation?
Thorough, usable, informative.
What is your evaluation of the potential usefulness of the library?
I can't overstate the need for a library of the kind put forward here for people like me who do scientific computations. As other reviewers have pointed out, commercial packages do exist, but this one is free, and in my opinion is one of the better (free or not). This is not a full implementation of the mythical "Digital Library of Mathematical Functions", but at least it *EXISTS*, and will prove extremely useful to many.
Did you try to use the library? With what compiler? Did you have any problems? (to be detailed later)
How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? (to be detailed later)
Are you knowledgeable about the problem domain?
I am not a statistician, though I use statistics frequently. I am not a numerical analysis specialist, though I have on occasion to play the part of one at work. I do sometimes have to find ways to compute what can only be called "special functions", as this turns out to be a necessity for other work, time and again. In other words, I am neck deep into that field as a (needy) user, and only moderately proficient at solving the problems of that field.
And finally, every review should answer this question: Do you think the library should be accepted as a Boost library?
The library ***should be accepted as a Boost library***.
Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
Review comments can be sent to the developer list, the user list, or directly to me if you don't wish to comment publicly. Thank you in advance for your time and work on this review.
Matthias Schabel Review Manager
Hubert Holin
Hi! Matthias Schabel wrote:
Here are some questions you might want to answer in your review: ? What is your evaluation of the design?
Great! Really Great! Especially statistical part is designed very carefully. Small distribution classes is an example what is enough to design good program (library). The all library (in my opinion) is prepared to be flexible and lightweight. In one of my tasks I need to prepare polymorphic structure for distributions. Thanks to this very good design, I do it quickly. It means that there are no problems with design to make enhancements for some particular cases.
? What is your evaluation of the implementation?
Very good. The code is boost like. Prefers usage of references. Template functions, ale prepared cerefully so usage is very simple. User do not need to allocate dynamically a memory to play with functions - no dynamical allocations of memory = no possible memory leaks.
? What is your evaluation of the documentation?
Very good.
? What is your evaluation of the potential usefulness of the library?
I am using it :-). For those who are working on the topics covered in the library it can be very good library.
? Did you try to use the library?
Of course.
With what compiler?
Gcc 4.1.1
Did you have any problems?
Rather not - to be honest - I do not remember any problems :-).
? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Close to "in-depth study". I watched in the implementation. I have read documentation. And finally use this library.
? Are you knowledgeable about the problem domain?
Rather yes. I am working on simulations of the queue (stochastic) systems.
And finally, every review should answer this question: ? Do you think the library should be accepted as a Boost library?
Yes. However I suggest to slowly extend its volume. Because there is a lack of very good C++ math libraries which are both designed and developed for C++ programs. Best regards. -- |\/\/| Seweryn Habdank-Wojewódzki \/\/
Hi! Matthias Schabel wrote:
Here are some questions you might want to answer in your review: ? What is your evaluation of the design?
Great! Really Great! Especially statistical part is designed very carefully. Small distribution classes is an example what is enough to design good program (library). The all library (in my opinion) is prepared to be flexible and lightweight. In one of my tasks I need to prepare polymorphic structure for distributions. Thanks to this very good design, I do it quickly. It means that there are no problems with design to make enhancements for some particular cases.
? What is your evaluation of the implementation?
Very good. The code is boost like. Prefers usage of references. Template functions, ale prepared cerefully so usage is very simple. User do not need to allocate dynamically a memory to play with functions - no dynamical allocations of memory = no possible memory leaks.
? What is your evaluation of the documentation?
Very good.
? What is your evaluation of the potential usefulness of the library?
I am using it :-). For those who are working on the topics covered in the library it can be very good library.
? Did you try to use the library?
Of course.
With what compiler?
Gcc 4.1.1
Did you have any problems?
Rather not - to be honest - I do not remember any problems :-).
? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Close to "in-depth study". I watched in the implementation. I have read documentation. And finally use this library.
? Are you knowledgeable about the problem domain?
Rather yes. I am working on simulations of the queue (stochastic) systems.
And finally, every review should answer this question: ? Do you think the library should be accepted as a Boost library?
Yes. However I suggest to slowly extend its volume. Because there is a lack of very good C++ math libraries which are both designed and developed for C++ programs. Best regards. -- |\/\/| Seweryn Habdank-Wojewódzki \/\/
The review period for the proposed Math Toolkit by John Maddock and Paul Bristow is now over. I will be assembling responses and put together a synopsis over then next few days. Thanks to everyone who participated and submitted reviews. Matthias
Matthias Schabel wrote:
The review period for the proposed Math Toolkit by John Maddock and Paul Bristow is now over. I will be assembling responses and put together a synopsis over then next few days. Thanks to everyone who participated and submitted reviews.
Do we want to check whether there are still any pending reviews? John.
participants (11)
-
AlisdairM -
Gottlob Frege -
Hubert Holin -
Johan Råde -
John Maddock -
John Phillips -
Kevin Lynch -
Matthias Schabel -
Paul A Bristow -
Seweryn Habdank-Wojewódzki -
Stephan Tolksdorf