- Boost - lists.boost.org

more on c2_function discussion
by Marcus Mendenhall 26 Mar '06

26 Mar '06

> > Message: 2 > Date: Sat, 25 Mar 2006 12:02:50 -0500 > From: Neal Becker <ndbecker2(a)gmail.com> > Subject: Re: [boost] c2_functions first submission materials uploaded > To: boost(a)lists.boost.org > Message-ID: <e03t3p$2ok$1(a)sea.gmane.org> > Content-Type: text/plain; charset=us-ascii > > Roland Schwarz wrote: > >> Neal Becker wrote: >>> 1. Generic data types instead of hard-coded 'double' >> Hmm, generic? int's won't make any sense would they? >> perhaps double or float but what else? >> > > I was thinking of any float-like type, but that's an interesting > question. > I'm afraid I don't have enough expertise to answer it - do any of > these > algorithms make sense for other numeric fields, (e.g., finite fields)? > That's for another package... This one needs to be kept very focused on plain floating types. >> >> Roland Schwarz wrote: >>> But complex of course could also turn out to be handy at times. >> Too fast again (._.) >> A complex function AFAIK is indefinitely differentiable by >> definition. >> >> So it obviously belongs to the class of C2 but is there such a >> thing as >> complex valued splines? >> Actually, if by this one means a complex function of a real argument, the extension is trivial since one can spline the real & imaginary parts separately. Otherwise, it is a bit murky. > From: Roland Schwarz <roland.schwarz(a)chello.at> > Subject: Re: [boost] c2_functions suggestions commentary > To: boost(a)lists.boost.org > Message-ID: <442589C0.8060006(a)chello.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Marcus Mendenhall wrote: >> For example, for >> bessel functions, one gets derivatives out of the same recursion >> relation (when recurring over the order) used to generate the >> function itself. > True. But why stop at order 2 ? Wouldn't one rather like to be able to > evaluate a function to arbitrary order say n? (y, y_1, y_2, ...y_n ) > Then you would supply a > > 1) framework of function evaluation that returns a vector of > derivatives > whose size is user specifiable or automatically selected by the > algorithm > > 2) a set of algorithms that can make use of derivatives of up to > order n. > > 3) a set of functions that are able to efficiently calculate not only > the function value but also the required number of derivatives. > > E.g.: > > sin(Pi/2,5) would return a vector (1,0,-1,0,1) This is a bang-for-the-buck issue. In real numerical computations, the manipulations get more complex rapidly for higher derivatives, but the yield gets less. Especially since this is aimed significantly at physical data, two derivatives is about all one has reason to believe in. I think a general C(N) package is really something for theorists to use, but then one can just use Mathematica for that kind of calculation any. Let's not try to rewrite Mathematica with this package. I would rather contribute a package which does a focused task perfectly and compactly, than a big fuzzy package that no one can use because it does too many things halfway. > > Message: 6 > Date: Sat, 25 Mar 2006 19:29:10 +0100 > From: Roland Schwarz <roland.schwarz(a)chello.at> > Subject: Re: [boost] c2_functions suggestions commentary > To: boost(a)lists.boost.org > Message-ID: <44258BF6.6000203(a)chello.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Marcus Mendenhall wrote: >> The cubic splines (as opposed to piecewise cubic interpolators) are >> very smooth at the boundaries, so I think there is not a problem >> there. It has worked for me with no difficulties. > > Hmm, whether a spline is interpolating or approximating only has to do > with how you calculated its pivot values. I am not sure if I > understand > you correctly here. > > Roland > If you look at the source for splint (which derives, a long ways back from the code in Numerical Recipes, but is heavily modified), you will see the forced continuity at the boundaries, including a way of expanding which (I hope) should result in good roundoff behavior at the boundary. Anyway, the root finder uses a numerical tolerance which should prevent it from having convergence issues due to the last bit anyway. > ------------------------------ > > Message: 10 > Date: Sat, 25 Mar 2006 15:03:44 -0500 > From: Jason Hise <chaos(a)ezequal.com> > Subject: Re: [boost] c2_functions first submission materials uploaded > To: boost(a)lists.boost.org > Message-ID: <4425A220.4070900(a)ezequal.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> > Rational numbers? > The concept of a continuous function on the rationals is suspect to me. Also, this is focused on numerical computation, not number theory. Everything is a float of some sort, to me!

4 3

Re: [boost] c2_functions suggestions commentary
by Marcus Mendenhall 25 Mar '06

25 Mar '06

I received a lot of useful suggestions for the c2_functions package I am working on. This includes some replies & discussion to those comments. Thanks for the interest! > ------------------------------ > > Message: 9 > Date: Sat, 25 Mar 2006 09:36:23 -0000 > From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> > Subject: Re: [boost] c2_functions first submission materials uploaded > To: <boost(a)lists.boost.org> > Message-ID: <E1FN5C4-0003Dl-3s(a)he303war.uk.vianw.net> > Content-Type: text/plain; charset="us-ascii" > > My knowledge in this field is only sufficient that I can tell that > this > shows some serious expertise in function fitting! > > Boost is thin in support for important parts of numerical analysis > that have > wide, if sometimes apparently niche, potential application, and not > just in > 'rocket science' physics. > > But in order to sell this to Boosters (as I know from experience > with trying > to promote widely used mathemetical functions), some better (and some > simpler and gentler) real-life examples will be needed as well your > erudite > whitepaper. > Yes, I know I need a lot more examples. I am working on this. The predecessor to this package was written for internal use at Vanderbilt, inside my own code, so it was not well documented, other than by my own use. It appears now that interest is high enough that I will pursue fleshing out the docs. > > > ------------------------------ > > Message: 12 > Date: Sat, 25 Mar 2006 13:57:33 -0000 > From: "John Maddock" <john(a)johnmaddock.co.uk> > Subject: Re: [boost] c2_functions first submission materials uploaded > To: <boost(a)lists.boost.org> > Message-ID: <056001c65014$215da0f0$4ee70c52@fuji> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > >> I have uploaded c2_functions.zip to the file vault. It contains the >> code for c2_functions (header & source), an html folder with Doxygen >> documentation, and a white paper describing the theory of this >> package. Anyone who is interested, look over this and let me know >> how the group wishes to proceed. > > I particularly like the idea that the library is effectively doing > symbolic > math internally, could the library be adapted to output symbolic > derivative > information: so given a formula for f(x) tell you what the > derivatives are? > I think that is what Mathematic is for! Really, I want to keep this a light-weight package. > With regard to the interface, it looks quite reasonable to me, > questions > likely to crop up during a review are: > > 1) Why restrict the library to double precision, could it made into a > template that works at arbitrary precision? Yes, I could templatize the whole thing, I suppose. > 2) Would it be possible to make c2function a handle-body class? > The classes > that currently inherit from c2function would then all become > implementation > details, and c2function would become a smart ptr to the actual > representation. The advantage is that you can pass c2functions around > without worrying about it's actual type (a lot like Boost.Function). > Composition of primitives could be handled by non-member free > functions, or > by operators: > > so given: > > c2function a, b; > > then: > > c2function c = a*b; // does the right thing internally. > This is already supported by the package. I will have to investigate handle-body classes and see if they help. The c2_binary_function (and children) and c2_composed_function already allow what you describe. > 3) How easy is the library to extend to new primitives, for example if > someone wanted to add sinh or something would that be straightforward? > Very easy. Look at c2_sin(). Just provide a value_with_derivatives virtual function, and everything else happens automatically. > 4) The library probably needs some concrete use cases to get people > interested :-) > Agreed. > ------------------------------ > > Message: 15 > Date: Sat, 25 Mar 2006 10:34:59 -0500 > From: Neal Becker <ndbecker2(a)gmail.com> > Subject: Re: [boost] c2_functions first submission materials uploaded > To: boost(a)lists.boost.org > Message-ID: <e03nv2$j99$1(a)sea.gmane.org> > Content-Type: text/plain; charset=us-ascii > > 1. Generic data types instead of hard-coded 'double' > I'm thinking about it... shouldn't be hard. > 2. Generic container types instead of hard-coded 'std::vector' > Same > 3. Does support of complex make any sense here? > Maybe, although a lot of the most useful things (interpolating functions & root finding) have very different meanings in the complex domain, so I think this probably belogs in son_of_c2_functions. > > > ------------------------------ > > Message: 16 > Date: Sat, 25 Mar 2006 16:46:47 +0100 > From: Roland Schwarz <roland.schwarz(a)chello.at> > Subject: Re: [boost] c2_functions first submission materials uploaded > To: boost(a)lists.boost.org > Message-ID: <442565E7.8000006(a)chello.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > I have seen from the doc's that c2_functions will also deal with root > finding of splines. From my experience with this topic I found that > this > is a numerically hard problem when interested in the number of > roots, if > the spline is being evaluated at it's splicing points. I.e. the number > of roots might be different depending whether evaluated on the > right or > left side. As far as I remember the value of the root(s) could also > differ slightly. I tried to cure this by defining the elementary > functions on half open intervals, but besides forcing the end > "interval" > being a single point, I also found the asymmetry somewhat unsatisfying > (which end should be open, based on what rationale?) I would be very > interested if you have some findings in this area. > The cubic splines (as opposed to piecewise cubic interpolators) are very smooth at the boundaries, so I think there is not a problem there. It has worked for me with no difficulties. > Al tough it might sound stupid to ask for inversion of a non monotonic > function it might be valuable to get it's main branch, the number of > branches or even an array filled with c2_functions one of each > represents one of the side branches. @Mendenhall: What do you think? > I think this is addressed by setting the domain (using set_domain) before root-finding or inversion. The global function need not be monotonic, only on the specified domain. Does this solve the problem? > I came across this type of problem when I tried to do "inverse- > sampling" > of a spline function. I.e. find the abscissa values that correspond to > equal sized ordinate steps. (Finding the time instances when to apply > impulses to a stepper motor, given the ordinate is the step number, to > control time dependent position of the motor. The spline was the > result > of some algorithm where it turned out to be very handy to view it as a > function. ) > This is exactly the kind of thing I use splines and inverse_functions of splines for. > Do you also intend to build into the library the ability to construct > the splines from the different possible data sets e.g x,y tables and > various boundary conditions? > There is no reason not to do this, given manpower. > Did you consider extending the library to multivalued functions too? > That is a more complex issue, probably also for son_of_c2_functions. > Regards, > Roland > > > Message: 17 > Date: Sat, 25 Mar 2006 17:06:55 +0100 > From: Roland Schwarz <roland.schwarz(a)chello.at> > Subject: Re: [boost] c2_functions first submission materials uploaded > To: boost(a)lists.boost.org > Message-ID: <44256A9F.1010700(a)chello.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Neal Becker wrote: >> 1. Generic data types instead of hard-coded 'double' > Hmm, generic? int's won't make any sense would they? > perhaps double or float but what else? > long doubles, I assume is the interest. >> 3. Does support of complex make any sense here? > I would rather like to see multivalued functions. > But complex of course could also turn out to be handy at times. > Sometime! Since this is unfunded work for the moment, it will have to grow slowly. Given the level of interest expressed on this list, I may seek NSF funding (or some such) to give me some time to proceed with this effort. > Roland > ------------------------------ > > Message: 19 > Date: Sat, 25 Mar 2006 17:43:20 +0100 > From: Roland Schwarz <roland.schwarz(a)chello.at> > Subject: Re: [boost] c2_functions first submission materials uploaded > To: boost(a)lists.boost.org > Message-ID: <44257328.9020909(a)chello.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Roland Schwarz wrote: >> But complex of course could also turn out to be handy at times. > Too fast again (._.) > A complex function AFAIK is indefinitely differentiable by definition. > > So it obviously belongs to the class of C2 but is there such a > thing as > complex valued splines? > Right. extending this to complex is a new can of worms, suitable for the future. > Then what about function composition? For the equivalence of complex > differentiation rules with real valued ones you need that the complex > function is identical to its real valued counterpart when evaluated > on a > part of the real line (sloppy speaking). So this will force the > function > class to be C_infinite. Or am I missing something? > Again, right. Lots more complexities as to what these operations mean when moved out of 1-dimensional real functions. > I think c2_functions are not so much interesting because they are > carrying their derivatives with them, but because they are a handsome > tool to deal with splines in a very readable manner. > The main reason for the rest of the package is, indeed, to provide a lot of very useful operations on splines, although there may be some occasional reasons to use them as freestanding object, especially for root-finding. I also see a future in which I develop a larger special-functions class to go with it. One of the features of most special functions is that it is very inexpensive to generate the derivatives at the same time as the main function. For example, for bessel functions, one gets derivatives out of the same recursion relation (when recurring over the order) used to generate the function itself. Thus, this the adaptive integrator in this can potentially be used to great effect to compute integrals of special functions multiplied by (for example) interpolating functions for use in wave function, etc. > Having said this, I think c2_functions should not be used for > hiding the > algorithm developers laziness to modify his/her algorithm to make > use of > whatever is known about the functions (in case of analytic funtions > you > know all derivatives!). > Actually, I disagree here. In a lot of cases, for numerical analysis, hiding further information is enough! It provides a lot of efficieny > c2_functions in my opinion is a want-to-have tool to deal with > splines > numerically, while still focusing on it's appearance as a function. > > Other directions deviate from numerical use and extend to symbolic > systems. This would also be desirable to have, but I think it > should go > to a different library. my feelings exactly.

2 2

c2_functions first submission materials uploaded with cleanups
by Marcus Mendenhall 25 Mar '06

25 Mar '06

After some very useful discussion with pavel_vozenilek(a)hotmail.com I have uploaded c2_functions_boost_prelim.20060325.zip to the file vault. It contains the code for c2_functions (header & source), an html folder with Doxygen documentation, and a white paper describing the theory of this package. Anyone who is interested, look over this and let me know how the group wishes to proceed. Marcus Mendenhall

1 0

Request for commentary about Boost interest in a new numerics package
by Marcus Mendenhall 25 Mar '06

25 Mar '06

I have been working on a compact (1 header, 1 cpp file, total about 1500 lines) and highly portable package for numerical operations on smooth functions. The package is in internal use by my research collaborators at Vanderbilt, and is very stable. The package consists of routines for manipulating smooth functions, which are defined as functions which are capable of not only returning their value, but the first two derivatives. Obvious cases are analytic functions, and cubic splines. The name of the package (and the objects it represents) is C2Functions. The most important and interesting parts of the package are 1) Very general spline support, including transparent change of variables in both X and Y to permit storage of linearized spline tables, while still presenting the function externally as it was established. Examples are LogLogInterpolatingFunction, LogLinInterpolatingFunction, etc., but the class is extensible to other schemes. These transformations allow high accuracy representation of functions by reducing the second derivatives in the spline tables, while exactly reconstructing the derivatives when evaluated. 2) Functional algebra, allowing one to generate new functions, constructed of old ones, which automatically keep track of the derivatives correctly. Thus, one can trivially write a new function g=C2Sin(f) where f is another C2Function, and g will correctly carry the derivatives through the composition. Available operators include basic binary functions, and composition. This allows a very compact representation of 'stiff' functions, such as the sine of a slowly varying phase error superimposed on a time, since the phase error can be embedded in an InterpolatingFunction, and the composition operation will reconstruct the exact derivatives of the rapidly varying sinusoid. 3) Very fast root finding and adaptive integration. Since the functions are smooth, and have exactly known derivatives, numerical methods are be introduced which are extraordinarily efficient. 4) Very light weight implementation. The C2Functions package is very shallowly nested, and the objects it creates are very low consumers of memory. They do almost no memory management themselves, leaving the user to be in charge of remembering to create and destroy them. In many cases, a lot of the work can be done with statically constructed functional compositions, etc., into which one plugs a pointer at run time to a particular function to which the operations will apply. As it currently stands, the only conflicts with Boost style are 1) naming... if the package is considered 'likely to be interesting', I will rename all functions to conform to Boost style 2) exception specification... I put these in while writing the code, thinking them to be a good idea, but I agree with the Boost rationale, and would gladly eliminate them. If this package is deemed interesting by the Boost community, it can be quickly cleaned up for actual submission. At present, I am working on a package of documentation for it, which describes both the thoery behind the package and its application. This still needs a bit of work. Comments? Thanks in advance. Marcus Mendenhall Research Associate Professor of Physics Vanderbilt University

4 3

Re: [boost] [shared_ptr] Best Practices - new_shared_ptr
by David Abrahams 24 Mar '06

24 Mar '06

Larry Evans <cppljevans(a)cox-internet.com> writes: > On 03/24/2006 11:00 AM, David Abrahams wrote: > [snip] >> Yes, the library ought to contain something like that, as I have been >> saying for years. Probably it should be spelled something like: >> new_<shared_ptr<T> >(a, b, c, ...) >> new_<auto_ptr<T> >(a, b, c, ...) >> Unfortunately, really making these functions work correctly for more >> than about 5 or 6 arguments is currently not feasible because of >> what's known as "the forwarding problem" (google it). >> Boost Consulting is working on a project where we'll need this >> functionality, so I hacked up the enclosed. I'm going to generalize >> it (and hopefully, optimize compilation speed) a bit and try to get it >> into Boost. In the meantime, enjoy. > > I tried to post the following but got an error. I'm trying again, > but I've also mailed directly to David in case I'm unsuccessful. > <--------------- cut here ------------------- <snip> > Of course I see that that would still require all the boost_pp > forwarding magic in David's new_.hpp, but it would be nice if > the new_ forwarding magic and that in auto_overhead could be > merged somehow increase reuse. That's what I meant when I wrote that I was going to generalize the code. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] problem with boost_unit_test : BOOST_CLASS_TEST_CASE seemsno the access instance at the right address, on Mac OS X, with gcc 4.0.1/2 with optimization level > 0
by Ananda Tallur 24 Mar '06

24 Mar '06

Hello Gennadiy, Thank you very much for you answer, and sorry for having forgotten something a important as mentionning the Boost version used ! In fact, I have tried with three Boost versions : 1.33.1, 1.33.0, and 1.32.0, compiled with Apple gcc 4.0.1, and the same is exactly the same with these three versions. I have just tried the test again, with the included version of unit_test_framework : - including <boost/test/included/unit_test_framework.hpp> instead of <boost/test/unit_test.hpp> - not linking the test program against boost_unit_test static library The test result is exactly the same as when using the static library version : ---- Running 1 test case...a : 13691 boost_unit_test_gcc4_pb_sample.cpp(18): error in " SampleTest::sampleTest": check a == 12345 failed [13691 != 12345] *** 1 failure detected in test suite "Sample test" So it really seems to show that there is a problem with the compiler from Apple. I am currently using build Apple gcc 4.0.1 build 5250, but I have also tried with previous version (build 5247), and the problem is the same. But it works with gcc 3.3 from Apple, and with gcc 4.0.1 without optimizations. I have already issued a bug report to Apple. Thank you again for your answer, do you think of some other test I could do to precise the problem ? And also, it would be great if another Mac OS X user could try the test program I have sent in my previous e-mail, and confirm the problem. Best regards, Anand On 6 mars 06, at 18:00, boost-request(a)lists.boost.org wrote: > Date: Mon, 6 Mar 2006 11:44:43 -0500 > From: "Gennadiy Rozental" <gennadiy.rozental(a)thomson.com> > Subject: Re: [boost] problem with boost_unit_test : > BOOST_CLASS_TEST_CASE seemsno the access instance at the right > address, on Mac OS X, with gcc 4.0.1/2 with optimization level > 0 > To: boost(a)lists.boost.org > Message-ID: <duhotr$dmg$1(a)sea.gmane.org> > > Hi, Ananda > > I did not reply to your post in users list, since I do not have any > idea > what could be casuing this. One question: which version of boost > you are > using. One recommendation: try to use included version of UTF > <boost/test/included/unit_test_framework.hpp> and let us know the > results. > > Regards, > > Gennadiy

2 2

Serious problem with gcc 4 on Mac OS X, when using boost:shared_ptr
by Ananda Tallur 24 Mar '06

24 Mar '06

Hello, Originally, I had discovered a problem when using boost::unit_test_framework, for which I have already posted. But, by further analysing the problem, I could come out to a simple program, using only boost shared pointers, and which fails : -> on Mac OS X 10.4 -> when compiled with gcc 4.0.1 (coming with XCode 2.2.1), or gcc 4.1 (delivered by darwin ports) -> with optimisations : at least -O, or -O1, or -O2,etc... It works correctly with -O0 -> using either boost 1.33.1, 1.33.0, or 1.32.0 Below is the sample test program : --- macosx_gcc4problem.cpp --- #include <iostream> #include <boost/shared_ptr.hpp> using namespace std; using namespace boost; struct A { int value; ~A () { std::cout << "A destructor" << std::endl << std::flush; } }; struct B { B (shared_ptr <A> val) : a (val) {} shared_ptr <A> a; }; struct C { C (B val) : b (val) {} B b; }; struct D { D (C val) : c (val) {} C c; }; D create () { boost::shared_ptr <A> a (new A); a->value = 12345; return D (C (B (a))); } int main (int argc, char * argv []) { D d = create (); std::cout << "value = " << d.c.b.a->value << std::endl << std::flush; return 0; } --- macosx_gcc4problem.cpp --- To compile it : g++-4.0 -O2 -I <path-to-boost-includes> macosx_gcc4problem.cpp -o macosx_gcc4problem Output : When run, the value displayed is 13691, instead of 12345 as it should. Analysis : -> there is a problem in shared_ptr reference counting, in line : return D (C (B (a))); Just after D creation, the reference counter is at 1, instead of 2 as it should. And when leaving create () function, the automatic variable a is detroyed, which changes the reference counter to 0 and detroys the A object. In main function after call to create (), the reference counter should be of 1, and the object A should be available on the heap. But it has already been destroyed, leading to an incorrect result being displayed. In worst cases, a segmentation fault may happen. Remark : if changing the constructor of B, so that a const reference to the shared_ptr is passed, instead of the shared_ptr itself, it works : --- struct B { B (const shared_ptr <A> &val) : a (val) {} --- To further investigate the problem, it may be needed to analyse the assembly code generated by the gcc 4 compiler. The problem is clearly in the line : return D (C (B (a))); There may be a problem with management of temporary variables, combined with optimisations. I require the help of other developpers working on Mac OS X, because I think this problem could concern many of us. I guess It is likely that the problem is not specifically caused by boost, but may rather be a gcc 4 compiler problem on Mac OS X. Thanks Anand

2 1

Bug list status
by Marshall Clow 24 Mar '06

24 Mar '06

Sorry for the long delay between postings - things have been hectic. I see that without my nagging ;-), the list of bugs has started to grow again. Last Report: 54 bugs Today: 62 bugs Let's try to knock these bugs down for 1.34! Thanks in advance! If anyone would like to integrate the "Fixes for build on IBM pSeries for AIX and Linux" currently assigned to "Nobody", please let me know! If you think that a bug has been assigned incorrectly, please let me know. Bug counts per assignee: Mike Glassford 9 Doug Gregor 5 Stephen Cleary (shammah) 5 Jeremy Siek 5 Jeff Garland (az_sw_dude) 4 Joerg Walter 4 Eric Friedman (ebf) 3 Samuel Kremp 3 John R. Bandela 2 Marshall Clow 2 Joel de guzman (djowel) 2 Thorsten Ottosen (nesotto) 2 Vladimir Prus 2 Rene Rivera (grafik) 2 Jonathan Turkanis 2 Nobody 2 Beman Dawes 1 Aleskey Gurtovoy (agurtovoy) 1 Kevlin Henney 1 Hubert Holin 1 Jaakko Jurvi (urzuga) 1 John Maddock 1 Here are the bugs, sorted by assignee: Assignee: agurtovoy <http://sourceforge.net/users/agurtovoy/> Summary: mpl::remove compile error with gcc 4.1.0 Bug #: 1453180 <http://sourceforge.net/tracker/index.php?func=detail&aid=1453180&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: wrong usage of ios_base::narrow Bug #: 989487 <http://sourceforge.net/tracker/index.php?func=detail&aid=989487&group_id=75…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: date_time type conversion warning Bug #: 1069225 <http://sourceforge.net/tracker/index.php?func=detail&aid=1069225&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: local_adjustor::utc_to_local throws 'Time label invalid' Bug #: 1220011 <http://sourceforge.net/tracker/index.php?func=detail&aid=1220011&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: bjam don`t copy lib & dll files to stage Bug #: 1402743 <http://sourceforge.net/tracker/index.php?func=detail&aid=1402743&group_id=7…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: linker error mingw 3.4.5 Bug #: 1426819 <http://sourceforge.net/tracker/index.php?func=detail&aid=1426819&group_id=7…> Assignee: daniel_wallin <http://sourceforge.net/users/daniel_wallin/> Summary: [Parameter] Docco error section 2.7.2 Bug #: 1378446 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378446&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: LEDA graph adaptors do not handle hidden nodes properly Bug #: 1168431 <http://sourceforge.net/tracker/index.php?func=detail&aid=1168431&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: random_vertex/random_edge are unnecessarily inefficient Bug #: 1204684 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204684&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: Document copy_component Bug #: 1204688 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204688&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: reverse_graph and constness of property maps Bug #: 1246336 <http://sourceforge.net/tracker/index.php?func=detail&aid=1246336&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: Bundled graph properties Bug #: 1420498 <http://sourceforge.net/tracker/index.php?func=detail&aid=1420498&group_id=7…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: Miss ' = ParserT()' Bug #: 907299 <http://sourceforge.net/tracker/index.php?func=detail&aid=907299&group_id=75…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: spirit insert_key_actor.hpp Bug #: 1059936 <http://sourceforge.net/tracker/index.php?func=detail&aid=1059936&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: boost::blank - missing operators Bug #: 1191356 <http://sourceforge.net/tracker/index.php?func=detail&aid=1191356&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: [variant] Bug in recursive_wrapper_fwd.hpp Bug #: 1359257 <http://sourceforge.net/tracker/index.php?func=detail&aid=1359257&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: ambiguous overloads in boost::variant source code Bug #: 1456780 <http://sourceforge.net/tracker/index.php?func=detail&aid=1456780&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: AIX 4.3 SIGSEGV at thread termination Bug #: 551577 <http://sourceforge.net/tracker/index.php?func=detail&aid=551577&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: boost::threads uses msvc only function? Bug #: 568951 <http://sourceforge.net/tracker/index.php?func=detail&aid=568951&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: BCB6 throw EExternelException Bug #: 596149 <http://sourceforge.net/tracker/index.php?func=detail&aid=596149&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: thread_cleanup problems Bug #: 649291 <http://sourceforge.net/tracker/index.php?func=detail&aid=649291&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Mac implementation of threads is CPU hog Bug #: 885045 <http://sourceforge.net/tracker/index.php?func=detail&aid=885045&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: condition variables and recursive_mutex Bug #: 1072605 <http://sourceforge.net/tracker/index.php?func=detail&aid=1072605&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: compiler error on Mac implementation of threads Bug #: 1201779 <http://sourceforge.net/tracker/index.php?func=detail&aid=1201779&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Exception safety in class 'thread' Bug #: 1305885 <http://sourceforge.net/tracker/index.php?func=detail&aid=1305885&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Memory leak in tss Bug #: 1424965 <http://sourceforge.net/tracker/index.php?func=detail&aid=1424965&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost jam problem with parallel builds Bug #: 1234224 <http://sourceforge.net/tracker/index.php?func=detail&aid=1234224&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost.build needs fixes for HP/UX Bug #: 1395924 <http://sourceforge.net/tracker/index.php?func=detail&aid=1395924&group_id=7…> Assignee: hubert_holin <http://sourceforge.net/users/hubert_holin/> Summary: Cannot compile octonion_test.cpp because of bug in sinc.hpp Bug #: 751289 <http://sourceforge.net/tracker/index.php?func=detail&aid=751289&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: Compiler error for tokenizer on Solaris Bug #: 976241 <http://sourceforge.net/tracker/index.php?func=detail&aid=976241&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: token_iterator::at_end() result is inversed Bug #: 1338326 <http://sourceforge.net/tracker/index.php?func=detail&aid=1338326&group_id=7…> Assignee: jmaurer <http://sourceforge.net/users/jmaurer/> Summary: Diff in state of mersenne_twister gen between GCC3.41 & CW9 Bug #: 1115124 <http://sourceforge.net/tracker/index.php?func=detail&aid=1115124&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: bug in ublas/storage.hpp Bug #: 1095697 <http://sourceforge.net/tracker/index.php?func=detail&aid=1095697&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: dead links in uBLAS page Bug #: 1169273 <http://sourceforge.net/tracker/index.php?func=detail&aid=1169273&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: Documentation not available on web site: Bug #: 1228242 <http://sourceforge.net/tracker/index.php?func=detail&aid=1228242&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: uBLAS::subslice doesn't work Bug #: 1292635 <http://sourceforge.net/tracker/index.php?func=detail&aid=1292635&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: Adding boost::is_complex to type_traits.hpp Bug #: 1315712 <http://sourceforge.net/tracker/index.php?func=detail&aid=1315712&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: invalid result for File Dependency Examp Bug #: 551110 <http://sourceforge.net/tracker/index.php?func=detail&aid=551110&group_id=75…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Spelling of Edmonds-Karp-Algorithm Bug #: 1226292 <http://sourceforge.net/tracker/index.php?func=detail&aid=1226292&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: g++ v3.2.3 inker error for read_graphviz ih boost v1.33.1 Bug #: 1378907 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378907&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Calling subgraph::global_to_local on a root graph Bug #: 1444271 <http://sourceforge.net/tracker/index.php?func=detail&aid=1444271&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Calling subgraph::global_to_local on a root graph Bug #: 1444293 <http://sourceforge.net/tracker/index.php?func=detail&aid=1444293&group_id=7…> Assignee: kevlin <http://sourceforge.net/users/kevlin/> Summary: lexical_cast & pure virtual functions & VC 8 STL Bug #: 1358600 <http://sourceforge.net/tracker/index.php?func=detail&aid=1358600&group_id=7…> Assignee: mclow <http://sourceforge.net/users/mclow/> Summary: Solaris - once.cpp compile error Bug #: 549162 <http://sourceforge.net/tracker/index.php?func=detail&aid=549162&group_id=75…> Assignee: mclow <http://sourceforge.net/users/mclow/> Summary: mistake in documentation of condition Bug #: 1364416 <http://sourceforge.net/tracker/index.php?func=detail&aid=1364416&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: boost.range and 'const char[]'. Bug #: 1272315 <http://sourceforge.net/tracker/index.php?func=detail&aid=1272315&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: [Boost.Range]boost::const_begin calls non-qualified 'begin' Bug #: 1361686 <http://sourceforge.net/tracker/index.php?func=detail&aid=1361686&group_id=7…> Assignee: nobody Summary: Fixes for build on IBM pSeries for AIX and Linux Bug #: 1446468 <http://sourceforge.net/tracker/index.php?func=detail&aid=1446468&group_id=7…> Assignee: nobody Summary: Fixes for build on IBM pSeries for AIX and Linux Bug #: 1446471 <http://sourceforge.net/tracker/index.php?func=detail&aid=1446471&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: format: assert when parsing invalid pattern Bug #: 1326132 <http://sourceforge.net/tracker/index.php?func=detail&aid=1326132&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: boost::format parse method doesn't work Bug #: 1439607 <http://sourceforge.net/tracker/index.php?func=detail&aid=1439607&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: 64 bit compile warning/error for boost::format Bug #: 1451470 <http://sourceforge.net/tracker/index.php?func=detail&aid=1451470&group_id=7…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: ct_gcd_lcm.hpp compilation error Bug #: 558174 <http://sourceforge.net/tracker/index.php?func=detail&aid=558174&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: pool::purge_memory() does not reset next_size Bug #: 984124 <http://sourceforge.net/tracker/index.php?func=detail&aid=984124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: Borland compiler error with Pool, boost::pool_allocator Bug #: 988124 <http://sourceforge.net/tracker/index.php?func=detail&aid=988124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: perfomance: memory cleanup for pool takes too long Bug #: 995270 <http://sourceforge.net/tracker/index.php?func=detail&aid=995270&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: boost::pool_allocator breaks with vector of vectors Bug #: 1179641 <http://sourceforge.net/tracker/index.php?func=detail&aid=1179641&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational operator&lt; can overflow Bug #: 798357 <http://sourceforge.net/tracker/index.php?func=detail&aid=798357&group_id=75…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: problem with boost::iostreams when compiled with Visual C++ Bug #: 1365752 <http://sourceforge.net/tracker/index.php?func=detail&aid=1365752&group_id=7…> Assignee: urzuga <http://sourceforge.net/users/urzuga/> Summary: [boost::lambda] Compile error with libstdc++ debug mode Bug #: 1444052 <http://sourceforge.net/tracker/index.php?func=detail&aid=1444052&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: multitoken broken in program_options 1.33 Bug #: 1266877 <http://sourceforge.net/tracker/index.php?func=detail&aid=1266877&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: program_options: additional parser bug Bug #: 1433424 <http://sourceforge.net/tracker/index.php?func=detail&aid=1433424&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 2

[Boost-bugs] [ boost-Support Requests-1457763 ] Cross compiling boost for Windows CE (ARM) from VS2005
by SourceForge.net 24 Mar '06

24 Mar '06

Support Requests item #1457763, was opened at 2006-03-24 06:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1457763&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Building Boost Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling boost for Windows CE (ARM) from VS2005 Initial Comment: I wondered if this would ever be a supported scenario. I have VS2005 Pro, and want to use Boost in a project on Windows Mobile 5, compiling for the ARM architecture. I can't find any documentation telling me how to do this, and from my attempts at getting it to cross compile I get the impression it isn't supported. For starters you get "Unknown CE compiler" in visualc.hpp. Thats easily fixed, but then getting bjam to install compiling for ARM doesn't seem to work. Apologies if this is not a bug, but I'm pretty much at the point of having to ditch Boost, and thats a shame. Damian Wilson (mail damian dot wilson 71 at ntlworld dot com) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1457763&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [threading] rewrite (was: Bug list status)
by Martin Bonner 24 Mar '06

24 Mar '06

From: Roland Schwarz > The intent is not to change interface while creating a better platform > separation of the library. And of course put it under the new license > which obviously implies the need for a rewrite. Thanks. That sounds /very/ reasonable. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0