October 2013 - Boost-users - lists.preview.boost.org

[Voronoi] Trying to figure out proper direction of semi-infinite edges.
by Nicolay P 18 Oct '13

18 Oct '13

Hi, Trying to figure out how to use the Voronoi library in 1.54 Boost (Great stuff BTW, Thanks!) I am using the library to shatter a 2d convex polygon. So I need to generate polygons that are the results of clipping a voronoi cell against my convex poly. I am having hard time figuring out how to properly identify the direction of the semi-infinite edge. I know i can obtain the general direction of the infinite edge from the participating cell points, but I am not clear on how to distinguish between two possible directions in the semi-finite case. Any help would be much appreciated! Thanks! Nick.

1 0

Boost_1_54_0: boost::math::sph_bessel(n, x) crash at x=0 n>0
by JE Campagne 18 Oct '13

18 Oct '13

Dear developpers, I'am running Boost 1_54_0 on Scientific Linux slc-6.1, gcc-4.4.5, 64 bits machine. I face a problem with computation of spherical bessel function, although the problem seems well known here is a test program { int L; try { for(L=100;L<2010;L++) { boost::math::sph_bessel(L, 0.); } } catch (std::exception& sex) { cout << "Error j_"<<L<<"(0): "<< sex.what() << endl; } } And the output Error j_1755(0): Error in function boost::math::tgamma<e>(e): Result of tgamma is too large to represent. which tends to point out that at L=1755 the spherical bessel function get a problem once one ant to estimate at x=0. Of course, I know that j0(0) = 1 and for L>0 jL(0) = 0 but 1) I'm using a program which compute integral of product of bessel function and sometimes it needs to call the function at 0. So I would expect the BOOST library to be protected against that. Am I wrong? Best regards Jean-Eric

3 6

zlib question
by Robert Ramey 18 Oct '13

18 Oct '13

I'm using boost 1.55 - current release branch and now I want to link with libboost_zlib-vc90-mt-sgd-1_55.lib - but of course I don't have this. What is the most expedient way to address this? Robert Ramey

2 2

How to use multi index container?
by yuan 18 Oct '13

18 Oct '13

Hi, I try to use multi index container.I have one problem.Please help me.Thanks struct TOrder { char szDate[9]; //date type int nID; // order id int nProductID; //product id double fPrice;// int nVol;// //other member … } // The unique key of TOrder struct is szDdate and nID. How I can typedef the composite_key and the multi_index_container? Thank you for your help. Best regards. Yuan

2 1

Getting introduced to boost Python world, struck at hello_ext.pyd generation
by Raghu Kalyan Anna 18 Oct '13

18 Oct '13

Hi, Started to explore boost.Python to use C++ classes (.so or .dll) from Python world. I did these, (Windows) downloaded boost 1.54 and unpacked to C:\boost_1_54, Python 3.3 (earlier tried with Python 2.7) installed visuall C++ 2010 Express free edition From Visual studio command prompt, tested example.cpp and got the result. Now struck in getting hellp.cpp and to generate hello_ext.pyd. Looked at posts in stackoverflow and tried similar steps. Still the same. After unpacking boost1.54, I tried these <boost root> C:\boost_1_54>bootstrap.bat C:\boost_1_54>b2 Now it said add C:\boost_1_54 to compiler include path and add c:\boost_1_54\stage\lib to linker paths. Added these two paths to %PATH% environment variable thru advanced settings. Now ran bjam from hello tutorial C:\boost_1_54\libs\python\example\tutorial>bjam hello_ext.pyd is not generated And noted this "LINK : fatal error LNK1104: cannot open file 'boost_python-vc100-mt-gd-1_54.lib' call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.b at" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86 /MANIFEST /subsystem:conso le /out:"bin\msvc-10.0\debug\hello_ext.pyd" /IMPLIB:"bin\msvc-10.0\debug\hello_e xt.lib" /LIBPATH:"C:\Python33\libs" @"bin\msvc-10.0\debug\hello_ext.pyd.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link.dll bin\msvc-10.0\debug\hello_ext.pyd bin\msvc-10.0\debug\he llo_ext.lib bin\msvc-10.0\debug\hello_ext.pdb bin\msvc-10.0\debug\hello_ext.pdb. .. common.copy boost_python-vc100-gd-1_54.dll ..\..\..\..\bin.v2\libs\python\build\msvc-10.0\debug\boost_python-vc100-gd-1_54. dll 1 file(s) copied. ...skipped <p.>hello_ext.pyd for lack of <pbin\msvc-10.0\debug>hello_ext.pyd... common.mkdir bin\hello.test common.mkdir bin\hello.test\msvc-10.0 common.mkdir bin\hello.test\msvc-10.0\debug ...failed updating 3 targets... ...skipped 1 target... ...updated 41 targets..." If this is basic question, please answer. Or else please direct to appropriate Boost mailing list -- Regards, Ram **

1 0

Re: [Boost-users] Boost_1_54_0: boost::math::sph_bessel(n, x) crash at x=0 n>0
by campagne 17 Oct '13

17 Oct '13

Thanks That's true that for x close to zero but positive there are also problems to the use of power series close to 0 is certainly the best thing to do. I am astonished that this not yet used. Jean Eric Envoyé depuis un mobile Samsung -------- Message d'origine -------- De : John Maddock <john(a)johnmaddock.co.uk> Date : A : boost-users(a)lists.boost.org Objet : Re: [Boost-users] Boost_1_54_0: boost::math::sph_bessel(n, x) crash at x=0 n>0 > I'am running Boost 1_54_0 on Scientific Linux slc-6.1, gcc-4.4.5, 64 > bits machine. > > I face a problem with computation of spherical bessel function, although > the problem seems well known here > is a test program Not well known to me - there are a number of fixes to the (cyclic) Bessel functions due out with 1.55, but I'm afraid this isn't one of them. BTW the issue effects all x < 1, not just x == 0. Here's the patch I'm about to commit to SVN: Index: boost/math/special_functions/bessel.hpp =================================================================== --- boost/math/special_functions/bessel.hpp (revision 86329) +++ boost/math/special_functions/bessel.hpp (working copy) @@ -48,7 +48,16 @@ { BOOST_MATH_STD_USING mult = x / 2; - term = pow(mult, T(v)) / boost::math::tgamma(v+1+T(0.5f), Policy()); + if(v + 3 > max_factorial<T>::value) + { + // term = v * log(mult) - boost::math::lgamma(v+1+T(0.5f), Policy()); + // term = exp(term); + // Denominator increases faster than numerator each time v increases by one, + // so if tgamma would overflow then the result is neceesarily zero. + term = 0; + } + else + term = pow(mult, T(v)) / boost::math::tgamma(v+1+T(0.5f), Policy()); mult *= -mult; } T operator()() @@ -142,6 +151,11 @@ if(n == 0) return boost::math::sinc_pi(x, pol); // + // Special case for x == 0: + // + if(x == 0) + return 0; + // // When x is small we may end up with 0/0, use series evaluation // instead, especially as it converges rapidly: // Index: libs/math/test/test_bessel_j.hpp =================================================================== --- libs/math/test/test_bessel_j.hpp (revision 86329) +++ libs/math/test/test_bessel_j.hpp (working copy) @@ -262,6 +262,13 @@ do_test_sph_bessel_j<T>(sph_bessel_data, name, "Bessel j: Random Data"); // + // Some special cases: + // + BOOST_CHECK_EQUAL(boost::math::sph_bessel(0, T(0)), T(1)); + BOOST_CHECK_EQUAL(boost::math::sph_bessel(1, T(0)), T(0)); + BOOST_CHECK_EQUAL(boost::math::sph_bessel(100000, T(0)), T(0)); + + // // Special cases that are errors: // BOOST_CHECK_THROW(boost::math::cyl_bessel_j(T(-2.5), T(0)), std::domain_error); HTH, John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[serialization] customizing save/load for a type (pointer)
by Mathieu Champlon 17 Oct '13

17 Oct '13

Hi, I'm using Boost.Serialization on a project where part of the data is not serialized and then loaded separately when unserializing. For instance a class MyThing can have a member data MyThingData* which described some "static" data. There is an application which edits these data and saves them on file for the main application to use latter on. When serializing MyThing we customize save/load in order to serialize MyThingData as a UID (MyThingData has a GetId member function). Upon unserialization the proper MyThingData instance is searched for based on the UID read from the archive. This works OK but is a bit tedious because with class MyThing { ... MyThingData* data_; }; instead of simply doing template< typename Archive > void serialize( Archive& ar, const unsigned int ) { ar & data_; } we have to do something like BOOST_SERIALIZATION_SPLIT_MEMBER() template< typename Archive > void load( Archive& ar, const unsigned int ) { int id; ar >> id; data_ = FindData( id ); // not very important how it is actually retrieved } template< typename Archive > void save( Archive& ar, const unsigned int ) const { ar << data_->GetId(); } Moreover things get even more complicated when serializing for instance a std::vector< MyThingData* > ... So I'm looking for a way to customize the serialization of MyThingData*. Of course I could wrap MyThingData* in a simple object to encapsulate save/load but they're everywhere and the code base is quite massive so this would require a lot of changes. Any idea how I could achieve this ? Thank you ! Regards, MAT.

1 0

bug in boost::date_time::time_facet?
by Jakub Zytka 16 Oct '13

16 Oct '13

Hi all I've run into a problem with *_facet from boost::date_time when compiling for windows and I'm pretty convinced it is a bug in boost (tested 1.49 and 1.54). However, since gcc makes a successful attempt not to trigger it, and I'm not exactly an expert on windows formats/linkers/etc I'd like to have second opinion before I fill a ticket. So, here we go: Consider following code: ------------- setFacet.h -------------------------- #include <iostream> __declspec(dllexport) void setFacet(std::ostream &); -------------- setFacet.cpp ----------------------- #include <boost/date_time/posix_time/posix_time.hpp> #include <locale> #include "setFacet.h" __declspec(dllexport) void setFacet(std::ostream & os) { boost::posix_time::time_facet * dateFormat =new boost::posix_time::time_facet("%Y-%m"); os.imbue(std::locale(os.getloc(), dateFormat)); } ------------------- test.cpp -------------------------- #include <boost/date_time/posix_time/posix_time.hpp> #include <iostream> #include "setFacet.h" using namespace std; int main() { std::string ts("20020131T235959"); boost::posix_time::ptime t(boost::posix_time::from_iso_string(ts)); cerr << t << endl; setFacet(cerr); cerr << t << endl; return 0; } ------------------------------------------------------- The expected result is that facet with "%Y-%m" format is imbued to cerr after calling "setFacet" function and that second print uses specified format. Now, suppose we built it so that we have setFacet.dll exporting function setFacet, and test.exe is linked against this dll. In such setting the code works under linux (gcc 4.1, 4.7), but it doesn't work under mingw-w64 4.6.4 or msvc10 - default format is used both times: linux: 2002-Jan-31 23:59:59 2002-01 windows: 2002-Jan-31 23:59:59 2002-Jan-31 23:59:59 Why? Well, lets look at operator<< for ptime. It does one interesting comparison: if (std::has_facet<custom_ptime_facet>(os.getloc())) this comparison gives different results under linux and windows. The key is static member "id" of a facet class. It is declared in boost/date_time/time_facet.hpp and it is used by has_facet to give answer whether locale has facet for the given class. Since this header is included twice - once in dll and once in exe there are two storages for id of the same facet class. In gcc 4.1 appropriate symbols are weak objects. Apparently only one is selected as the proper one by the linker and used universally. In gcc 4.7 it is even better. Appropriate symbols are "unique global symbol" which explicitly means there should be only one instance in whole process. In mingw both these storages are used independently and the same class (boost::posix_time::time_facet) has different id in dll (in setFacet function) and different in exe file (in operator<<). This is why operator<< believes locale has no facet for posix_time. At this point I was suspecting some incompatibility between windows' linker and mingw's libstdc++ implementation (regarding std::locale::id initialization) However, under msvc10 it doesn't work either, with msvc library. I believe it is a bug in boost, even if some deficiency in mingw/msvc/windows is involved. Also, let me confess I'm far from having learned boost docs by heart. If there is some big red sign somewhere telling I must link statically if using facets from boost::date_time have mercy on me. command lines used to build example: gcc (just get rid of these dllspecs): g++ -fPIC -shared -o libsetFacet.so setFacet.cpp g++ -L. -lsetFacet -Wl,--rpath=. -o test test.cpp mingw: x86_64-w64-mingw32-g++ -isystem pathToBoostIncludes -shared -o libsetFacet.dll -m32 -Wl,--enable-runtime-pseudo-reloc-v2 -Wl,--out-implib,libsetFacet.lib setFacet.cpp x86_64-w64-mingw32-g++ pathToBoostIncludes -o test.exe -m32 -Wl,--enable-runtime-pseudo-reloc-v2 -L. -lsetFacet test.cpp msvc10: cl.exe /I"pathToBoostIncludes" /LD set.cpp /EHsc /link /out:setFacet.dll /LIBPATH:"pathToBoostLibs" cl.exe /I"pathToBoostIncludes" /EHsc setFacet.lib test.cpp /link /LIBPATH:"pathToBoostLibs" regards, Jakub Zytka

1 0

Can't get boost version 1.54.0 to compile (Debian Linux)
by Ban Hammer 16 Oct '13

16 Oct '13

Hello. I'm quite new, and I've been needing Boost for something else I'm trying to compile... I've been trying to compile Boost, but it's giving me errors. Unfortunately, I can't use Debian's apt-get to get Boost, because I need version 1.5 or greater, and apt-get (for this version of Debian) only gets 1.49.0. I've put some feedback it gave me below. I've already run ./b2 (no arguments) before, so that's where the found targets are coming from. I'm not sure why I'm getting these errors...A whole bunch of header files are reported missing. I tried re-downloading Boost, and using a different format (tar.bz2 instead of tar.bz), but it still does the same thing. Building the Boost C++ Libraries. Performing configuration checks - 32-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) error: No best alternative for libs/coroutine/build/allocator_sources next alternative: required properties: <link>static <target-os>windows <threading>multi not matched next alternative: required properties: <link>static <segmented-stacks>on <threading>multi not matched next alternative: required properties: <link>static <threading>multi not matched - has_icu builds : yes (cached) warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes (cached) - iconv (libc) : yes (cached) - icu : yes (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : yes (cached) - long double support : yes (cached) warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : yes (cached) Component configuration: (All are building) ...patience... ...patience... ...patience... ...patience... ...patience... ...found 11439 targets... ...updating 70 targets... gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.7/release/threading-multi/bzip2.o libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory compilation terminated. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.7/release/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp" ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.7/release/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.7/release/threading-multi>libboost_iostreams.so.1.54.0 for lack of <pbin.v2/libs/iostreams/build/gcc-4.7/release/threading-multi>bzip2.o... ...skipped <pstage/lib>libboost_iostreams.so.1.54.0 for lack of <pbin.v2/libs/iostreams/build/gcc-4.7/release/threading-multi>libboost_iostreams.so.1.54.0... ...skipped <pstage/lib>libboost_iostreams.so for lack of <pstage/lib>libboost_iostreams.so.1.54.0... gcc.compile.c++ bin.v2/libs/python/build/gcc-4.7/release/threading-multi/numeric.o In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/numeric.hpp:8, from libs/python/src/numeric.cpp:6: ./boost/python/detail/wrap_python.hpp:75:24: fatal error: patchlevel.h: No such file or directory compilation terminated. ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.7/release/link-static/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.7/release/link-static/threading-multi>libboost_iostreams.a(clean) for lack of <pbin.v2/libs/iostreams/build/gcc-4.7/release/link-static/threading-multi>bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.7/release/link-static/threading-multi>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.7/release/link-static/threading-multi>bzip2.o... ...skipped <pstage/lib>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.7/release/link-static/threading-multi>libboost_iostreams.a... gcc.compile.c++ bin.v2/libs/python/build/gcc-4.7/release/link-static/threading-multi/numeric.o In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/numeric.hpp:8, from libs/python/src/numeric.cpp:6: ./boost/python/detail/wrap_python.hpp:75:24: fatal error: patchlevel.h: No such file or directory compilation terminated. (From here on, I got a lot of errors that look like these ones.) "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -DNDEBUG -I"." -I"/usr/include/python2.7" -c -o "bin.v2/libs/python/build/gcc-4.7/release/link-static/threading-multi/object/function_doc_signature.o" "libs/python/src/object/function_doc_signature.cpp" ...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-4.7/release/link-static/threading-multi/object/function_doc_signature.o... ...skipped <pbin.v2/libs/python/build/gcc-4.7/release/link-static/threading-multi>libboost_python.a(clean) for lack of <pbin.v2/libs/python/build/gcc-4.7/release/link-static/threading-multi>numeric.o... ...skipped <pbin.v2/libs/python/build/gcc-4.7/release/link-static/threading-multi>libboost_python.a for lack of <pbin.v2/libs/python/build/gcc-4.7/release/link-static/threading-multi>numeric.o... ...skipped <pstage/lib>libboost_python.a for lack of <pbin.v2/libs/python/build/gcc-4.7/release/link-static/threading-multi>libboost_python.a... ...failed updating 58 targets... ...skipped 12 targets...

2 1

[interprocess] Reading huge files
by Sensei 16 Oct '13

16 Oct '13

Dear all, I am new to boost memory mapping, so this question might look simplistic. I need to read huge amounts of data (for instance, a 20GB file), and since memory mapping is quite fast, I was going to use it. However, I don't know what it would be faster when, due to memory constraints, I need to partition the file into regions. Moreover, I should treat the file as a string (I need to perform string operations). What I'm trying now is just to read the entire file: boost::interprocess::file_mapping mmap(input_filename.c_str(), boost::interprocess::read_only); boost::interprocess::mapped_region map(mmap, boost::interprocess::read_only); std::size_t l = map.get_size(), tot_read = 0; void *ptr = map.get_address(); while (tot_read < l) { register std::size_t x = std::min(l - tot_read, static_cast<std::size_t>(prealloc)); std::copy_n(static_cast<char*>(ptr) + tot_read, x, line.begin()); // Do something here... tot_read += x; } So, when the file is huge, do I need to create a mapped_region inside the loop? I didn't see anywhere in the documentation the possibility to move the mapped region. Another side-question, if you don't mind. I'm not sure that what I'm doing is efficient, especially the need to copy from the region to a string. If you have suggestions, I'm more than happy to hear these. Thanks & Cheers!

4 6