July 2004 - Boost - lists.preview.boost.org

Re: Boost Mathematicians
by Michael Stevens 06 Jul '04

06 Jul '04

On Tuesday 06 July 2004 01:30, "Aleksey Gurtovoy" <agurtovoy(a)meta-comm.com> wrote: > Neither 'size1' nor 'num_rows' are generic, though. What you want is > something like > > template< int n > size(int_<n>); > > The particular int_<n> specializations then can be typedef'ed to > something more mnemonic, e.g. > > typedef int_<0> rows; > > or even > > extern int_<0> rows; > > The lack of this genericity will force you, sooner or later, to resort > to code duplication. I believe Vesa made the same point a long time > ago... yep: http://thread.gmane.org/gmane.comp.lib.boost.devel/60338. Aleksey, Thanks for point this out. I had forgotten about Vesa contribution. It seems this is very much a repeat of the discussion you link to. Interestingly uBLAS never did get the generic versions of the functions. Although it gained a set of similar functions for major/minor mappings. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

Re: Lightweight Mutex Code
by Tyson Whitehead 06 Jul '04

06 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron W. LaFramboise wrote: > I am not sure what the status of these are. Are other components > supposed to be using these? I came upon them when I was checking out the smart pointers implementation. Grepping the source seems to indicate 'lightweight_mutex.hpp' is only used by the smart pointers (only included by 'quick_allocator.hpp' and 'shared_count.hpp') under multithreaded conditions. > In addition to what you mentioned, they're broken in other ways: > > If a low priority thread is preempted by a high priority thread > immediately before __atomic_add, and the high priority thread is > attempting to grab the spinlock, deadlock is acheived, despite the > sched_yield(). I missed that one. You're right though, and not only that, but the sched_yield manpage states (I'm assuming this applies to threads -- threads in Linux are actually processes -- right?): "Note: If the current process is the only process in the highest priority list at that time, this process will continue to run after a call to sched_yield." The implementer seemed to be aware there could be priority problems though. The relevant comments in 'lightweight_mutex.hpp' are: // * Used by the smart pointer library // * Performance oriented // * Header-only implementation // * Small memory footprint // * Not a general purpose mutex, use boost::mutex, CRITICAL_SECTION or // pthread_mutex instead. // * Never spin in a tight lock/do-something/unlock loop, since // lightweight_mutex does not guarantee fairness. // * Never keep a lightweight_mutex locked for long periods. // // The current implementation can use a pthread_mutex, a CRITICAL_SECTION, // or a platform-specific spinlock. // // You can force a particular implementation by defining // BOOST_LWM_USE_PTHREADS, // BOOST_LWM_USE_CRITICAL_SECTION, or // BOOST_LWM_USE_SPINLOCK. // // If neither macro has been defined, the default is to use a spinlock on // Win32, and a pthread_mutex otherwise. // // Note that a spinlock is not a general synchronization primitive. In // particular, it is not guaranteed to be a memory barrier, and it is // possible to "livelock" if a lower-priority thread has acquired the // spinlock but a higher-priority thread is spinning trying to acquire the // same lock. // // For these reasons, spinlocks have been disabled by default except on // Windows, where a spinlock can be several orders of magnitude faster than a // CRITICAL_SECTION. The current Win32 doesn't have the counter problems, and claims to be able to yield to lower priority threads, so it should be okay. The relevant lock routine is (m_.l_ is initialized to 0): while( InterlockedExchange(&m_.l_, 1) ){ // Note: changed to Sleep(1) from Sleep(0). // According to MSDN, Sleep(0) will never yield // to a lower-priority thread, whereas Sleep(1) // will. Performance seems not to be affected. Sleep(1); } The unlock routine is: InterlockedExchange(&m_.l_, 0); - -T - -- Tyson Whitehead (-twhitehe(a)uwo.ca -- WSC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6a+FRXbLmIoqtdgRAqxRAJ0RxqXlsbc5i5GBCydxFWgqTU32sQCgyJ/Y py3rSxTj5BiVUmXPqoP/zcY= =nVLD -----END PGP SIGNATURE-----

5 8

Lightweight Mutex Code
by Tyson Whitehead 06 Jul '04

06 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I believe there is a mistake in the 'details/lwm_gcc.hpp' and 'details/lwm_linux.hpp' (and possibly the other lightweight_mutex implementation as well -- I haven't looked at them). In both of these files we have a counter (m_.a_) that is initialized to 1. The lock routine is implemented as follows: while( !__exchange_and_add(&m_.a_, -1) ){ __atomic_add(&m_.a_, 1); sched_yield(); } The unlock as: __atomic_add(&m_.a_, 1); This works if there are only two contenders for the lock. It can fail if there are three or more: 1- Thread one takes the lock, putting the counter at 0. 2- Thread two does the __exchange_and_add, fails the test, and then its time time slice expires before the __atomic_add, leaving the counter at -1. 3- Thread three also takes the lock (because !-1 is false). A simple solution is to initialize the counter to zero and replace the above lock by: while( __exchange_and_add(&m_.a_, 1) ){ __atomic_add(&m_.a_, -1); sched_yield(); } and the unlock by: __atomic_add(&m_.a_, -1); This would result in: 1- Thread one takes the lock, putting the counter at 1. 2- Thread two does the __exchange_and_add, fails the test, and then its time slice expires before it can do the __atomic_add, leaving the counter at 2. 3- Thread cannot take the the lock (because 2 is true). - -T - -- Tyson Whitehead (-twhitehe(a)uwo.ca -- WSC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5dgwRXbLmIoqtdgRAmbyAJ0aZFZvxn5MXeXyNqSAI63o9EqddQCfTK9p wFAoBbQueoo9hLNhXJtit44= =SPra -----END PGP SIGNATURE-----

3 2

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