- Boost - lists.boost.org

Re: [boost] [Math] acosh implementation
by John Maddock 08 Aug '08

08 Aug '08

Hubert Holin wrote: > Paris (U.E.), le 08/08/2008 > > Bonjour > > This not only looks just plain wrong, it *IS* just plain wrong... or > at the very least badly suboptimal. Sorry! To fix it (as it is > correctly in asinh.hpp), one has to add: > > static T const upper_taylor_n_bound = one/ > taylor_n_bound; > > and replace "else if (x >= taylor_n_bound)" by "else if (x >= > upper_taylor_n_bound)" at the line you point out. Hmm, isn't the final else clause for x near 1? So the check would be else if(x - 1 > taylor_n_bound) > The reason this has not been detected by the unit tests is rather > unfortunate: due to a very poor QOI of GCC on 64 bits ppc (my platform > of choice at the time), the unit tests are rather lenient, and only > compare the functions to test with (user platform) library provided > functions, instead of also comparing with hand-computed special > values. Perhaps is it now time to change this? Nod, how about adding some tests along the lines of the newer special functions where we test both random values (with results computed at high precision), and a few specific sanity-check values generated by functions.wolfram.com ? That way we can get a much better handle on the accuracy, and any potential problem area of these older functions. I can try and work up some tests in week or so if that would help, or can you handle this? Cheers, John.

1 0

Boost license now, finally, OSI approved
by David Abrahams 08 Aug '08

08 Aug '08

-- Dave Abrahams BoostPro Computing http://www.boostpro.com

6 6

[BGL] why not breakup put_get_helper into three structs?
by Mostafa 08 Aug '08

08 Aug '08

Hello, I posted this in gmane.comp.lib.boost.user and got no response, so I thought of reposting it here: Link: http://thread.gmane.org/gmane.comp.lib.boost.user/37318 Repost: Helllo, I was wondering why put_get_helper shouldn't be three structs (put_helper, get_helper, put_get_helper, with the latter deriving from from the formers) instead of one? My rationale is outlined below along with the proposed code. //Begin Rationale Problem: want a helper method for readable property maps. Solution1: use exist boost::put_get_helper and just never use the put function. Problem with solution 1: 1) the put function will still be "callable", and 2) calling the put function will result in an invalid assignment to a read-only variable compiler error, which is cryptic to decipher, ie, that even though the put function does exist it should not be called. The only way to clarify this would be via documentation, which then brings about the problem of keeping code in sync with comments. Solution2: make a helper method for readable property maps that won't make the put companion function a valid function call, ie, break up boost::put_get_helper to put_helper, get_helper, and put_get_helper which derives from the latter two. Problems with solution 2: None that I can see. Advantages of solution 2: 1) It's self-documenting whether the put or get functions are intended to be called, ie if I derive from get_helper then it's self-evident that I shouldn't be calling the put function (vice versa); and 2) given the above scenario, even if by chance the put function get's called the compiler error message will be easier to decipher, ie, something along the lines of: <no matching function for call to ‘put(...)'>. 3) Not really an advantage, but ... backward compatibility is maintained. //End Rationale. //Proposed code adapted from boost/property_map.hpp // A helper class for constructing a property map // from a class that implements operator[] template <class RetVal, class RvaluePropertyMap> struct get_helper { }; template <class LvaluePropertyMap> struct put_helper { }; template <class RetVal, class LvaluePropertyMap> struct put_get_helper : public put_helper<LvaluePropertyMap>, public get_helper<RetVal, LvaluePropertyMap> { }; template <class PropertyMap, class RetVal, class K> inline RetVal get( get_helper<RetVal, PropertyMap> const & pa, K const & k) { RetVal v = static_cast<const PropertyMap&>(pa)[k]; return v; } template <class PropertyMap, class K, class V> inline void put( put_helper<PropertyMap> const & pa, K k, V const & v) { static_cast<const PropertyMap&>(pa)[k] = v; } Thanks in advance, -Mostafa

4 7

Library proposal: box
by Chris Jefferson 07 Aug '08

07 Aug '08

I wish to seek interest in generalising, extending and documenting a simple but useful library I use personally. 'box' is a simple class which provides an almost standard C++ container on top of a pre-allocated block of memory or range of iterators. For raw memory this container is a perfect implementation of vector, except for the constructors. It is possible for the underlying objects to be already constructed, or have the container handle construction and destruction. Simple usages: box<int> b1(malloc(sizeof(int) * 10), 10); // makes an empty container of size 10. assert(b1.size() = 0); assert(b1.max_size() == 10); b1.resize(10, 1); // Fills the container with 1s. b1.push_back(1); // throws std::length_error box<int> b2(alloca(sizeof(int) * 10), 10); // makes an empty container on the stack of size 10. void get_things(b2); // passing 'alloca'ed boxes to functions avoid heap allocation. A number of macros exist for automating the creation of containers with 'alloca'ed memory. Further, a simple alternative implementation of alloca which uses a parallel stack is provided. Common use cases: 1) Use 'alloca'ed memory to make a container on the stack. 2) In general allow the use of C++ container idioms (push_back, resize) while maintaining fully controlled, clear memory management. Design decisions: 1) Box has no copy constructor or assignment, and will have no move constructor either, as it seems difficult to give any definition without too many 'gotchas'. 2) Box does not attempt to implement complex memory management, 3) In general box aims to be as simple as possible, sticking with fixed size containers and no container copying. Possible Qs (with I hope correct answers) Q) Why is this not just boost::range? A) The container starts empty, and can be inserted into. Q) Why not implement this as an allocator to give to vector/list? A) Allocators are a complex and often misunderstood type, and it is not felt it makes things easier for users to give a different allocator to vector as opposed to defining a new class. In particular, getting correct behaviour for the copy constructors of the container is difficult, and it is not possible to give a correct definition of max_size, which is more important for small-sized containers. Current state: box is currently in usage in a number of projects, based on a heavily-hacked SGI vector implementation. As a library the code would probably be rewritten, and also of course carefully documented. Chris

4 6

Re: [boost] [1.36][ublas] VC8/SP1 with ADL problem?
by joel falcou 07 Aug '08

07 Aug '08

Le Jeu 7 août 2008 20:33, Thomas Klimpel a écrit : > I'm no expert on ADL, so I have no idea whether VC8 is allowed to fail > here. VC8 seems to fail as soon as I define any template function named > sqrt inside the boost or boost::numeric namespace. I have no idea how to > work around that. Perhaps I should investigate why "#define NDEBUG" works > around the problem. did you try #undef sqrt after including any headers like cmath or windows.h ? I had a similar problem with min/max and log2 for a while.

1 0

Re: [boost] [1.36][ublas] VC8/SP1 with ADL problem?
by joel falcou 07 Aug '08

07 Aug '08

Le Jeu 7 août 2008 20:33, Thomas Klimpel a écrit : > I'm no expert on ADL, so I have no idea whether VC8 is allowed to fail > here. VC8 seems to fail as soon as I define any template function named > sqrt inside the boost or boost::numeric namespace. I have no idea how to > work around that. Perhaps I should investigate why "#define NDEBUG" works > around the problem. did you try #undef sqrt after including any headers like cmath or windows.h ? I had a similar problem with min/max and log2 for a while.

1 0

Re: [boost] out of date release results?
by Eric Niebler 07 Aug '08

07 Aug '08

Beman Dawes wrote: >> Rene Rivera wrote: >>> Eric Niebler wrote: >>>> >>>> Oh whoa. Something really strange is going on with these pages. >>>> >>>> These results are old: >>>> http://www.boost.org/development/tests/release/developer/accumulators_relea… >>>> >>>> These results are new: >>>> http://www.boost.org/development/tests/release/developer/accumulators.html >>>> >>>> I can reach either page via different sequences of clicks. At first >>>> I thought that maybe one page represents results from 1.35, but >>>> that's not possible because accumulators wasn't in 1.35. >>>> >>>> What's going on? >>> >>> This sounds like the release view of the results is not getting >>> generated, on Beman's machine, and it's using some old set of >>> results. Hence only the developer view has the current results. > > No idea. That machine just runs the script from the web site; I haven't > done any customization, and haven't changed either hardware or software > setup in ages. Whatever the problem is, we need to sort this out now. It's not ok to be publishing stale tests results. Rene, thoughts? Can we just nuke the old test results? -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[Math] acosh implementation
by Szymon Modzelewski 07 Aug '08

07 Aug '08

http://svn.boost.org/svn/boost/trunk/boost/math/special_functions/acosh.hpp goes like this: static T const taylor_2_bound = sqrt(tools::epsilon<T>()); // this is way smaller than 1 static T const taylor_n_bound = sqrt(taylor_2_bound); static T const upper_taylor_2_bound = one/taylor_2_bound; if(x < one) // right { return policies::raise_domain_error<T>( "boost::math::acosh<%1%>(%1%)", "acosh requires x >= 1, but got x = %1%.", x, pol); } else if (x >= taylor_n_bound) // what? { ... } else { // so when do we actually get here? ... }

2 1

[Range] Review scheduled?
by Robert Jones 07 Aug '08

07 Aug '08

I see from the review schedule page that "Boost Range (update)" has been submitted for review. Is this the range_ex project from the sandbox? The link to the vault is broken on the schedule page. Also, what exactly is the vault? I'm unclear of its relationship to the sandbox. Thanks, - Rob. -- ACCU - Professionalism in programming - http://www.accu.org

1 0

Re: [boost] [Boost-users] boost on apple gcc 4.2
by Ryo IGARASHI 07 Aug '08

07 Aug '08

Hi, On Fri, Aug 1, 2008 at 2:50 AM, Mat Marcus <mat-lists(a)emarcus.org> wrote: >>> I then conclude that the C++ ABI is fully compatible between 4.0 and >>> 4.2 >> >> Right. > > [snip, then user hypothesizes as to why there are problems with boost > under gcc 4.2/libstdc++ 4.0 on current Apple systems] > >>> This is the case because boost assumes that a 4.2 compiler implies >>> 4.2 libraries in flies such as boost/detail/atomic_count_gcc.hpp: >>> >>> #if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) >>> # include <ext/atomicity.h> >>> #else >>> # include <bits/atomicity.h> >>> #endif >> >> Yes, this is a bug or faulty assumption in boost. > > [snip] > >> The 4.2 library issue is a bug in Boost, not a problem with >> our compiler. I'd suggest raising the issue on one of the boost >> mailing lists and see what they say. > > Comments? > Mat >From Debian GNU/Linux ABI transition history, I found that gcc 3.0, 3.1, 3.2, 3.3 have C++ ABI compatibility (libstdc++5) and gcc > 3.4 also have C++ ABI compatibility (libstdc++6). (Of cource this may not apply on other OSs.) Note that gcc major version don't jump simultaneously with C++ ABI update. Regards, -- Ryo IGARASHI rigarash(a)gmail.com

1 0