- Boost-announce - lists.preview.boost.org

[boost] [Review] Quantitative units review results
by John Phillips 11 Apr '07

11 Apr '07

I’m happy to report that the quantitative units library developed by Matthias Schabel and Steven Watanabe has been accepted for inclusion in boost. My thanks to the authors for their submission, and to the reviewers for all the work put into the reviews and discussions. A very busy review period saw contributions ranging from small commentaries to extensive reviews and discussions from Shaun Bloom, Martin Bonner, Paul Bristow, Malte Clasen, Phil Endecott, Michael Fawcett, Ben FrantzDale, Dave Hicherson, Lewis Hyatt, Janek Kozicki, Zach Laine, Eric Lemings, Kevin Lynch, John Maddock, Michael Marcin, Scott McMurray, Noah Roberts, Martin Schulz, Andrey Semashev, Dave Steffen, Matthias Troyer, K. R. Walker, David Walthall, Gunter Winkler and Deane Yang. Thanks to you again, since without your work the library would not become nearly as good as it can be. Given the scale of the review and the large number of issues discussed, this summary will be rather long. As has been my policy in the past, I will try to encapsulate the main ideas in the discussions for ease of later reference. In the case of this library, there are also some specific recommendations that should be addressed before the library is added to the CVS. Some of them were fixed by the authors during the review, and made available at that time, but for completeness the completed issues will also be included in the report. I’ll organize the report with some general discussion issues first, followed by suggestions for improvement for the library (required issues will be clearly marked and listed first), and since there was a vocal minority who argued against inclusion, the report will end by specifically addressing some of the points they raised in the review discussion. DISCUSSION Whether boost should include unit analysis as a compile time library or a runtime library is an almost religious issue. On each side are adherents who are strongly committed to their views and who see no way their needs can be met by the other type of library. However, the goal of boost is not to decide who is correct in situations of this sort. Boost was founded to generate good ideas and good implementations so use by a wide audience could determine which if any of these ideas are appropriate for addition to the language. Therefore, my suggested resolution to the compile time vs. runtime issue is for a runtime adherent to submit a runtime units library that is of sufficient quality for boost inclusion and let the broader base of programmers decide if there is a need for one or both libraries. Since the compile time library is already completed and accepted, it is reasonable to expect that any runtime submission should either be able to cleanly interoperate with the compile time version or a convincing rationale will be supplied for why this is not a reasonable goal. I look forward to this submission, though I will probably not volunteer to run the review since I claim no expertise in the issues that runtime proponents feel make a compile time solution inadequate. For the moment, I believe there is certainly enough of an audience that is looking for a compile time solution to justify the need for a library. I could only find two reviewers who said that a proper solution couldn’t be formulated with compile time facilities. The implication is that the rest of the people who expressed opinions about the library did not consider this an obstacle. In a list of library builders (as the boost developer list is) I would expect a bias toward compile time solutions compared to runtime solutions, but not enough of a bias to make me believe there is not an audience for a compile time solution. I also think that some of the problems perceived by those who opposed the library are more communications problems than problems with library functionality. To try to alleviate this issue, I am insisting that the documentation adds a rationale section. This section is suggested for all boost libraries, but is badly needed in a setting where there are many subtle mistakes of thinking or design that can be made. The authors showed during the discussions that they have good reasons for their choices, but some of those reasons are not obvious. A rationale section that is clear and complete on the topics of what the library is intended to do, why that is a good idea and how that can be done in C++ will go a long way to avoid further misunderstandings. The library uses the type system to make code more readable and more dependable. However, many commonly used third party libraries are not built in a way that is compatible with this use of the type system. Thus, some sort of proxy or façade system will be used in most cases to provide an interface with third party facilities. My personal preference is to put the special interface on the unsafe libraries, but either way, this would be a good choice for a simple example. It also gives a chance to explain that this is not a flaw in the design of the units library, but instead an issue with how to communicate between sections of a program that have incompatible type information. If, in the future the third party libraries are improved to allow direct communication, the façade can become a pass through or be removed. Imperial units (My apologies to Martin for the use of the term.) open a can of worms, but a nearly unavoidable one. They should either be included, or a prominent explanation of why they are not included should be provided. During the review questions arose of what to do with units such as meter * furlong / foot. The decision that the default behavior is to not convert and simplify is IMHO the correct one. In my academic area of expertise, the units km / (s * Mpc) (kilometers per second per megaparsec) are an example of a commonly used unit where automatic simplification is not acceptable. Megaparsecs measure distance, but should not be used to simplify with the kilometers. (These units are used to measure the expansion rate of the universe.) Paul made the case in his review, and I think he is correct, that the documentation should be very friendly to non-expert C++ programmers. Many potential users will not be experts in the template system or even the type system, but will be looking for a way to write more usable code for manipulating numbers in calculations. The documents should be written and organized to aid this. My suggestions are that you simplify the quick start’s discussion of how the library does its job, and focus on just presenting two problems (the work calculation and the circuit calculation) and how the units library makes solving those problems easier and more intuitive. Do it as two problems, each with a reason to exist, instead of as one mashed together program. Also, the listings for each example on the examples page should include a short (a few words to a couple of sentences) description of the problem the example illustrates and solves. Remember that someone who doesn’t already know the value of including units in code (and that means almost everyone) will look at the introduction, the quick start and the examples. If they aren’t convinced of the utility of the library by then, they’ll stop looking. This isn’t a binding suggestion, but right now static_rational is an implementation detail. As such, I think it should be kept internal to the library. If it is useful and important enough to move out to its own library, then pretty it up and submit it for the review process. This closely follows the pattern established by such useful tools as fusion. It took some thinking, but I believe the decision not to add operator++() is a good one. It might be good to include the reasoning and something like the example that ended that discussion (from Eric, I think) in the rationale section. REQUIRED IMPROVEMENTS Each of the improvements below should be addressed before adding the library to the CVS. Add a rationale section to the documentation. Since the design decisions required for a good units library aren’t always obvious, you need to include a section that explains the choices and your reasons for making the design decisions you made. Many things listed below have a place in this section. Fix the bugs in conversion/construction. You already addressed this, but make sure each way to construct a quantity that should work, does work. Include an explanation of why the ones that shouldn’t work don’t. Either include a real performance test, or no performance test. As the discussion during the reviewed, performance testing is not trivial, and when done without careful thought creates confusion. If you can develop a good performance test, include it in the examples or as a separate program in the documentation. However, example 14 isn’t a good performance test and confuses people about what is happening in the library. Check the suggestion about auto generation of ordinal values. If auto generation works across translation units, use it instead of assigning values. If auto generation does not work, consider the reserved range ordinals. This has to be addressed before submission because any later decision to change the range of reserved ordinals is a potentially breaking change for users (and probably a very hard one to debug). Remember that it is better to reserve 3 times too many ordinals than even 1 too few. Look at the problems of reworking the library for mpl re-use and simplifying the conversion implementation. If these projects are of a reasonable scale to be completed without slowing you down so much that you miss a release, do them now. Otherwise, implement them after including the library in the CVS. Remove the mutating member function x.value(). You have already agreed that this is a good choice and that needed mutating functionality should use a more ugly and obvious syntax, such as x.quantity_cast(). You have designed a way to simplify reverse conversions so someone who adds a new unit system doesn’t have to add redundant conversion definitions. Include this in the library and documentation. Include a rationale item that explains why the default behavior is explicit conversions. Correct the typos Paul noticed on the work “calculation” in the quick start. Provide a clear and complete listing of the systems and units included in the library. The use nautical::miles is not consistent with other names. Decide what naming scheme you want and stick with it. Include a rationale item that explains the reason for the notation quantity<SI::length> m_value=3.0 * SI::meter. I think you have a good reason, but it isn’t explained to the user. SUGGESTED IMPORVEMENTS The improvements below are not required, but they are suggestions for how to make a good submission better. Consider them, and do what you think will make the best library. Consider a check for compilers that are known to not be able to compile the library. Carefully consider the purpose for each example provided. What do you expect a reader to learn from each example? What examples are needed for users who want to write code for the common use cases for a library of this sort? Add an item to the rationale to quickly explain why rounding and error issues are not handled in the library. Consider changing the notation for negative exponents away from using parenthesis. Zach Laine had a collection of suggested edits to the text. Consider how to best fix them. One thing that will greatly aid broad adoption is ease of definition for new units and systems. There are tons of unit systems in the world, and someone is using each of them. As such, the easier you can make adding new units and systems, the better. This includes a possible tutorial showing the process (including discussions of the decisions that must be made and good ways to make them). It will greatly benefit the authors if anyone who tries this tells them about what went well and poorly. Provide clear and detailed examples of implicit and explicit conversions. Include a discussion of the good and bad points of each. Consider convenience headers for a variety of typical use cases. Consider whether you should change the current header arrangement to make them more or less fine grained. Consider including a simple currency example, with rates checked at run time from some simple source. Consider an example of using the library to interface with a GUI (similar to Janek’s). Consider including an example of how to accept a value in units not known at compile time and convert to a predetermined unit. You decided the if() check on line 57 of quantity.hpp is not needed. Check for other unneeded code and remove. Include the SI prefixes (milli, mega, …) in the SI catchall header. Since you can’t assume the memory layout of quantities in arrays is the same as doubles in all cases, consider an optional compile time check on sizeof() to make sure the size is the same. Consider adding the example from the discussion of a dual reference frame system. This is a good use of this library that won’t occur to many users without help. Consider opening the constants for use in systems that don’t provide native typeof(). This might be unimportant, if such systems can’t use the library for other compatibility reasons. Documentation is the gift that keeps on giving. Continue to look for ways to make the documentation more clear and complete. ISSUES RAISED WITH THE LIBRARY During the discussion, several issues were raised that have reasonable answers. I’ll try to collect my understanding of the issues and the answers here. It does not allow interaction with a GUI layer. Janek’s example posted to the discussion shows direct interaction including the ability to select units at runtime from the GUI. Similar can be done for other presentation layer issues except for possible rounding issues, which are inherently hard to solve satisfactorily. The focus should be on the business and presentation layers. While both layers are important, there is a substantial audience for this library that does little to no work with them. If this library proves insufficient for this work, a runtime submission is encouraged. Rational exponents are a needless complication and make integration with a runtime system impossible. While not everyone has a use for them, there is a noteworthy population that needs to have them, so they are provided. Similar functionality can be provided at runtime using boost::rational. Inadequate serialization tools are provided. I/O with units is a large and complicated problem all its own. Anyone who wishes to solve it is welcome to develop a library proposal, but the scope of this proposal is intentionally limited in this regard. Workarounds are needed for third party libraries, such as BLAS. This is true, but a common symptom of any unit system for C++. The only question is then where the workarounds happen. See above for more on this. Doesn’t support … (pick your favorite) So far, Janek has provided code examples for GUI use and Michael tells us he has used it with OpenGL and other systems. In fact, reasonable solutions have been provided for every problem presented, so far. There may be problems of this sort, but no direct evidence has been seen so far. No check for matching units on deserialized quantities. This is true to an extent, but not as important as it sounds. The serialization library provides support for version numbers on archives. The version number can be propagated between groups along with a definition of the required data format for that version. Yes, it is possible for someone to ignore this information, but it is also possible for them to call their units meters but use numbers that go along with feet. No unit system can eliminate such intentional circumventions, so it isn’t very important that this one doesn’t. Some real world uses of units have improper dimensions. For example measuring pressures in terms of inches of mercury. This will probably best be handled at I/O time, and converted to some more sensible internal unit for the rest of the program. In cases where this is not a viable answer, I don’t currently have one. Why distinguish between torque and energy, since the have the same dimensions? There are sensible physical problems where torque and energy both appear, such as rotational energy problems with work. As such, insulating against accidents is good. That’s the whole thing. Thanks to anyone who lasted this long, and thanks once again to the authors. John Phillips _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0

Intrusive library review results: library accepted
by "JOAQUIN LOPEZ MU?Z" 02 Apr '07

02 Apr '07

I'm pleased to announce that Ion Gaztañaga's Intrusive library has been accepted into Boost. Prior to its inclusion in Boost, the author is encouraged to address several issues raised during the review, a summary of which is given below. A total of 14 full reviews were received, all of them positive. Additionally, other members did not submit full reviews but expressed their support for the library. One Boost member raised some concerns about the usefulness of the library; I hope these concerns have been satisfactorily addressed by those review participants who explained their current and potential usage scenarios for Boost.Intrusive. This has shown that more movitational material need to be provided in the documentation introduction and in the form of full-fledged examples. Thank you to Ion Gaztañaga for all the hard work involved in creating a Boost library, to Olaf Krzikalla, who wrote the first versions of this piece of work, and to all the participants in the review. The list of issues to be addressed follows. Feel free to comment if you detect some error or omission from my part. List of issues to be addressed prior to inclusion of the Intrusive library into Boost: * Documentation - Provide a motivating introduction about usefulness of Boost.Intrusive. - Add some hello world motivating examples. - Class names linked to their section in the reference (except in code due to Quickbook limitations). - Document iterator and const_iterator as part of the container interfaces. - Add overview of iterator validity rules. - Document usage before concepts. - Improve concepts part. - Provide container concepts à la STL. - Add performance section. - Add quick guide to docs. - Make the tests more comprehensive. - Add examples section. - State clearly the purpose of the lib in the introduction. - Add more examples using the different hooks. - State in docs the possibility that tags be incomplete types. - State in docs the fact that Boost.Intrusive does not support shared_ptr's. - Document the fact that member hooks rely on non-standard implementation techniques. * Naming - Change Destroyer to a more suitable name (e.g. Sink or Disposer), rename member functions accordingly. - Rename current() as iterator_to(). - Rename [s]list_algorithms as circular_[s]list_algorithms. - Drop the 'i' prefix from the names of containers. - Rename linked() as is_linked(). - Rename assign_and_destroy() as destroy_and_assign(). * Interface improvements - Study ways to simplify the usage syntax of hooks. - Add a default value to Tag. - Member hooks shouldn't be parameterized on the host class type. - Make hooks assignment operator a no-op. - bucket_size() y bucket() should be const. - Provide cbegin(), cend() etc. - Add *_fwd.hpp headers. - Fuse autolink and regular/safe hooks into one class whose second parameter is a category class. * Implementation improvements - Iterators to be implemented with iterator_facade. - Use Boost.Concept for concept checking if compilation times are not severely affected. - Extend bucket primes table to 64 bits. - Use template trick to avoid direct use std::size_t in template parms of containers, thus pulling the std namespace in via ADL. - Use Watanabe's version of swap_nodes() for ilist. - Use insert_after() in clone_from(). - Reimplement clone_from() to not delete partially constructed data on exception. - Investigate bug with member hooks and virtual inheritance. * Extensions and issues to be considered in the future - Order-statistics tree. - Study other libraries for ideas: DOL, PTL, jjLib. - Study feasibility of implementing a "destroy multihooked element when completely unlinked" mode. - Investigate use of two-way pointers with Boost.Intrusive. - Consider a shift() member function for lists and slists. - Additional slist-like container with a pointer-to-last member to make swapping constant time. The Review Manager, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[boost] [Review] Quantitative Units library review begins today, March 26
by John Phillips 26 Mar '07

26 Mar '07

The review for the Quantitative Units library, submitted by Matthias Schabel and Steven Watanabe begins today, March 26 and ends April 4. From the documentation: The Boost.Units library is a C++ implementation of zero runtime overhead compile-time dimensional analysis in a general and extensible manner, treating it as a generic metaprogramming problem. Support for units and quantities (defined as a unit and associated value) for arbitrary unit system models and arbitrary value types is provided, as is a general facility for unit conversions enabling fine-grained control over conversion. Complete SI and CGS unit system models are provided, along with systems for angles measured in degrees, gradians, and radians. A small subset of the SI system including only length, mass, and time is developed in the examples as a demonstration of the relative ease of adding new unit systems and the extensibility of the library architecture. In this review, the authors and I expect that there will be active discussions on two topics. In every review there is a discussion of the quality of the library implementation and documentation, and it is obviously expected and desired here. Also, since this library is specifically designed as a compile time library with no attempt to provide unit conversions or other runtime facilities it is expected that the review will include an active thread on whether this is the correct design decision. In specific, this is a different approach than that taken by Andy Little's submission of last year. Because some people will be more interested in one or another of these two discussions, I request that everyone clearly marks comment topics to show which they are discussing. This will also improve Matthias' and Steven's ability to respond usefully and my ability to produce review results and recommendations that accurately reflect the desires of the boost community. In general, please include the following in your review. Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. 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 in this review. John Phillips Review Manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0

Review Schedule
by Tom Brinkman 17 Mar '07

17 Mar '07

Review Schedule http://www.boost.org/more/formal_review_schedule.html . If you have any changes, post them as a reply to this thread. We need experienced review managers for many of the libraries in the review queue. A few of them have been waiting for a volunteer for a few months now, such as boost::exception, boost::GloballyUniqueIdentifier and boost::scope_exit. If your interested, let us know. Preferably, you will have a background in the problem domain, but no association with the library and are a regular contributer on the boost mailing list. You can read the "review manager" requirements at the following link: http://www.boost.org/more/formal_review_process.htm Most of the libraries are located at the Boost Sandbox Vault, located here: http://boost-consulting.com/vault/ Here is a summary of the libraries that are in the queue waiting for a "review manager" volunteer. ------------------------------------- Library: Exception Author: Emil Dotchevski Location: http://www.revergestudios.com/boost-exception/boost-exception.zip Review Manager: Needed Date: Needed Summary: The purpose of Boost Exception is to free designers of exception classes from having to consider what data needs to be stored in exception objects in order for the catch site to be able to make sense of what went wrong. When Boost Exception is used, arbitrary values can be stored in any exception. This can be done directly in the throw-expression, or at a later time as the exception object propagates up the call stack. The ability to add data to any exception object after it has been thrown is important, because often some of the information needed to handle an exception is unavailable at the time of the throw. ----------------------------------------- Library: Globally Unique Identifier Author: Andy Tompkins Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: A guid, or globally unique identifier, is an identifier standard used in many disciplines including computer networks, distributed computing, and databases. They can be used to tag objects with very short lifetimes, to reliably identify very persistent objects across a network. An attractive feature of guids is their relative small size, of 128-bits, compared to alternatives. Also the creation of guids does not require a centralized authority. ----------------------------------------- Library: Scope Exit Author: Alexander Nasonov Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: The scope-exit-arg-pp-seq is Boot.Preprocessor sequence of identifiers that can be used inside scope-exit-body. The direct-declarator is declarator-id followed by optional argument of type boost::scope_exit_group (inside brackets or after the equal sign). This construct executes scope-exit-body at the close of the current scope. ----------------------------------- Library: Floating Point Utilities Author: Johan Råde Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: Proposed Additions to the Boost Math Library <boost/math/fpclassify.hpp> Functions for floating point number classification: fpclassify, isfinite, isinf, isnan, isnormal. Follows TR1. <boost/math/signbit.hpp> Functions for floating point number sign bit access and modification: signbit, copysign, changesign. Follows TR1. <boost/math/nonfinite_num_facets.hpp> Facets that parse and format infinity and NaN according to the C99 standard. Used for portable handling of infinity and NaN in text streams. ----------------------------------- Library: Switch Author: Steven Watanabe Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: Needed

1 0

Review of Intrusive library begins today March 12
by Joaquín Mª López Muñoz 12 Mar '07

12 Mar '07

The review of Ion Gaztañagas's Intrusive library begins today, March 12, and extends up to March 21. * Download: Boost vault: http://boost-consulting.com/vault/ Folder: Containers File: intrusive.2007-03-04.zip * Online docs: http://ice.prohosting.com/newfunk/boost/libs/intrusive * Description: Intrusive is a library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in C++ due to the presence of the standard containers, which don't support intrusive techniques. Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can easily use Intrusive. Like their STL-counterparts, intrusive containers use template parameters to control the stored data types and some special aspects of intrusive containers. * Compilers tested (so far): Visual 7.1/WinXP Visual 8.0/WinXP GCC 4.1.1/MinGW Intel 9.1/WinXP GCC 4.1.2/Linux * Review questions: 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. I invite you to submit your review, either publicly to the developers or the users lists, or else, if for whatever reason you don't want to publicize it, directly to me. Thank you for investing some of your time on reviewing Ion Gaztañaga's Intrusive library. The Review Manager, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[boost] Review of Intrusive library begins today March 12
by Joaquín Mª López Muñoz 12 Mar '07

12 Mar '07

The review of Ion Gaztañagas's Intrusive library begins today, March 12, and extends up to March 21. * Download: Boost vault: http://boost-consulting.com/vault/ Folder: Containers File: intrusive.2007-03-04.zip * Online docs: http://ice.prohosting.com/newfunk/boost/libs/intrusive * Description: Intrusive is a library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in C++ due to the presence of the standard containers, which don't support intrusive techniques. Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can easily use Intrusive. Like their STL-counterparts, intrusive containers use template parameters to control the stored data types and some special aspects of intrusive containers. * Compilers tested (so far): Visual 7.1/WinXP Visual 8.0/WinXP GCC 4.1.1/MinGW Intel 9.1/WinXP GCC 4.1.2/Linux * Review questions: 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. I invite you to submit your review, either publicly to the developers or the users lists, or else, if for whatever reason you don't want to publicize it, directly to me. Thank you for investing some of your time on reviewing Ion Gaztañaga's Intrusive library. The Review Manager, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[review][bimap] Bimap accepted
by Ion Gaztañaga 03 Mar '07

03 Mar '07

Hi to all, The Bimap library submitted by Matias Capeletto has been accepted into Boost. Thanks to all reviewers and all who contributed to the library in the informal review. Thanks also to Matias for his submission and Joaquin for his mentoring effort on this Google SoC project. We've received 6 reviews (Alisdair, Fernando, Jeff, John, Thorsten and Tony), all of which were positive. If I weren't the review manager, I would also make a positive review of this library, so I'm pretty happy with the results. Now I have a bit of work reviewing all the comments, suggestions and Matias' replies to write an small summary of requested changes and conclusions. The "relation" view, and some basic names ("first"/"second" vs. "left"/"right") were the most active topics. But everyone has considered Bimap useful, well-written, and well documented. I'll post the summary following week. Regards, Ion

1 0

[Ann] Boost and Google Summer of Code 2007
by John Maddock 02 Mar '07

02 Mar '07

Dear Boosters, It is a pleasure to announce that Boost will be applying as a mentoring organization for the upcoming Google Summer of Code 2007. There is a lot of preparation work to be done and little time to do it. A page has been set up at the Boost Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… which will hold a list of preliminary ideas for students to take up and use in their own applications to GSoC07. Please feel free to contribute by directly editing the Wiki page. Any questions, requests for feedback etc. can be conducted through the Boost lists. Remember that this initiative, as Boost itself, is the result of many individuals' contribution and ideas, which means we are looking forward to *your* feedback. Sincerely, John Maddock

1 0

[Review][Bimap] Bimap review extended until March 2nd
by Ion Gaztañaga 22 Feb '07

22 Feb '07

Hi to all, Bimap review has been extended until March 2nd. I encourage all boosters to give a try to this great library. The links are: Start reading the documentation here: http://tinyurl.com/y95qng And download the library here: http://boost-consulting.com/vault/index.php?&directory=Containers Regards, Ion

1 0

[boost] [Review results] Accumulators accepted
by John Phillips 19 Feb '07

19 Feb '07

The accumulator library submitted by Eric Niebler has been accepted into boost. Thanks, once again to all of the people who contributed to the development of the library, to everyone who contributed to the review, and to Eric for a fine submission. During the review, Eric and some of the reviewers had a useful discussion about issues for the library, and possible improvements. A condensed version of the outcomes from that discussion is included below. Also, in perusing the archives for other comments about the library, I found a couple of other issues that were discussed. I have included them below, as well. In many cases, Eric acknowledged issues and committed to a fix during the review. Those issues are included below, along with the current state of some of the more open ended discussions to provide easy reference for all interested parties. For my own organizational convenience, I have numbered the entries below. This does not indicate relative importance. 1) Prior to the review it was asked why the function that returns a histogram is called the density. Little was done at the time, as Eric suggested it should be addressed during the review. As far as I can see, it was not brought back up during the review process. This should be examined to make sure that density is the best name for the function, and changed if needed. 2) There are a number of variant implementations of some statistical functions. The documentation should clearly indicate which variants focus on quick and dirty implementations, and which provide more numeric stability. Eric has stated that this will be addressed in the revisions of the documentation. 3) The question was asked whether or not it is feasible to provide outlier rejection for some or all of the accumulators. I can find no further discussion of this question in the review, however, since this is a very important statistical technique it would be a good feature to investigate for future addition. 4) Michael Stevens expressed interest in a form of the variance that accumulates the differences squared iteratively and divides the result by n. I saw no direct response, but this is basically what the immediate_variance does. 5) Interest was expressed in making the compensated sum the default version of the sum. It could be supplimented by the quick and dirty version as an alternative. However, since there are reports that many optimizing compilers turn the compensated sum algorithm into the same compiled code as the simple sum, tests should be done to see if there is any real gain before the modification. 6) There are a number of broken links in the quickbook docs. This has been acknowledged and is in line for a fix. 7) Steven Watanabe suggested changing the structure to move away from the fusion vector dependence. After discussion it appears that fusion cons,. may be a better choice. However there may be a use case for the original library that precipitated the choice of fusion vector. This should be checked, and if Steven's idea holds up under scrutiny, it should be implemented. 8) There is a request that the user guide specifies which header each component is in. This has been acknowledged and is in line for a fix. 9) The macro BOOST_PARAMETER_NESTED_KEYWORD has no description in the docs. This has been acknowledged and is in line for a fix. 10) There were a number of requests for improvements to the reference manual, ranging from wording changes to a reorganization that reflects class structure instead of header structure. In some cases, these improvements are direct, and they are in line for fixes. In other cases there is currently no known way to do it with the boost tool chain. Eric, and many of the other members of boost would greatly appreciate anyone who has ideas and time to fix the harder problems. 11) There was a suggestion that the documentation could mention the TR1 reference_wrapper as a future solution to the accumulator_set_wrapper issues, and the implementation could be changed once there is a boost accepted implementation of the reference_wrapper. My impression was that I was not the only person who didn't realize that it could solve that problem. 12) Functions that allow a range of values to be pushed into an accumulator set all at once should be added. This could include forms that take begin and end iterators and forms that take a sequence. Eric agreed that this is a good idea. 13) Paul Bristow mentioned that the kurtosis has a confusing naming history. What the docs refer to as the kurtosis would better be called the "kurtosis excess." His suggestion was that a name change be considered and that the docs be modified to acknowledge the confusion whether the name is changed or not. Eric agreed with this suggestion. 14) Accessors for the standard deviation, the unbiased variance and the unbiased (N-1) standard deviation were requested. The fact that John Maddock fell into the trap of miscalculating the standard deviation shows that even experts can make mistakes when converting from the variance. Thus, it is a good idea for inclusion. Eric said he is interested, and he would also welcome submissions that provide these functions. 15) The docs mention "Even the extractors can accept named parameters. In a bit, we'll see a situation where that is useful," but there is no later mention. Eric has an example he intended that to refer to, but forgot to include it in the last edition of the docs. He intends to fix that. 16) The ability to "reset" and accumulator was requested. Eric pointed out that it is quite possible to make accumulators with reset methods. He also pointed out that it might be desirable to reset accumulator_sets, but this could also pose a problem. It is not clear what should happen if one of the accumulators used by an accumulator set does not have a reset method. Further thought should be given to this for possible inclusion in a later revision. 17) Autocorrelation for accumulator_sets should be explored. Matthias already plans to do this in the coming year for possible inclusion in a later revision. 18) The documentation on what to expect when one accumulator is dropped while a second accumulator that depends on the first is not dropped should be clarified. Careful thought on this may lead to a change in current behavior. 19) There is a request that the docs state more clearly what happens when more than one accumulator maps to the same feature. Eric plans to include this in documentation revisions. 20) It is not currently possible to combine accumulators. In some very common use cases, this would be an important feature. However, not all accumulators can be combined in any sensible way. A solution to this will require some study and design work, but it is a valuable addition for a future revision. One possible solution is to have a compile time check to see if the accumulators are combinable. 21) While finding newer/faster/more robust algorithms is not a bad thing, the focus of this review has been the interfaces. If the interfaces are good, improved algorithms can be worked in later. There is some minimum standard for performance, but it is not the focal point or the submission. 22) Javier and Hans submitted lists of documentation corrections that Eric acknowledged and plans to fix. 23) It is agreed that there is a need for a more gentle and thorough getting started document. This should include some compelling examples that show why this is a good design decision. 24) More of the formulas should be available in the documentation. Eric requested volunteers to make some formulas into LaTeX, and I have already contacted him to do so. 25) The docs for how to incorporate new features should be improved. This can be helped tremendously if the people who had problems doing this would send Eric descriptions of where they had problems with the docs and the process. Thanks again to everyone for your time and work. Any problems or misrepresentations in the above list are purely my fault, and I apologize for them. John _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0