- Boost - lists.boost.org

Re:Re: [boost] Re: 1.32 release preparation
by Robert Ramey 06 Jul '04

06 Jul '04

Message: 16 Date: Sun, 27 Jun 2004 22:25:47 -0500 From: "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> Subject: Re: [boost] Re: 1.32 release preparation To: boost(a)lists.boost.org Message-ID: <40DF8FBB.4040408(a)aaronwl.com> Content-Type: text/plain; charset=us-ascii Aaron W. LaFramboise wrote: >Robert Ramey wrote: >> Dave Abrahams wrote: >> >> >>>I'd like to know the reasons for "all the sudden rush". We did >>>announce a schedule long ago, and it has already been delayed by three >>>weeks. I'm not asking in order to point fingers; I just want to know >>>how to avoid the "sudden rush" next time. >> >> >> Here is the current scenario. >> >> a) The announcement gets posted - release 1.32 scheduled for date x. >> b) Each developer decides - uh oh I better get in my changes before date x. >> c) Of course these changes take longer >> d) and break some other things >> e) which takes longer still >> >> Personally I think the concept of scheduling a release fundamentally flawed. >> I would suggest another idea. >As an observer, I'm fairly impressed with GCC's release methodology. >http://gcc.gnu.org/develop.html >A critical component is a schedule that includes several stages during >which certain sorts of changes are unacceptable. >There's still rush, but most of the rush for major features or other >destabilizing elements happens long before the release comes around. I found this to be very interesting. I had never seen this before. It basically implements my view that the "Main Line" should be code that is always works and is ready to be used, tested and potentially released. As far as I'm concerned it's totally consistent with my proposal which I thought was un-orthodox but now see that is used at least by GCC. So, my view would be - stick to the original 28 June date, require that new libraries be added to branches and merge to main as appropriate. I realize its not THAT easy - but it would address the concerns that I have about the whole process and allow all libraries to proceed on independent schedules. New libraries would be tested against the "known good tree" independently of one another. Take as a small example changes in MPL. The current method is to check in a new version of MPL and see what happens. Presumable some issues will arise and now we have a broken system which inhibits development of other libraries until the issues are resolved. Under the proposed method, the new MPL would be check in under its own branch and issues would be detected on all libraries before they affect other developers. Anyway - my 2 cents. Robert Ramey

8 16

boot::mpl::list problem
by zaufi 06 Jul '04

06 Jul '04

Hi all! I have a problem compiling the following simple program without defining BOOST_MPL_NO_PREPROCESSED_HEADERS. Though obviously there are preprocessed headers in boost/mpl/list/aux_/preprocessed/plain. The problem seems to be in compiler-specific preprocessed header (for example boost/mpl/aux_/preprocessed/gcc/list.hpp) where list is defined with 10 arguments regardless of BOOST_MPL_LIMIT_LIST_SIZE value. ---{boost_list.cc} --------------------------------------------- // # define BOOST_MPL_NO_PREPROCESSED_HEADERS # if !defined(BOOST_MPL_LIMIT_LIST_SIZE) || (BOOST_MPL_LIMIT_LIST_SIZE < 20) # undef BOOST_MPL_LIMIT_LIST_SIZE # define BOOST_MPL_LIMIT_LIST_SIZE 20 # endif #include <boost/mpl/list.hpp> typedef boost::mpl::list< int, int, int, int, int , int, int, int, int, int , int, int, int, int, int > my_list; int main() { my_list l; return 0; }; ---------------------------------------{end of boost_list.cc}--- any suggestions?? regards. zaufi.

2 1

Boost.Test, failed assert output
by Glen Knowles 06 Jul '04

06 Jul '04

This is my first time using Boost.Test. I was able to get started pretty quickly from the docs, and I'd like to start by saying that the library looks pretty good. Now for my request. ;) I'm using vc++ 7.1, and when an assert unexpectedly fails I'd like the framework to output a message that is recognizable by the IDE as an error. What I'm seeing right now is: ------ Build started: Project: CBdbRangeSummary_test, Configuration: Debug Win32 ------ Run unit tests Assertion failed: 0, file .\CBdbRangeSummary.cpp, line 33 Running 3 test cases... Exception in "single_rnode_test": This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Build Time 0:00 CBdbRangeSummary_test - 0 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 1 succeeded, 0 failed, 0 skipped Thanks, Glen Knowles Centor Software Corporation

1 0

Re: [ublas-dev] Re: Boost Mathematicians
by Jeremy Graham Siek 06 Jul '04

06 Jul '04

Hi Paul, I agree with you. The use of operator* does not imply commutativity. Cheers, Jeremy On Jul 5, 2004, at 6:04 PM, Paul C. Leopardi wrote: > Hi all, > Reply to a sub-issue below. > Best regards > > On Tuesday 06 July 2004 02:58, Peter Schmitteckert wrote: > > This imples, that the elements of a matrix need not be commutative, > > having again consequences for general routines using operator*(), > > since this oftemn implies the commutativity of elements. > > Can anyone explain to me why operator* implies the commutativity of > elements? > The GluCat library ( http://glucat.sf.net ) uses operator* and its > elements > do not necessarily commute under multiplication. > > How would you use expression templates to implement a non-commutative > group > concept, or more to the point, a ring or an algebra? My first thought > for > this was to use operator* as it seems most natural, and in the case of > Clifford algebras, gives subalgebras isomorphic to the quaternions, > complex > numbers and real numbers. > > Of course, this discussion comes from a mathematical viewpoint rather > than a > computer science viewpoint, but I don't see why these viewpoints need > be > incompatible. > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > <lrec_companion_043004.gif> > <l.gif> > > Yahoo! Groups Links > > • To visit your group on the web, go to: > http://groups.yahoo.com/group/ublas-dev/ > > • To unsubscribe from this group, send an email to: > ublas-dev-unsubscribe(a)yahoogroups.com > > • Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

1 0

Re: [boost] Random number library
by Kris Thielemans 06 Jul '04

06 Jul '04

Hi 3 more comments on the random number library. 1) Further on the topic started by Oliver Kullmann, and the reply by Cromwell Enage: -------Start Quote:--------- typedef boost::uniform_int<> UniformDist; UniformDist dist(min,max); typedef boost::mt19937 BaseRNG; BaseRNG rng; boost::variate_generator<BaseRNG&,UniformDist> your_generator(rng, dist); Note the ampersand; your program will fail silently if you omit it. -------End Quote:--------- An example why you could need the &: Suppose you have your_generator being defined locally, as it depends on some run-time parameters int f(int min, int max) { UniformDist dist(min,max); static BaseRNG rng; boost::variate_generator<BaseRNG&,UniformDist> your_generator(rng, dist); return your_generator(); } If you don't have the &, the variate_generator constructor will make a fresh copy of the rng object every time f() is called. Result: your random number will always be the same! On the other hand, using it without ampersand works fine for me in other situations. I find this rather subtle (i.e. it took me a few hours to understand why my data were not what they should have been). So, maybe the documentation for variate_generator should be more explicit about this. I've tried to write a doc for this, but find that it probably needs explicit examples. Here it is anyway "Whether you use a reference, pointer, or 'plain' type for the Engine template parameter of variate_generator<Engine, Distribution> depends on similar considerations as for ordinary functions. E.g. if a reference is used, subsequent calls of the variate_generator::operator() will modify the state of the referenced Engine object, which is probably useful if the same Engine object is used for multiple variate_generator<Engine, Distribution> objects. " -------------------------------------------------- 2) While on the topic of references, the following generates a compiler error. boost::uniform_01<BaseRNG &> random01(generator) /home/kris/mydoc/include/boost/random/uniform_01.hpp:58: error: forming reference to reference type `stir::base_generator_type&' -------------------------------------------------- 3) on distribution::operator()(Engine& eng) template<class Engine> normal_distribution::operator()(Engine& eng) assumes that Engine is like uniform_01. This not documented, and worse, also not checked in the code. template<class Engine> result_type operator()(Engine& eng) { if(!_valid) { _r1 = eng(); _r2 = eng(); _cached_rho = sqrt(-result_type(2) * log(result_type(1)-_r2)); _valid = true; } else { _valid = false; } // etc I would recommend to insert something like assert(eng.min()==result_type(0)); assert(eng.max()==result_type(1)); BOOST_STATIC_ASSERT(!std::numeric_limits<Engine::result_type>::is_intege r); Of course, when using variate_generator<Engine, normal_distribution<double> > the Engine is converted into a uniform_01 if necessary. I'm afraid that the same is true for the gamma_distribution and geometric_distribution class. So, maybe some_distribution::operator()(Engine& eng) should not be used at all. If so, it should not be public (at least for compilers that can do template friends I guess). However, it is required by the 'Random Distribution' concept. Any particular reason that we need it? Kris Thielemans Hammersmith Imanet Du Cane Road London W12 0NN UK http://www.HammersmithImanet.com/~kris

1 0

Attn: Eric Niebler - Xpressive
by Dan 05 Jul '04

05 Jul '04

I downloaded the xpressive files and had a look through the files. I'm interested. I'd like to put xpressive to work in a real parsing application (it's the early stages of development so I'm confident we will work through any issues well before release). I've been getting a vague idea of how things work through the tests, and I may find more in the source files, but what I really need is a quick explanation of the basics. If you haven't already, I'd seriously recommend writing a quick start guide and placing it with the project files. If you have some documentation, I'd love to get access to that but otherwise just a brief explanation of the basics will suffice for now. It is my hopes that xpressive will make development and maintenance of our application easier and that our use of the library will help shape xpressive's development in a positive fashion. -Dan

2 1

Administrative Requests
by David Abrahams 05 Jul '04

05 Jul '04

Just a reminder -- I'm not the only moderator. Please post all administrative requests to boost-owner(a)lists.boost.org so that the workload of responding to them is distributed across everyone who can handle them. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 2

Re: Boost Mathematicians
by Michael Stevens 05 Jul '04

05 Jul '04

On Saturday 03 July 2004 16:54,David Abrahams <dave(a)boost-consulting.com> > Jeremy and I have just completed a re-evaluation of uBlas based on > what's in uBlas' own CVS repository, having not discovered that until > recently (you should have that info on uBlas' Boost page!) We have > some major complaints with uBlas' design. The list is long, and the > issues run deep enough that we don't believe that uBlas is a suitable > foundation for the work we want to do. This is very interesting. Thanks for writing this up and posting. I can't address all the issues. However those which I can I will endeavor to give you and the Boost community my feedback on. First of all I am currently making sure Boost is updated with the latest uBLAS development version. This already has updated documentation which points to all the correct locations for discussions, CVS and Wiki. This should make it much easier for users to find the correct locations if the stable version in Boost does not meet their needs. To facilitate the development of solutions I will place many of the points into the uBLAS bug tracker on SF. > Interface Design > ---------------- > > * Not grounded in Generic Programming. The concept taxonomies, to the > extent they exist, are weak, and poorly/incorrectly documented. > Aspects of the design that should be generic are not (e.g. only > certain storage containers are supported, rather than supplying > storage concept requirements). No linear algebra concepts (vector > space, field, etc.) The library is so out-of-conformance with our > expectations for Generic Programming that this one item by itself > is probably enough to make it unsuitable for us. This is a big issue. I believe we need to split the documentation issues from the design issues. Documentation is high on the priority list of many uBLAS users and developers. Most new users start with a requirement for a C++ matrix and BLAS library with nice syntax, efficiency and documentation! The need for clearly defined and documented concepts comes for most people a little latter when extensibility becomes an issue. The storage concept is not as bad as it appears. The concept although not documented is sufficiently well defined that creating a new model is unproblematic. At present the concepts are documented by their models :-) > No linear algebra concepts (vector space, field, etc.) I not sure if these concepts really need to be defined. They are already well described in many mathematical text books and in Wikipedia. Almost all the major reference works on BLAS and Matrices simply state elements are either Real or Complex and are therefore implicitly a field. Of course a C++ linear algebra library should be generic enough to work with any type which is a numeric approximation to a field. > > * Redundant specification of element type in matrix/vector storage. Not sure what is meant here, can you elaborate ? > * size1 and size2 should be named num_rows and num_columns or > something memnonic > > * iterator1 and iterator2 should be named column_iterator and > row_iterator or something memnonic. I think many uBLAS users have come to appreciate the brevity of naming. I think the concensus in the Boost review was as long as they were used consistenty these names are acceptable. > * prod should be named operator*; this is a linear algebra library > after all. Oh, there has been much ink spent on this! Joerg argues against operator* for two reasons I think. a) operator* brings an expectation of commutativity and this is not the case in linear algebra b) The are many products (inner,outer,element) and there should be a clarity of naming. > * begin() and end() should never violate O(1) complexity expectations. > > * insert(i,x) and erase(i) names used inconsistently with standard library. Agreed. > * Matrix/Vector concept/class interfaces are way too "fat" and need to > be minimized (e.g. rbegin/rend *member* functions should be > eliminated). Interesting. Certainly the fatness is a worry. I think rbegin/rend need to stay as members as this is part of the Reversible Container concept. > * The slice interface is wrong; stride should come last and be > optional; 2nd argument should be end and not size; then a separate > range interface could be eliminated. For std::slice (valarray) compatibility stride should be last. Not sure why this was not picked up on a long time ago!! valarray (and uBLAS) use size (not end) for good reason however. I also think it would be a mistake to drop range. slices can be degenerate (zero stride) and this has a runtime cost which range does not need to share. > * No support for unorderd sparse formats -- it can't be made to fit > into the uBlas framework. Interesting. I guess this requires some thinking time for a sensible discussion. > Implementation > -------------- > > * Expressions that require temporaries are not supported by uBLAS > under release mode. They are supported under debug mode. For > example, the following program compiles under debug mode, but not > under release mode. > > std::cout << prod (prod(v, m), m) << std::endl; > } > > The workaround to make it compile under release mode is to > explicitly insert the creation of a temporary: > > std::cout << prod (vector<double>(prod(v, m)), m) << std::endl; > > There should be no such surprises when moving from debug to > release. Debug mode should use expression templates, too, as the > differences can cause other surprises. This was changed by Joerg after the last stable release to Boost. I will check there has been no regression. The fix propagates an expression complexity that is statically checked. This check explictly prevents the creation of nested products!! Therefore the correct code is now that with the explicit temporary or with one of the parameterized prod's. The change is aimed at the user. They must clearly express the evaluation and storage complexity of the expressions. The change of semantics between debug/release builds is unfortunate. The partial disabling of the expression templates in debug mode is currently the default and a config macro. With current compiler technology this prevents debuggers crashing and users scrolling through type names that are pages long. In a perfect environment the default would be the opposite. > * Should use iterator_adaptor. There is a ton of boilerplate iterator > code in the uBLAS that needs to be deleted. Agreed 100%. A well used iterator_adaptor would shorten uBLAS definitions to about 30% of their current size !! > * Should use enable_if instead of CRTP to implement operators. uBLAS > avoids the ambiguity problem by only using operator* for > vector-scalar, matrix-scalar ops, but that's only a partial > solution. Its expressions can't interact with objects from other > libraries (e.g. multi-array) because they require the intrusive CRTP > base class. Interesting solution. Agreed, the current implementation is closed to other objects because of the intrusive base class. Sadly uBLAS was designed before enable_if. Any pointers to compile/runtime effects of the enable_if solution? We would however lose the static type checking that argument matching with the CRTP base class gives us. At this point I think we land in a deep philosophical argument as to the strengths and weaknesses of generic progreamming %-) > * Certain operations, especially on sparse matrices and vectors, and > when dealing with matrix_row and matrix_column proxies have the > wrong complexity. Functions such as begin() and end() are suppose > to be constant time. I see calls to find1 and find2, which look like > expensive functions (they each contain a loop). Agreed. The implementation with findN is simple but expensive. I am not sure why Joerg choose this route. > Testing > ------- > * There should be a readme describing the organization of the tests. > > * Tests should not print stuff that must be manually inspected for > correctness. > > * Test programs should instead either complete successfully > (with exit code 0) or not (and print why it failed). Agreed. If anyone submits a patch it would be included very quickly! > * Abstraction penalty tests need to compare the library with tuned > fortran BLAS and ATLAS, not naive 'C' implementation. There was some very good work on this about a year ago. Sadly the results are no longer accessable on the web. Since the loss to Intel of the KAI compiler it is hard to see any library archiving really exceptional results in this regard. > Documentation > ------------- > > * In really bad shape. Redundant boilerplate tables make the head > spin rather than providing useful information. > > * Needs to be user-centered, not implementation centered. > > * Need a good set of tutorials. Agreed. > Compilers > --------- > > * Simple example doesn't compile with gcc 3.3. Got it to compile by > #if'ing out operator value_type() in vector_expression.hpp. Strange gcc-3.3.3 is my primary compiler. Can you specify the problem more exactly. Which gcc-3.3 subversion is causing the problem? Thanks, Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

3 4

Re: Boost Mathematicians
by Michael Stevens 05 Jul '04

05 Jul '04

Oppps I forgot the last section of David's posting. On Saturday 03 July 2004 16:54,David Abrahams <dave(a)boost-consulting.com> > > Other then the many forms of blocking (other then banded) uBLAS supports all > > these in its design. > I believe that a design with really good support for blocking can't be > easily grafted onto an existing design that doesn't have it. Now I understand. Blocking in the context of evaluation rather then sparsity/ shape. Yes this is a good point. Blocking evaluation requires significant contribution from the Expression Template mechanism that is not present in uBLAS. > > Other then the lack of ET in the current MTL the big difference > > between the two libraries is the definition of iterators. Neither > > design seems to be perfect with regard to efficiency. > > No, and I have some ideas for addressing that. A improved iterator concept that allows succinct coding and runtime efficiency would be a big step forward. > > > Since uBLAS is already in Boost and has a well established and clean user > > syntax it would seem strange to ignore it. > > Yeah, I stopped ignoring it long enough to determine for sure that we > should probably ignore it :(. No sure what to say here! > > > For the perspective of building further Linear Algebra algorithms it > > would not be too hard to use the syntax sufficiently portably so > > that a future MTL with expression templates could not be used > > interchangeably. > > We have some problems with the syntax too, as you can see from the > above. That said, if the design of MTL makes sparing use of members > and instead relies on free functions, you should be able to make > uBlas syntax adapters ;-) Can't fault the logic here :-) All the best, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 05 Jul '04

05 Jul '04

According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>Well, as you point out, try_lock is like a timed_lock with >>time = 0, and lock is like a timed_lock with time = infinity, >>so why not give timed_lock both lock() and try_lock() >>methods as shorthand notation for lock(m, t=0) and >>lock(m, t=infinity)? > > > [Batov, Vladimir] Because, in my view, it violates the fundamental (and > I think widely accepted) OO design principle (guideline?) that in simple > terms can be expressed as "one class, one responsibility". Names like > Bertrand Meyer, Herb Sutter and many others immediately come to mind. > > We can either achieve that by having a universal lock (with timed_lock > as the basis) and shorthand notations in separate derived classes (lock, > timed_lock and try_lock) or by keeping those three completely unrelated > (probably at the expense of some code/functionality duplication). I am > personally leaning towards latter, as even though technically all three > concepts are related, from the user point of view they are distinct. > > >>The argument for try_lock not having a blocking lock() method, >>which you seem to stress more often, is much clearer; I'm much >>more inclined to agree with you there. > > > [Batov, Vladimir] Thank you. I feel that it is important that every > class does what it promises to do. No more, no less. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1