- Boost-announce - lists.boost.org

Ann: Statistical distributions / Mathematical Special Functions
by John Maddock 04 Oct '06

04 Oct '06

This package consists of 3 related components, and we're now seeking further feedback on these before the final push prior to a review: Statistical Distributions ~~~~~~~~~~~~~~~~~~~~~~~~~ Following feedback from the previous preview, we have re-organised so that distributions are now C++ classes. See the docs and especially the tutorial for illustrations on how this will be useful in real life. We would especially welcome feedback from those with experience of using statistics, and indeed from professional statisticians who are probably not Boosters. Mathematical Special Functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ These are currently focused on those functions that are useful for statistical applications: Floating point classification. Gamma/lgamma/digamma/beta/erf/erfc Ratios of gamma functions Factorials The incomplete gamma and beta functions. The inverses of the gamma, beta, and error functions. Derivatives of the incomplete gamma and beta functions. Compared to the previous release, most of the changes involve accuracy and quality of implementation issues. Error handling has now been revised to provide a comprehensive package-wide error handling scheme complete with meaningful error messages. Toolkit ~~~~~~~ Provides tools to assist in the implementation of numerical methods: Infinite series evaluation. Continued fraction evaluation. Polynomial and rational function evaluation. Root finding with derivatives (Newton/Halley/Schroeder methods). Root finding without derivatives. Function minimisation. Misc Tools ~~~~~~~~~~ These are strictly experimental, but are used in the development of approximations: they are provided to hopefully encourage others to develop further special function implementations. Tools include: Polynomial arithmetic and manipulation. Minimax approximations (the Remez algorithm). Helper functions used in testing etc. Documentation and source downloads are available online at www.johnmaddock.co.uk/toolkit Regards, John Maddock.

1 0

BoostCon 2007 Call for Proposals
by Beman Dawes 30 Sep '06

30 Sep '06

The first annual Boost conference will take place in Aspen, Colorado, May 14-18, 2007. BoostCon 2007 is looking for session presenters. We invite you to propose a session. For details on how to become a presenter, see www.boost.org/more/BoostCon07_session_call.html This inaugural Boost conference promises to be the main face-to-face venue for all things Boost, from using libraries to writing them, from evangelizing Boost to deployment within your organization, from infrastructure and process to vision and mission, and from TR1 to TR2. Given the range and interests of the participants, the event is going to be intense and in-depth. For more information about the conference, see www.boost.org/more/BoostCon07.html --The Organizing Committee David Abrahams Beman Dawes Jeff Garland Joel de Guzman Kevlin Henney Howard Hinnant Scott Meyers Eric Niebler Sean Parent Rene Rivera Jeremy Siek Matthias Troyer

1 0

Boost.MPI accepted
by Jeremy Siek 21 Sep '06

21 Sep '06

It is my pleasure to announce that Boost.MPI has been accepted as a Boost library. Congratulations to Doug Gregor and Matthias Troyer on their excellent contribution to Boost! One particularly nice aspect of Boost.MPI is the way it leverages the Boost serialization library. So also thanks to the author of that library, Robert Ramey. Yeah generic programming and code reuse! I would also like to thank all of the people that took some time to review Boost.MPI and participate in the review discussion: Dean Michael Berris, Robert Ramey, David Abrahams, Geoffrey Irving, John Fletcher, John Phillips, and Noel Belcourt. During the review, several suggestions for improvement were made, which I recommend that the authors take action on as they prepare Boost.MPI to be included in Boost. 1. Named parameters in the interface 2. Revise introduction to focus more on describing what Boost.MPI is, and move info about how Boost.MPI is implemented to a later section. 3. Document the performance characteristics of functions, e.g., Create_vector. 4. A copy-edit pass over the docs to catch typos, etc. 5. Hooks for dispatching between the underlying MPI implementation vs. a Boost.MPI provided impl. Cheers, Jeremy __________________________________ Jeremy Siek <siek(a)cs.colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder

1 0

Fwd: [boost] [Review][MPI] Boost.MPI review begins
by Ronald Garcia 07 Sep '06

07 Sep '06

Begin forwarded message: > From: Jeremy Graham Siek <jsiek(a)osl.iu.edu> > Date: September 6, 2006 3:16:06 PM EDT > To: Boost mailing list <boost(a)lists.boost.org>, Boost Announce > <boost-announce(a)lists.boost.org> > Subject: [boost] [Review][MPI] Boost.MPI review begins > Reply-To: boost(a)lists.boost.org > > Hi All, > > The view of the Boost.MPI (for Message Passing Interface) begins > today, Sept. 6 and continues through Sept. 15. > > Description: > > The Message Passing Interface (MPI) is a standard interface for > message > passing in high-performance parallel applications. It defines a > library > interface, available from C, Fortran, and C++, for which there are > many > MPI implementations. Although there exist C++ bindings for MPI, they > offer little functionality over the C bindings. The Boost.MPI library > provides an alternative C++ interface to MPI that better supports > modern C++ development styles, including complete support for user- > defined > data types and C++ Standard Library types, arbitrary function objects > for > colective algorithms, and the use of modern C++ library techniques to > maintain maximal efficiency. As an example, one can concatenate the > std::strings stored on each processor with a single reduce call and > the function object std::plus<std::string>. However, if the call to > reduce is merely computing the sum of integers, the implementation > transforms into the appropriate call to MPI_Reduce. For more > information > about the design of Boost.MPI, see our design philosophy. > > The review tarball is here: > > http://www.generic-programming.org/~dgregor/boost.mpi/boost- > mpi-20060906.tgz > > Online documentation is available here: > > http://www.generic-programming.org/~dgregor/boost.mpi/libs/ > parallel/doc/html/ > > PDF documentation is available here: > > http://www.generic-programming.org/~dgregor/boost.mpi/mpi.pdf > > > Review questions > ================ > > Please always explicitly state in your review, whether you think the > library should be accepted into Boost. > > You might want to comment on the following questions: > > - 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? > > Cheers, > Jeremy > > __________________________________ > Jeremy Siek <siek(a)cs.colorado.edu> > Visiting Assistant Professor > Department of Computer Science > University of Colorado at Boulder > > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/ > listinfo.cgi/boost

1 0

[regex] Thread safety patch.
by John Maddock 01 Aug '06

01 Aug '06

With apologies to all concerned, and thanks to Aleksey Sanin for tracking down the problem, there is a const-correctness bug in Boost.Regex-1.33.x that strikes only in multithreaded programs on Unix platforms, if: * Multiple threads construct regexes concurrently, or * Multiple threads perform search and replace operations concurrently. There are two possible fixes: * Apply the attached patch (this has just gone into cvs along with an updated test case that detects the issue). Or, * define BOOST_REGEX_USE_C_LOCALE in boost/user.hpp and rebuild everything. Regards, John Maddock.

1 0

[Review results][PQS]
by fred bertsch 19 Jun '06

19 Jun '06

The Physical Quantities System review has ended, and, unfortunately, we are going to have to turn it down at this time. However, it is clear from the reviews that there is an enormous amount of interest in the library. I'm really hoping that that Andy Little will continue his work on it and resubmit it for review. Andy has been following the large discussion of PQS, so I will not enumerate the more minor criticisms included there. Some of the major criticisms that influenced my difficult decision include the following: * Many of the reviews liked the documentation, but improvements there would help out for a large number of reviewers. * If the library were more flexible about the type system used, several reviewers would have been happier. However, I would suggest that as long as a plan is in place for improving the flexibility, this should not prevent an initial version of the library from being accepted. * Since the library includes a large number of compile-time type manipulations, it would be great if the library included standard metafunctions to query these types. In addition, following other template metaprogramming conventions established within Boost such as documenting the concepts used would be a great help. I'd like to thank Andy Little for the work done so far on PQS and also for responding rapidly to the prolific discussion on the developer's list. -Fred Bertsch

1 0

[Review][PQS] Review ends
by fred bertsch 09 Jun '06

09 Jun '06

Hello, boosters! Any given day exists for 50 hours, but it does end at some point. Likewise, the PQS review ends at some point. I will arbitrarily say midnight UTC and the timezone of the author. However, it will take me roughly a week to collate all of the reviews and reach an official decision, so don't feel shy about posting or mailing me additional reviews. I thank the reviewers very much for reviewing the library, and I thank Andy Little even more for all of his work responding to the reviews and for writing the library in the first place! -Fred Bertsch

1 0

[review] Fusion Library Accepted
by Ronald Garcia 05 Jun '06

05 Jun '06

Dear All, I am pleased to announce that the Fusion compile-time/run-time hybrid heterogeneous container and algorithm library by Joel de Guzman and Dan Marsden has been accepted into Boost. The library received 7 YES votes and 0 NO votes, with one abstention. Detailed Review Comments ------------------------ The following comments refer to issues that the library authors should address prior to merging the library into CVS: * Documentation: Many of the reviewers stated that they would like to see more tutorial documentation that demonstrates not only what the particular constructs in Fusion do, but also how they are expected to be used. A reasonably concise motivating example has been requested. It has already been pointed out that Fusion is used for some other boost libraries. A well-developed and self-contained case study of when and how to use Fusion would be greatly appreciated. The relationship between this library and the current Boost.Tuple library, as well as Boost.Mpl, should be discussed. The reference documentation is quite thorough and detailed comments regarding them have already been addressed by the authors. However the notion of "views" requires greater documentation. The examples in the algorithm sections currently do little more than demonstrate the syntax by which they can be called. Examples that more specifically express intent would be a notable improvement. (see for example Matt Austern's "Generic Programming and the STL"). In general the documentation would benefit from copy-editing. * Several commented on the use of the name "pair" for the fusion type that has typedefs for two types but only contains the second type. Although the typedefs and member names are consistent with the std::pair object, the name "pair" is confusing. The compile-time/run-time hybrid nature of this library makes it difficult to find perfect metaphors for constructs in the library. In this case, it seems better to find a term for this template (and the concept that it models) that more directly states its purpose. The name "tag_of" would also benefit from renaming. * The behavior of Fusion functions in the face of argument-dependent lookup (ADL) is not well specified. This should be made explicit in the reference documentation. The following comments refer to issues that, while not mandatory, deserve consideration: * The library name "Fusion", though not arbitrary, says little about the library's purpose. There is precedent for this within boost, however. A name change is not mandatory for the library's acceptance, but it would be worth while for the authors to consider a more telling name. * The mechanism for extending Fusion with new containers and iterators is complex and involves implementing a number of components, especially regarding iterators. An adaptation layer that is analogous to the Boost.Iterator library would be a fine addition to Fusion. * It would be beneficial to supply Boost.Serialization support for the Fusion container types. I am sure, as mentioned, that the authors of this library would accept a volunteer to implement this functionality. I would like to thank all the people who reviewed the library, voted, and otherwise participated in the discussion. Congratulations to Joel and Dan and I look forward to seeing Fusion in the Boost CVS soon. Ron Garcia

1 0

[Announce] Physical Quantities System review (May 31 through June 9)
by fred bertsch 31 May '06

31 May '06

The review of Andy Little's Physical Quantities System begins today, May 31, 2006, and continues through June 9, 2006. Download: pqs_3_1_0 is the Official Boost Review version of pqs. (Please note that pqs_3_1_0 has a bug in one header. This can be either patched according to the latest release notes, "relnotes.txt" available from http://tinyurl.com/7m5l8 or alternatively download pqs_3_1_1, which is basically equivalent to pqs_3_1_0, except the bug has been fixed there. Description PQS (Physical Quantities System) is designed to replace the use of floating point types for modelling physical quantities in C++ programs. Advantages include automated dimensional analysis checking, automatic unit conversions, self documentation of code and uniform mechanisms for dealing with physical quantities overall, allowing better interoperability, accuracy and repeatability among engineering, physics and trade applications. The library will ultimately consist of various types for modelling quantities in different situations. The t1_quantity, which is the first to be implemented, performs all its dimensional analysis checks as well as parts of its unit conversion calculations, at compile time rather than runtime, for maximum efficiency. PQS is designed with a firm commitment to the SI system, as being the internationally agreed preferred system of units. A reasonable selection of common quantities and units is included in the review version for demonstration purposes. The intent is to expand on this to include all the common quantities mentioned in Appendix B.8 and B.9 of the NIST SI document: http://physics.nist.gov/cuu/pdf/sp811.pdf The library also defines a selection of physical constants again intended as a flavour of the constants that would be included in a full library implementation as outlined in: http://physics.nist.gov/cuu/pdf/chart1.pdf Review questions: Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - 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? -Fred Bertsch

1 0

[Boost Review] Property Tree Library accepted
by Thorsten Ottosen 20 May '06

20 May '06

Dear All, I have the great pleasure to announce that Marcin Kalicinski's Property Tree Library have been accepted into Boost (www.boost.org) The votes were as follows: - yes: 11 - no: 3 Congratulations to Marcin! I would like to thank the following people for doing a review: Sebastian Redl Matt Doyle Pavel Vozenilek Ivan Vecerina Gennadie Rozenal Tom Brinkman Darren Cook Alexander Belyakov John Maddock Daniel Wesslén Jose Paul A Bristow Jeff Hardy. Matias Capeletto I apologize if I have overlooked anybody. Also thanks to the *countless* people who participated in the dicsussion during the review: none mentioned, none forgotten (as we say in Denmark). Below follows more comments on the issues raised in the review. best regards Thorsten Ottosen, review manager Detailed review comments ------------------------ The general feedback was positive, with one reviewer even said he would use the library even if it was not accepted into Boost. Experienced boosters saw the general quality of the submission as higher than average. There was also some strong concerns by a few long-time boost members, most notably because of a potential overlap with Boost.Program Options. I think in the end it was fairly clear that the two libraries take different approaches to the problem. Even so, the property-tree library should clearly state the limitations of its program option parser component and via its documentation refer to Boost.Program Options for a more scallable solution. There were quite a big number of people that thought the library could and should be further polished / enhanced. There is nothing new to this, and I hope Marcin will work hard to incorporate/try out as many of the ideas from the review. (There have been quite a few libraries which went through substantial changes after the review and before the post-review.) When Marcin feels his design/functionality is rock-solid, he should do a post-review on the developer list to clear up remaining matters. Here's a list of ideas that should be considered for the post-review: 1. documentation needs smaller topics, more examples and syntax highlighting 2. implementation: it could be a possibility to use Boost.Multi Index to give a space-optimal implementation. We should not underestime the tasks the library vould be used for, so space/performce does matter. The idea of flattening queries with wildcard syntax "prop.foo.*" might be something to look into 3. support for non-standard strings was seen as a must 4. the issue of preserving white-spaces and comments was important to some people, which is understandable if the library is used to read and write config files 5. serialization support would be nice 6. there should be clear statements on the limitations of the supplied parsers 7. many would like to see the incorporation of a path concept 8. many were intersted in even more syntactic sugar to make the library even easier to use, eg. by using (),[] etc cleverly. Thanks again to Marcin for his submission. -Thorsten

1 0