August 2014 - Boost - lists.boost.org

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

Boost Hana comments
by Jeremy Maitin-Shepard 21 Aug '14

21 Aug '14

First off, while I haven't thoroughly reviewed the library, I am certainly impressed by a lot of what I see. It is obvious that this library represents a lot of excellent work. Here are my miscellaneous comments: Constant type class: -------------------- Why isn't std::integral_constant an instance? There is no documentation of what the value method actually returns, just that it returns something that is a constexpr. Does value(integral<int,3>)) return int, or does it return integral<int,3> ? Perhaps the Constant type class should be "parameterized" by a type specifying the return type of value. Integral data type: ------------------- It would be better not to duplicate std::integral_constant. However, I recognize that the overloaded operators are useful and you wouldn't be able to do this with std::integral_constant (well, I suppose you still could, but as they wouldn't be found by ADL, they wouldn't be terribly useful). This rationale (assuming it is correct) should be documented though. Logical type class: ------------------- What is really gained by making this a type class at all? It seems that and_ and or_ require that all arguments be of the same "hana datatype", though actually this isn't documented anywhere and this might not even be the precise requirement (but obviously it needs to be documented very explicitly, and this probably applies to almost every method in Hana). Really we really should be able to mix multiple data types in a call to or_ or and_, though. Otherwise the usability is unreasonably limited. Of course there is then the question of return type. However, I would assume most users would be happy getting back either a Hana Integral or a bool, depending on whether it is a compile-time or runtime condition. Certainly this would be better than getting back a compiler error. Another question: how does the performance of and_ and or_ compare to the optimized verions you showed in your MPL11 talk? Pair datatype: -------------- Why duplicate std::pair? Alternatively, why duplicate list? Perhaps list should just define first and second as well? Product type class: ---------------- Why isn't a 2-element List, a 2-element std::tuple, etc. an instance? List type class: ---------------- Just as for Logical, it would be useful to be able to mix datatypes in calls to concat, zip, zip_with. The list function itself shouldn't be documented as part of the type class, since it isn't logically part of it. What about get<N>, get<N,M> accessors? I understand these can be defined in terms of the other methods, but clearly they are useful on their own.

3 4

[Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
by Mostafa 21 Aug '14

21 Aug '14

On Thu, 31 Jul 2014 10:54:59 -0700, Robert Ramey <ramey(a)rrsd.com> wrote: > Eric Niebler-4 wrote >> On 07/29/2014 05:14 PM, Niall Douglas wrote: >>> I'm all for Concepts as in compiler enforced ones, and I'll add them >>> to AFIO when and only when C++ gets them. But for documentation they >>> don't help. >> >> Wow, I couldn't disagree more. I can't imagine how the standard >> algorithms would be specified without the use of concepts like >> "RandomAccessIterator", for instance. Clustering requirements into >> meaningful abstractions and assigning them names makes it possible to >> document library interfaces without an explosion of verbosity and >> repetition. > > +10 > > Usage of concepts is greatly: > > a) misunderstood > b) misunderestimated as to their value in design AND documentation > d) The word "concepts" is a big contributor to the problem - substitute > "type requirements" or "type constraints" for concepts. -1 to the above term substitutions for concepts. Type requirements/type constrains are not concepts. The reason concepts are misunderstood is because they have not been well defined. FWIW, here's my take on how they should be defined: Concepts are sets of types whose membership are compile-time determinable. Precisely, a concept is any set expressible in the following form: { T | T is a type and p(T ...) } where p is a (n+1)-ary compile time computable boolean function (a function in the mathematical sense, not an actual C++ function). p is said to be (or to express) the type requirements or type constrains for its associated concept. (Note: just as a set membership predicate is not its set, a type requirement is not its concept. For example, the predicate "there exists a,b and a,b are integers and b != 0 and c = a/b" does not denote the set of rational numbers, the symbol Q does.) A type T is said to model a concept C if T is a member of C. In such a case we also say that "T is a C". A concept B is said to be a refinement of a concept A if B is a subset of A. Why use concepts? Because they are helpful in documenting generic code, especially template type parameter requirements. Examples: 1) DefaultConstructible := { T | T has the method "T()" defined and accessible. } // Requirements: // T is DefaultConstructible. template <typename T> struct FooBar { ... }; std::tuple<int> is DefaultConstructible, therefore FooBar< std::tuple<int> > is well formed. Mostafa

14 57

[Container] Provide more guarantees for flat_multimap
by Vinícius dos Santos Oliveira 21 Aug '14

21 Aug '14

Currently, flat_multimap mirrors C++98's multimap concept. I'd like to propose an update to flat_multimap fulfil the C++11's multimap concept. The part I'm particularly interested are guarantees about preserving the insertion ordering for elements with equivalent keys. On ISO/IEC 14882-2011, 23.2.4 - associative container requirements, pages 741 and 742, you can see the effects for a_eq.emplace and a_eq.insert ends with "If a range containing elements equivalent to t exists in a_eq, t is inserted at the end of that range". I see no similar guarantees on the Boost's flat_multimap documentation[1]. This feature is useful, for instance, in HTTP messages, where field reordering is illegal[2] if the keys are equivalent. I did a few tests and it looks to me that flat_multimap already provides these guarantees, but before I go check the source and possibly provide patches, I need to know if there is interest in turning this accidental behaviour into intentional behaviour through documented guarantees. [1] http://www.boost.org/doc/libs/1_56_0/doc/html/boost/container/flat_multimap… [2] http://tools.ietf.org/html/rfc7230#section-3.2.2 -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

7 17

Metadata pull requests
by Daniel James 21 Aug '14

21 Aug '14

Hi, I just created about 100 pull requests to add library metadata to modules that don't already have it. Apart from them all containing the same typo, I think it went okay. I forgot to mention that the file format is documented at: http://www.boost.org/development/library_metadata.html I'll spend a bit of time improving that soon, so let me know if there's anything missing. Also, if it wasn't clear, the idea is that you can update this file if you need to change the library details. It might take a little while for the website to update, as it only happens when I run the appropriate script. thanks, Daniel

5 11