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

A Boost.NumericAdaptor library to support big numbers
by Bruno Lalande 02 Apr '09

02 Apr '09

Hello, Barend quickly talked about this in the discussion about robustness, big numbers and GMP. We have discussed about the idea and I'd like to present it here to see if there's an interest. The idea started from the need to rely on big numbers in geometry computations that are sensitive to floating point errors. The most important points were: - big numbers are needed for those computations - it's difficult to develop a Boost Big Numbers library as efficient as the existing ones - having a Boost geometry library that *necessarily* depends on an existing big numbers library would impose to the user the way in which big numbers must be handled, and would imply a dependency that apparently disturbs some people Thus we had the idea of using an adaptor, that is a wrapper that would have the same semantics as a number, with an underlying implementation chosen at compile-time, by selecting a policy. There would be a IEEE policy that doesn't use any big number at all, and other policies that would be implemented upon the most widely used big numbers libraries. In the end it appears that this adaptor could become a library on its own since it can be useful in other libraries than just geometry. It could thus take the form of a Boost.NumericAdaptor library, aimed to any library developer who needs to optionally enable the use of big numbers for the most robustness-sensible operations of his library. He would just have to take a policy as a template parameter, and propagate this policy to a Numeric Adaptor used internally. The first user of this library would obviously be the GGL we're developing. Libraries like the fixed-size matrix being currently discussed as a GSoC project could offer take advantage of this kind of library, since ideally it has to support big numbers. The sample in attachment shows the numeric_adaptor, a IEEE policy, a GMP policy and a sample showing the use of the library. The implementation has to evolve of course, but the main points are here. Would there be an interest in adding such a library into Boost? Bruno Lalande Barend Gehrels

7 10

Back to Boost.SIMD - Some performances ...
by Joel Falcou 02 Apr '09

02 Apr '09

I'm still working on a potential Boost.SIMD proposal despite the apparent lack of interest by the list. Last discussion spawned the fact that actual performances figures may be interesting. So here's some (see end of mail). This table show for a subset of non-trivial functions the cycles needed to compute one value in scalar, using SSE2, some precision concerns and the actual speed-up. Most of them are super-linear because either : 1/ libc algorithm is badly implemented, or 2/ non-SIMD architectural difference between SSE2 FPU and scalar FPU leads to additional speed-up Most transcendental functions used a SIMD evrsion of the old yet useful Cephes C library based around various polynomial estimations. Results on Altivec processor are roughly the same except for transcendental where the use of a proper FMA instead of sequence of mul-add increases performances.For trivial function like +,-,*,/, I was happily surprised that indeed gcc is able to generate SIMD code. Alas, gcc auto-SIMD speed-up never exceed 2.54 while our code can go up to 3.5. Concerning the problem of interface and support of odd-ball vector size in a platform independant fashion, we use the remark of Matthias and provide a vec<T,C> class in which the vector cardinal can be speficified (and is equal to the native cardinal of said type by default). Things like vec<double,5> are handled as boost::array and provide same interface and set of functions. for any given functions, it cna be applied either to any vec<T,C> types or any native SIMD type (__m128 in SSEx or vector xxx in Altivec). Syntaxic sugar like v = v+4 is provided and perform consatnt splatting before SIMD evaluation. This still has to be boostified and made independant of the whole project it depends on. Once done, a preliminary version will be uploaded into the Vault. Current target architecture are : - SSE2, SSSE3,SSE3 - AltiVec for PPC and Cell processor (a patched version of boost is needed) Comments and questions welcomed. || -------------- || --------------- || scalar || -------------- vector ---------------- || ---- || || || || cycles ||cycles | ulp | rms | peak || s-up || || --------------------------------------------------------------------------------------------- || || abs_ || float || 2.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 2.4 || || acosh_ || float || 148.2 || 30.2 | 1 | 9.15e-09 | 1.19e-07 || 4.9 || || acos_ || float || 261.8 || 14.7 | 3 | 7.01e-08 | 2.38e-07 || 17.8 || || arg_ || float || 5.0 || 1.2 | 0 | 0.00e+00 | 0.00e+00 || 4.2 || || asinh_ || float || 152.8 || 32.4 | 1 | 1.22e-08 | 1.19e-07 || 4.7 || || asin_ || float || 256.5 || 11.6 | 2 | 5.32e-08 | 2.28e-07 || 22.1 || || atanh_ || float || 123.9 || 20.4 | 2 | 2.27e-08 | 4.55e-07 || 6.1 || || atan_ || float || 160.7 || 12.7 | 1 | 3.55e-08 | 6.74e-08 || 12.7 || || bitofsign_ || float || 5.1 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 6.1 || || boolean_ || float || 5.4 || 1.0 | 0 | 0.00e+00 | 0.00e+00 || 5.4 || || cbrt_ || float || 152.5 || 39.7 | 1 | 2.76e-08 | 7.77e-08 || 3.8 || || ceil_ || float || 16.6 || 2.8 | 0 | 0.00e+00 | 0.00e+00 || 5.9 || || cosh_ || float || 211.5 || 19.1 | 2 | 4.00e-08 | 1.83e-07 || 11.1 || || cos_ || float || 112.2 || 14.6 | 1 | 2.98e-08 | 1.11e-07 || 7.7 || || cospi_ || float || 103.6 || 12.1 | 1 | 3.43e-08 | 1.19e-07 || 8.6 || || cot_ || float || 142.8 || 17.8 | 3 | 5.54e-08 | 2.38e-07 || 8.0 || || cotpi_ || float || 142.1 || 17.1 | 6 | 9.62e-08 | 4.08e-07 || 8.3 || || exp10_ || float || 169.3 || 32.1 | 1 | 2.88e-08 | 1.19e-07 || 5.3 || || exp_ || float || 171.3 || 19.3 | 1 | 2.60e-08 | 1.19e-07 || 8.9 || || expm1_ || float || 294.1 || 42.6 | 3 | 2.89e-08 | 1.94e-07 || 6.9 || || floor_ || float || 16.9 || 2.7 | 0 | 0.00e+00 | 0.00e+00 || 6.4 || || gd_ || float || 602.4 || 35.8 | 3 | 3.93e-08 | 2.46e-07 || 16.8 || || indeg_ || float || 2.2 || 0.8 | 0 | 2.59e-08 | 5.94e-08 || 2.7 || || inrad_ || float || 2.2 || 0.8 | 0 | 2.53e-08 | 5.94e-08 || 2.6 || || iseqz_ || float || 5.5 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.3 || || iseven_ || float || 45.0 || 2.3 | 0 | 0.00e+00 | 0.00e+00 || 19.9 || || isfin_ || float || 5.9 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.6 || || isflint_ || float || 38.3 || 1.8 | 0 | 0.00e+00 | 0.00e+00 || 21.4 || || isgez_ || float || 6.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 7.4 || || isgtz_ || float || 6.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.5 || || isinf_ || float || 6.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.5 || || islez_ || float || 5.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 5.8 || || isltz_ || float || 5.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 5.8 || || isnan_ || float || 3.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 3.6 || || isnegative_ || float || 5.6 || 1.1 | 0 | 0.00e+00 | 0.00e+00 || 5.0 || || isnez_ || float || 5.4 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.2 || || isnotfinite_ || float || 3.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 3.6 || || isodd_ || float || 47.8 || 2.5 | 0 | 0.00e+00 | 0.00e+00 || 18.8 || || ispositive_ || float || 5.6 || 1.3 | 0 | 0.00e+00 | 0.00e+00 || 4.2 || || log10abs_ || float || 107.5 || 17.3 | 2 | 6.59e-08 | 2.12e-07 || 6.2 || || log10_ || float || 105.4 || 16.9 | 2 | 6.58e-08 | 2.12e-07 || 6.2 || || log1p_ || float || 149.7 || 18.8 | 1 | 9.16e-09 | 1.19e-07 || 8.0 || || log2abs_ || float || 107.5 || 17.2 | 1 | 1.89e-08 | 1.19e-07 || 6.3 || || log2_ || float || 105.5 || 17.1 | 4 | 1.90e-08 | 2.51e-07 || 6.2 || || logabs_ || float || 107.5 || 23.6 | 1 | 4.36e-08 | 1.19e-07 || 4.6 || || log_ || float || 108.3 || 15.4 | 1 | 9.12e-09 | 1.19e-07 || 7.0 || || mantissa_ || float || 22.1 || 5.0 | 0 | 0.00e+00 | 0.00e+00 || 4.4 || || oneminus_ || float || 3.3 || 0.8 | 0 | 5.16e-10 | 5.96e-08 || 4.0 || || oneplus_ || float || 3.4 || 0.8 | 0 | 2.87e-10 | 5.74e-08 || 4.1 || || rec_ || float || 37.4 || 4.3 | 0 | 2.48e-08 | 5.92e-08 || 8.8 || || round_ || float || 43.7 || 5.5 | 0 | 0.00e+00 | 0.00e+00 || 8.0 || || rsqrt_ || float || 105.4 || 11.3 | 1 | 3.62e-08 | 8.81e-08 || 9.3 || || signedbool_ || float || 9.3 || 0.9 | 0 | nan | 0.00e+00 || 10.6 || || sign_ || float || 12.1 || 2.5 | 0 | 0.00e+00 | 0.00e+00 || 4.9 || || signnz_ || float || 12.1 || 1.4 | 0 | 0.00e+00 | 0.00e+00 || 8.5 || || sinh_ || float || 267.2 || 19.1 | 3 | 2.38e-07 | 3.84e-07 || 14.0 || || sin_ || float || 110.5 || 17.0 | 1 | 2.98e-08 | 1.12e-07 || 6.5 || || sinpi_ || float || 115.8 || 14.4 | 1 | 2.98e-08 | 1.10e-07 || 8.0 || || sqr_ || float || 2.0 || 0.7 | 0 | 2.53e-08 | 5.94e-08 || 2.9 || || sqrt_ || float || 68.3 || 7.1 | 0 | 2.62e-08 | 5.96e-08 || 9.6 || || sqrtabs_ || float || 68.3 || 7.0 | 0 | 2.61e-08 | 5.96e-08 || 9.7 || || tanh_ || float || 206.4 || 20.8 | 197 | 1.63e-07 | 1.77e-05 || 9.9 || || tan_ || float || 153.0 || 17.8 | 2 | 4.18e-08 | 1.45e-07 || 8.6 || || tanpi_ || float || 156.2 || 18.0 | 2 | 4.16e-08 | 1.48e-07 || 8.7 || || --------------------------------------------------------------------------------------------- || -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

9 23

[safebool] Can we generalize it and put it into utilities?
by Vladimir.Batov＠wrsa.com.au 01 Apr '09

01 Apr '09

Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities? struct safebool { typedef void (safebool::*unspecified_bool_type)() const; typedef unspecified_bool_type result; explicit safebool(bool v) : value_(v) {} operator result() const { return value_ ? &safebool::internal_bool : 0; } private: void internal_bool() const {}; bool value_; }; That way all we (and the users) will have to do to deploy the technique will be class Foo { ... operator safebool::result() const { return safebool(my_condition); } }; This seems simple and hassle-free. Thanks, Vladimir.

8 19

has_operator_new
by Robert Ramey 01 Apr '09

01 Apr '09

I've made a TRAK item to request a new type traits feature - has_operator_new. I've included an implementation and a test - both type_traitsified. Hope you can see fit to check it out, and if it's OK, check it in. Let me know when you do this. Once this is in, I can clear a dependent feature request TRAK item from the serialization library. Robert Ramey

2 3

[gsoc] Interest check for 3d geometry proposal
by Kornel Kisielewicz 01 Apr '09

01 Apr '09

Hello all, I was instructed on the #boost-soc channel to post the initial interest check on the GSoC proposal on the dev list, so here it is. It was inspired by one of the project proposals from 2006 (Geometry Library). As a known fact Boost begins to be used in the gaming industry. Following the idea of code reusage, there are several generic algorithms and components reused by virtually every 3d gaming engine. Most particulary this is 3D math. Sure, Boost has a linear algebra library graph algorithms, and a proposed geometry library, yet what is missing is a high-performance low-dimensional linear algebra library ( vectors and matrices up to the 4th dimension ). Side by side we have also a need of several 3-dimensional algorithms -- including, but not limited to intersection tests, inclusion tests, volume bounding, and several computational geometry algorithms. My suggestion would be creating a 3d specific geometry library for boost, with reasonable performance and the most used algorithms. I'd be happy to work on such a library as a GSoC project. My goal is to assess the initial interest in such an GSoC proposal idea before preparing and posting a more detailed description. -- regards, Kornel Kisielewicz http://chaosforge.org/

22 56

GSoC 2009
by Julian Mautner 01 Apr '09

01 Apr '09

Hi everyone! I'm Julian, 21 years old, student at the university of Innsbruck, Austria. Currently I'm making my bachelor in physics and computer science. I really would like to participate as a GSoC-student of yours. I intend to write a proposal for the Boost.Devector project. But first I wanted to ask a few questions: 1) I didn't understand if devector is an intrusive container or it only has to use them? 2) What does this devector class should (exaclty) be capable to do? 3) Which methods are the most important to perform in O(1)? 4) I didn't used the boost-library very much in the past, is this a great problem for this project? Thanks for your time. Regards, Julian

2 1

How to generate a Bernuolli number
by Barco You 01 Apr '09

01 Apr '09

Hi, I want to randomly generate a Bernuolli number [0, 1],with probability p ~[0 1]. How to do that with boost? Thanks! -- ------------------------------- Enjoy life! Barco You

6 16

[GSoC] Opinions and suggestions for improving CGI library
by Eugene Wee 31 Mar '09

31 Mar '09

Hi everyone, I hope to participate in this year's Google Summer of Code by working on a project for Boost, and would like to get opinions and suggestions on what I intend to do. In GSoC 2007, Darren Garvey worked on a CGI library under the mentorship of Christopher Kohlhoff. This sounded interesting to me, as my first forays into programming were for the Web with PHP, but I never actually used CGI with C++, even though I have been aware of cgicc and Wt for some time. I contacted Darren, who informed me that while he was still working on the library, he lacked the time to implement many features, and would welcome help. There were a number of features that he highlighted, but three of them stood out for me: * Persistent sessions >From my experience with PHP, session handling tends to be a heavily used feature that this CGI library lacks. I intend to design an interface for session handling that would allow the use of memory mapped files (with the help of Boost.Interprocess) and relational databases as storage options. I will also implement session handling with one of the possible storage options. * Improved multipart/form-data parsing Currently, the parsing is done with regex, which is something of a hack in this case. The aim is to replace the use of regex with the use of Boost.Spirit. From what I see, this is also an area that needs more testing, hence developing the test suite would be an important part of this subproject. * Windows support for Fast CGI Portability is one of the goals of Boost, and this is of interest to me personally as I use Windows quite often. However, I am unable to conceive a solution (or even pinpoint the problem) to this right now, but I believe that with time I can figure it out, especially since Darren has some idea as to what might need to be done. For reference: Darren's proposal abstract: http://code.google.com/soc/2007/boost/appinfo.html?csaid=5869D5120647336D Current documentation: http://omnisplat.com/docs/ In Boost sandbox: https://svn.boost.org/svn/boost/sandbox/SOC/2007/cgi/ Thank you, Eugene Wee

6 9

How to bind objects with reference handle
by Altaf Navalur 31 Mar '09

31 Mar '09

Hello All, I am using the latest version of boost. I am trying to bind a particular member function to a signal. I am trying to bind the signal to a pointer, which is a reference Handle(WeakRefHandle,RefHandle). I am getting an error for this. How do I fix it. I am trying to port a game, So switching to boost::shared_ptr is not an option, as it will force lot of changes in the game code. Cheers, Altaf -- An eye for an eye only ends up making the whole world blind.

2 1

Google SoC idea - Relations
by Michael Lopez 31 Mar '09

31 Mar '09

Hello everyone. I am an undergraduate student of Kent State University and I am drafting a proposal for GSoC to try and extend the BGL. I don't exactly know to whom I should direct this post, but I wanted to informally pass this idea to the boost community. I would like to add a binary relation data type to the BGL. Binary relations are quite similar to graphs and can be visualized using directed graphs. I would even like to use the graph interface for relations, since one of its key features should be that a user can use relations just as she would use graphs. Sometimes, a single criterion is all that is needed to define a relation (an edge) between two objects (vertices). This relation can be a '<' operator or '>=' operator or something more complex, for instance an equivalence relation between some geometric shapes. It doesn't really matter. The beauty in this datatype is that the relation, in the form of a function, will be user defined. I would like to provide several common relations such as less than and modular equivalence, but the relation is completely up to the user and packed snugly into a familiar interface that is quite capable of handling relations. Speaking of snug packing, the other key feature that differentiates relations from graphs is data storage. The relation data type will store a set of objects rather than vertices and edges. Since the relation is defined as a function, checking to see whether there is a relation (an edge) between two objects (vertices) simply requires a function call with those two objects as parameters. This bypasses the look up of an edge in favor of a computation. The computation, however, does not have to be limited to a boolean value. In the case of weighted complete graphs, the relation can be utilized as a normal functions, such as distances between cities. Better yet, the Boost.optional can be used to return either a type or false if a relation does not exist. Time permitting, I would also like to examine the possibility of providing support for properties like transitivity and symmetry and also provide a data type that would enable closures, such as transitivity (connectivity). who am I: Like I mentioned above, I am a KSU student majoring in both mathematics and computer science. I've been programming in c++ since early highschool. good heavens, that would be about 8 years. I am fascinated by generic and template programming and enjoy applications of math in programming, particularly visulaization and applications of discrete math. thank you for reading, michael lopez

4 3