April 2009 - Boost - lists.preview.boost.org

Re: [boost] [threads] making parts of Boost.Threads header-only
by Brian Wood 09 Apr '09

09 Apr '09

Anthony Williams writes: >Emil Dotchevski <emildotchevski(a)gmail.com> writes: >> >> I am against such a move. Boost Threads requires linking for other >> features which makes it one of the few libraries in Boost that can be >> properly designed to avoid unnecessary physical coupling. Unless >> something is proven to cause performance problems it should not be >> inlined, regardless of how simple it is. > >Wow, that's a hard line you've drawn there. I'm not sure I agree. The >only reason this matters is if you're going to be changing the >implementation and don't want to recompile the code that uses the >header. For boost users, the implementation only changes if they change >boost versions, and in that case I would expect people to recompile >anyway --- I wouldn't trust something compiled against boost 1.37 to >link against a 1.38 lib, for example. I'm sure you know more about Boost than I do, but I disagree that the implementation only changes when users change versions. There are fixes that have to be applied by users to libraries from time to time. I tend to agree with Emil's arguments here. Brian Wood Ebenezer Enterprises www.webEbenezer.net

6 6

[exception] updated in the trunk and in the release branch
by Emil Dotchevski 09 Apr '09

09 Apr '09

Two new functions added: current_exception_cast (http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception_c…) and current_exception_diagnostic_information (http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception_d….) There is a minor breaking change in the interface of the get_error_info function: it used to return shared_ptr, now it returns just a raw pointer: http://svn.boost.org/svn/boost/trunk/libs/exception/doc/get_error_info.html. This limits the lifetime of error_info objects to not exceed the lifetime of the exception object, which could make custom platform-specific error_info optimizations possible (the type of the pointee is guaranteed to be copyable, so if the user needs to hold on to it after the exception object has expired, they can simply copy it instead of relying on shared_ptr to keep it afloat.) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[Polynomial] Review Result
by John Maddock 09 Apr '09

09 Apr '09

Apologies for the delay in putting this together... First off I'd like to thank the author for submitting this for review - I wish all our SOC students were similarly diligent! :-) We received a number of reviews of this library, but none were in favor of acceptance in its current form, and most thought that there was still a fair bit of work to do to get the library into shape. However, most thought that the library could be accepted into Boost given sufficient changes/enhancements. Therefore the library is not accepted into Boost at this time, but I would like to encourage the author to continue to work on the library and resubmit at a future time. In no particular order the main review comments are summarized below: Principal comments: * Documentation, especially the background is inadequate and needs a good proofreading a) From the examples are nothing that a competent programmer couldn't figure out from the declarations. Some more interesting or useful examples would be nice, particularly for things like the special forms. It's not exactly clear what I would do with those functions. b) There is no documentation or references to the various algorithms used. Those, too, would be nice. c) Doc.html appear to have been created 'the Hard Way'. Would be much more useful and look nicer if produced with the Quickbook, Doxygen... toolchain. And make it maintainable by other people. * Use of constructors and assignment operators that modify their arguments isn't acceptable - best to find another interface for this. * Several reviewers noted that the code didn't build for them, in particular log2 isn't available on all platforms/compilers. * evaluate_polynomial() and evaluate_polynomial_faithfully() take their coefficient arguments in the opposite order of all the other functions/constructors in the library, without providing any reason for that choice. That's seems somewhat surprising. I'd suggest fixing that, or at the very least providing an argument in the documentation why this makes some sense. * Rename evaluate() to horner() and provide evaluate() as an inline call to horner(). * Rename evaluate_faithfully() to compensated_horner(). * Things that say "Be careful about this" generally need fixing. * It would be nice to have operator* and operator/ as well as *= and /=. * Considering they share the same core algorithm, it might be nice to have a function that could do division and return the remainder at the same time. Something like poly::divide(P &divisor, P &quotient, P &remainer) * FFTs are good for multiplying polynomials above a certain size, but they are rather heavy for small polynomials and can lead to unexpected crosstalk between terms. There should be an option for * that doesn't use the FFT, and it should be the default for small polynomials. * operator/= has a hardcoded "std::vector<double> new_coefficients" that later gets rounded?? This should be fixed to work with any type that fulfills the necessary conceptual requirements (and tested and documented what those requirements are - it would be nice if they were the same as the rest of Boost.Math). * The name FieldType is mathematically misleading since the instantiating type is very likely not to be a field (e.g. int or a multiple precision integer type). * the Polynomial class provides a fairly minimalist set of supported functions. This may well be deliberate (if so, apologies), but I would like to see a richer interface including such things as - content (gcd of coefficients, where that makes sense) - polynomial discriminant - resultant of 2 polynomials - evaluation of homogeneous polynomial ( f(x) = sum c_i x^i,f(a,b) = sum c_i a^i b^(d-i) ) - evaluation at a polynomial (f(g(x))) - Pseudo-division of polynomials - finding roots over C - finding roots over F_p - factorisation over Z - factorisation over F_p * We had one feature request for extending support to finite fields. * This constructor: template<typename U> polynomial(const U& v); had me a little confused at first - is there any advantage to making this a template rather than simply accepting a const FieldType& as the single argument? * It's not clear from the documentation what this constructor does: polynomial(InputIterator first1, InputIterator last1, InputIterator first2); It needs to clearly state the degree of the resulting polynomial and whether it passes through all/any of the points - in fact maybe the constructor should have a final parameter for the degree of the polynomial and use least-squares fitting when required? Likewise for the member function template<typename InputIterator> void interpolate(InputIterator first1, InputIterator last1, InputIterator first2); * Operators: the / and % operators need good descriptions of what they do, given that no exact division is possible. As someone else has already noted, a function to calculate divide and remainder in one step would be useful too. * GCD: presumably this is restricted to polynomials with integer coefficients? If so it should say so. * Evaluation: The docs should say what method is used for the evaluate_faithfully method and give a reference. Renaming as someone else suggested may be better too, but personally I'm easy either way on that. I'm not sure whether there should be an evaluate_by_preconditioning method, shouldn't the polynomial "know" that it has been preconditioned and react accordingly. I haven't looked/checked but do the usual arithmetic operators still work if the polynomial has been preconditioned? I assume probably not, but if that's the case there should be a stern warning to that effect, *and* checks in code to prevent us from doing something stupid :-) BTW, preconditioning can be applied to polynomials of any degree I believe it's just that it gets hard to implement in the generic case. In addition I'd like to see the evaluation functions templated, so that the type being evaluated can differ from FieldType - it would surely be quite common for example to create and manipulate polynomials with integer coefficients, but then want to evaluate on a floating point type. There is machinery in Boost.Math BTW to handle the mixed argument-promotion and calculation of the result type, let me know if you need help in using this. * Special Forms: the functions provided do *not* generate polynomials in the alternative forms, but rather generate the named polynomial of order N, which is rather less useful, but at the very least the docs need updating to reflect this. * test_arithmetics.cpp fails on cygwin: or at least it did once I added a using std::pow; to start of operator*= to get things compiling. * None of the code builds with msvc: there are a couple of issues here: friend polynomial<FieldType> boost::math::tools::gcd<>(polynomial<FieldType> u, polynomial<FieldType> v); Needs to be changed to: friend polynomial<FieldType> boost::math::tools::gcd<FieldType>(polynomial<FieldType> u, polynomial<FieldType> v); to get msvc to Grok the code. After that there are a bunch of failures due to the use of log2 which msvc doesn't support (and since it's not part of the std other compilers are likely to complain too). * I haven't looked too hard at the implementation, except to echo the comments posted previously that the Conceptual requirements for FieldType need documenting and *testing*. There are concept checking classes and archetypes in Boost.Math which may be of use here. Again, shout if you need help in figuring out how to use these. I did notice that operator*= for example uses std::complex<double> internally which effectively limits the precision that can be achieved - to be useful to me - and to replace the existing "implementation detail" polynomial class in Boost.Math - I would need the polynomial class to be usable with arbitrary precision types such as NTL::RR or mpfr_class. Also as previously noted, multiplication of small polynomials may well be more efficient with the "naive" algorithm, so some performance tests and experimenting is required here. Related to this, use of "round" should be restricted to types that are known to be integers? Regards, John Maddock Review Manager for Polynomial Library.

2 1

why the output is different?
by Dongfei Yin 09 Apr '09

09 Apr '09

I write some code like this: #include <iostream> using namespace std; class Base1 { public: typedef Base1 base; void f() { cout<<"Base1::f()"<<endl; } }; class Base2 { typedef Base2 base; public: void f() { cout<<"Base2::f()"<<endl; } }; class A : public Base1 , public Base2 { public: A() { base::f(); } }; void main() { A a; } the output is : Base1::f() But if the definition of class A modified like this, class A : public Base2 , public Base1 { public: A() { base::f(); } }; the out will be: Base2::f() the output depends on the sequence of base class, that means the "typedef" in base class is unreliable. complier gives no warning. I try these code at both VS2005 and VS2008, the result are same.

2 1

[math] Help needed porting to AMD64/Linux platforms
by John Maddock 09 Apr '09

09 Apr '09

Folks, I'm still having trouble with some failures that appear to be specific to Linux on AMD64, if anyone with access to such a platform can help me out I'd be most grateful. You can test whether your machine exhibits the issue by: cd into libs/math/test and bjam gcc test_hypergeometric_dist1 If that fails, then I'm looking for the output from the following program to try and track down the cause of the error (caution this will be quite voluminous!): #define BOOST_MATH_INSTRUMENT #include "boost/math/distributions.hpp" int main() { double x = 30520, r = 130605, n = 130605, N = 523360, p = 1.315394088731268169855067478460234e-53, q = 1; boost::math::hypergeometric_distribution<> hyp(r, n, N); unsigned x_found = quantile(hyp, p); BOOST_MATH_INSTRUMENT_VARIABLE(x_found); return 0; } Perplexed yours, John.

3 5

[proto] _value doesn't enforce zero arity
by troy d. straszheim 09 Apr '09

09 Apr '09

I see some funny behavior when misusing _value: #include <boost/proto/proto.hpp> namespace bp = boost::proto; int main(int, char**) { bp::terminal<int>::type t = {0}; bp::terminal<int>::type hmm = bp::value(t * 2); bp::terminal<int>::type uhm = bp::_value()(t * 2); bp::terminal<const int&>::type hrm = bp::value(2 * t); bp::terminal<const int&>::type feh = bp::_value()(2 * t); } Which does compile.. but the docs say that _value requires an expression of zero arity. Here as usual is an attempt at a patch, to see if I'm learning anything: BOOST_MPL_ASSERT_RELATION( remove_reference<Expr>::type::proto_arity_c, ==, 0L); in the body of struct _value in transform/args.hpp. How'd I do? -t

6 16

[Testing] Sandia-tiger-x86 intel-darwin compiler crashes
by Emil Dotchevski 08 Apr '09

08 Apr '09

I'm wondering if someone with access to that compiler can help me diagnose the problem and/or submit compiler bug reports. Here are the tests that seem to crash the compiler: http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… This one has no log, but might not be a crash: http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

Patches in trac...
by Marshall Clow 08 Apr '09

08 Apr '09

At BoostCon last year, we had a discussion about the Trac system. One of the things that we discussed was the fact that the "Patches" tag in Trac was really a bad way to label things. Don't get me wrong - patches are a good thing. However, if a submitted patch fixes a problem, it should be categorized as a "bug report" with a fix attached. And if a patch adds new functionality, it should be categorized as a "feature request" with a proposed implementation attached. The conclusion that was reached at the end of the discussion was that we wanted to get rid of the "Patches" label for Trac tickets, and to move all the existing patches to either "Bugs" or "Feature Requests". I am proposing that this happen immediately after the release of version 1.39 - or immediately after BoostCon, say. What do people think? -- -- 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

Moving property map library into a directory
by Jeremiah Willcock 08 Apr '09

08 Apr '09

The Boost Property Map Library (property_map) currently consists of a number of files in the top-level boost/ include directory. It would probably be better to move all of them into a subdirectory, especially as Nick Edmonds and I will be adding new files and directories into that library soon. Should I do that move? I will update Boost.Graph; are there other libraries in Boost that use property_map? -- Jeremiah Willcock

4 4

Re: [boost] Compilation errors upgrading boost from 1.34 to 1.37 (Windows)
by tinkertom 08 Apr '09

08 Apr '09

I figured out what my problem was: When constructing a boost::mutex::scoped_lock in 1.33 the second parameter is a boolean. In 1.38, boost::mutex::scoped_lock (defined as unique_lock) constructor is overloaded using different types as the initial lock state instead of a single constructor with a boolean. In the constructor I now have to use adopt_lock_t, defer_lock_t, or try_to_lock_t as the second parameter. In 1.33: boost::mutex mtx; boost::mutex::scoped_lock lock(mtx, false); In 1.38 now looks like: boost::mutex mtx; boost::mutex::scoped_lock lock(mtx, defer_lock_t()); -Tom -- View this message in context: http://www.nabble.com/Compilation-errors-upgrading-boost-from-1.34-to-1.37-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0