- Boost - lists.boost.org

[math] pull request for boost::math::round bug in corner cases
by Robin Eckert 24 Aug '14

24 Aug '14

Hello, I found two corner cases in which boost::math::round doesn't round correctly. For double types, these are the numbers directly beneath 0.5: +/- 0.499999999999999944488848768742172978818416595458984375 (which get rounded to 1.0 although their aboslute value is smaller than 0.59) and odd integral numbers on the edge of the mantissa length: +/- 4503599627370497.0 +/- 4503599627370499.0 +/- 4503599627370501.0 ... +/- 9007199254740989.0 +/- 9007199254740991.0 +/- 9007199254740993.0 These get rounded to the next bigger/smaller integral value. For a detailed explanation and a fix, see the description of the pull request on https://github.com/boostorg/math/pull/8 Regards, Robin

1 0

[test] Using BOOST_CHECK_EQUAL with enum
by Edward Diener 23 Aug '14

23 Aug '14

In code I have the expression: BOOST_CHECK_EQUAL(cnew,e_test_third); where 'cnew' is: test_enum cnew; and test_enum is: enum test_enum { e_test_default, e_test_first, e_test_second, e_test_third }; This is giving me the error: ..\..\../boost/test/test_tools.hpp:100:1: error: expected ')' before 'do' do { \ ^ ..\..\../boost/test/test_tools.hpp:169:5: note: in expansion of macro 'BOOST_CHECK_WITH_ARGS_IMPL' BOOST_CHECK_WITH_ARGS_IMPL( ::boost::test_tools::tt_detail::equal_impl_frwd(), "", CHECK, CHECK_EQUAL, (L)(R) ) ^ test_auto_value.cpp:64:4: note: in expansion of macro 'BOOST_CHECK_EQUAL' BOOST_CHECK_EQUAL(cnew,e_test_third); ^ Is Boost Test incapable of checking that an enumeration object equals an enumerated value ? Is this a known problem ? How do I work around it ?

1 1

[iterator] Merge pull request
by Andrey Semashev 23 Aug '14

23 Aug '14

Hi, Some time ago I made this pull request: https://github.com/boostorg/iterator/pull/6 It makes some of the implementation details of Boost.Iterator public. These components are already used in Boost.Range and Boost.Tokenizer and the intent is to further patch these libs to use public interfaces instead of the implementation details. Could this pull request be merged?

2 6

[filesystem] Epoch of trivial_clock
by Bjorn Reese 23 Aug '14

23 Aug '14

The filesystem::trivial_clock type is implementation-defined [1]. That means that the epoch is also implementation-defined. How do we determine the epoch of trivial_clock? For instance, we may need to represent the last_write_time() timestamp to the end-user, or transfer it to another node when we implement a network file system. PS: I am looking at the std::filesystem proposal, but I assume that boost::filesystem will be update accordingly. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4097.html#8

5 7

GSOC: Boost.Math: hypergeometric functions
by Anton Bikineev 22 Aug '14

22 Aug '14

Hi all, I'm glad to represent my GSoC project work about implementation of hypergeometric functions: https://github.com/BoostGSoC14/boost.math I would like to thank everybody who helped me, essentially my mentor Christopher Kormanyos, my advisors John Maddock, Paul Bristow and, of course, Niall Douglas. The concentration of the project was mostly confluent hypergeometric function 1f1. Some essential algorithms were implemented and research works were done. A few short articles may be read in my blog: http://antoha-bikineev.blogspot.com Of course, it's gonna be updated while researching. The most important thing for me is that this work opened new ideas, ways and approaches for development and investigation of new numerical algorithms. Some of them are intended to reduce probability of cancellation errors in power series and to reduce round-off errors for recurrence relations at unstable directions. So there are plenty of stuff to do and improve.

1 0

[graph] Faster strong_components-implementation
by Alexander Lauser 22 Aug '14

22 Aug '14

Hi all, reimplementing Tarjan's dfs-visitor used in Boost.Graph's algorithm to compute strong components yielded a performance gain of about 15 to 20% (for adjacency_list-graphs). The problem is that due to bug #10231 [1], this implementation does not work with a current vanilla version of Boost. (See below for some details explaining my changes and the reason it is affected by the bug.) Is there interest in the faster implementation? If so, what's the best way to proceed? Wait until the bug is fixed and then incorporate the changes in a pull request? Create a pull request and hope that is not merged before the bug is fixed? Btw, my feeling is that the bug's not too involved and I tried to fix it myself. It seems that it is not even in Boost.Graph itself, but in Boost.TTI (in the macro-depths of which I got lost). Should I file a separate bug for Boost.TTI? For the details: My implementation is a back-to-the-root-approach, following the classical formulations of Tarjan's algorithm more closely. The current implementation somewhat "simulates" edge events upon leaving a vertex by an additional loop over all edges incident to the vertex. This can be avoided by using finish_edge -- which suffers from the above mentioned bug. (In addition to the performance-boost, I think it is also more natural to implement Tarjan's algorithm using finish_edge.) Cheers, Alex [1] https://svn.boost.org/trac/boost/ticket/10231

1 0

ISO C++14 passes final ballot
by Beman Dawes 21 Aug '14

21 Aug '14

All 18 countries voting voted "yes". See http://isocpp.org/blog/2014/08/we-have-cpp14

7 7

[container] variadic template support in g++ 4.5.1
by Richard Hadsell 21 Aug '14

21 Aug '14

I am trying to compile some of our code with Boost 1.56.0 on a Linux (Fedora 14) platform with this compiler: gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) I apologize for using this ancient version of g++, but we're stuck with it for a while longer. I get this error message: In file included from .../boost/circular_buffer/details.hpp:19:0, from .../boost/circular_buffer.hpp:56, from ...: /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp: In static member function 'static void boost::container::allocator_traits<Alloc>::priv_construct(boost::false_type, Alloc&, T*, const Args& ...)': /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:324:43: sorry, unimplemented: cannot expand 'Args ...' into a fixed-length argument list /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:325:51: error: 'value' is not a valid template argument for type 'bool' because it is a non-constant expression /netDISKS/master/netmt/LINUX_INTF14/cgi/boost/1.56.0/Include/libboost/boost/container/allocator_traits.hpp:325:57: error: invalid type in declaration before ';' token Line 324 is in a block guarded by: #if !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) config/compiler/gcc.hpp defines BOOST_NO_CXX11_VARIADIC_TEMPLATES for g++ earlier than 4.4, which means it believes the code should be valid for 4.5.1. Is there already a fix for this in development? Please, tell me what to do with my copy of 1.56.0. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 4

intrusive_ptr wrapper for C++/CLI
by Stephen Channell 21 Aug '14

21 Aug '14

I do a lot of development using native C++ and managed C++/CLI, and have coded a simple smart pointer wrapper around intrusive_ptr to allow C++/CLI code to use reference counting objects without change. IntrusivePtr takes advantage of the template support engineered for gcroot<T> to implement the smart pointer. It’s a wrapper to support factory functions that return intrusive_ptr. Whilst many would object to putting C++/CLI conditional code into boost, the smart pointer is too small to stand alone and too boost specific for Microsoft. thoughts welcome https://ql.codeplex.com/SourceControl/latest#IntrusivePtr/boost/IntrusivePt…

3 3

Re: [boost] [units] Pull request and RFC: information unit definitions for Boost.Units
by Curdeius Curdeius 21 Aug '14

21 Aug '14

Hi all, From: Jürgen Hunold <jhunold(a)gmx.eu> > > > I'd like to have a definite response on "go/no go" for maintainership > > > before I invest some of my scarce time on this. > > > > Go for it. > > Thanks a lot. > > Done. See https://github.com/boostorg/admin/issues/83 for my request. > > Please bear with me as I want to check the current repository state first. > The > plan is to tackle the simple pull requests afterwards and then come back to > the features. > > Yours, > > Jürgen > Firstly, congratulations Jürgen! Secondly, a few days ago I have proposed myself to be a co-maintainer together with Jürgen (see the cite below), but have still no answer from the community. At least Jürgen is not against. So, I ask for a green light from the community to co-maintain Boost.Units. Hi all, > I considered proposing myself as a maintainer of Boost.Units for some > time, but considered too inexperienced to do it on my own. > Therefore I am happy that Jürgen proposed himself and I would like to help > him by being a co-maintainer if it is possible and needed. > As for me, I have been using the library for at least 3 years now and > would like to contribute to it. > For the moment, I mainly proposed small bug fixes to Boost libraries. > Regards, > Marek Kurdej > -- > Ph.D. candidate Best regards, Marek Kurdej -- Ph.D. candidate

3 2