- Boost - lists.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

[Boost.Asio] Compiler warning in address_v6.hpp
by Fraser Hutchison 02 Apr '09

02 Apr '09

I'm new to boost and am looking for a bit of advice if possible. asio/ip/address_v6.hpp lines 58 & 355 yield the following compiler warnings when flag -Wmissing-braces (which is enabled by -Wall) is set: missing braces around initializer for 'u_char [16]' missing braces around initializer for 'in6_addr::<anonymous union>' These can be avoided by amending e.g. line 58 from boost::asio::detail::in6_addr_type tmp_addr = IN6ADDR_ANY_INIT; to boost::asio::detail::in6_addr_type tmp_addr = {{IN6ADDR_ANY_INIT}}; Is this worth submitting a bug report and patch for this, or not?

3 2

personal samsung
by Fernando Cacciola 02 Apr '09

02 Apr '09

11 6 100 6359

1 1

[gsoc] Proposal - Boost.Matrix - DRAFT RFC
by Kornel Kisielewicz 01 Apr '09

01 Apr '09

Hello all, Following the discussion in the threads: "[boost][gsoc] Interest check for 3d geometry proposal" "[boost] [gsoc] fixed size matrix class?" I post a draft of my proposal with a request for comments. Following the suggestions I decided to scale down the proposal to a polished and production-quality fixed-size Boost.Matrix library, with a big emphasis on correctness and performance. The application follows: Abstract ========= uBLAS is Boost's general linear algebra library, and it is a fine library indeed. However, in some cases it's design decisions, while quite rational for the general use case, are restrictive. This proposal is about a new library that would address some of these issues in the specific situation of vector and matrix operations on fixed sized structures. Suggested is a new library boost::matrix. The library would introduce a single container class that allows representation of fixed size vectors and matrices, and their respective standard operations. The library would define the following template template<typename T, std::size_t N, std::size_t M, class Traits> matrix and standard operations on it. The class would make heavy use of template specialization to allow efficient vector operations ( matrices with size 1xN ), and provide efficient operations for the common sizes (2-4). The class will provide the interface of STL containers with the exact concept depending on the Traits used. Care will be taken to allow transparent usage within STL and other boost libraries. Rationale ========== Boost.Matrix aims to be for uBLAS, what Boost.Array is for vectors -- a fixed size version to remove the overhead. The need is however greater, because while uBLAS provides a template for a fixed-sized version of it's arrays, the template is just a cover for the original uBLAS matrices. While the performance is comparable, the size includes a unnecessary field size. In cases that make heavy use of fixed sized matrices and vectors ( like real-time computer graphics ), such a tradeoff is unacceptable -- due to increased memory consumption as well as effective vectorized math operations, and alignment of structures passed ( a single 4D vector should effectively fit a 128 bit register, and a single 128 bit move operation ). Also, knowing the dimensions of a matrix/vector at compile time, allows for a more efficient operation implementation, both from the programmers side ( better algorithms ), as well as from the compilers side ( optimization ). Primary deliverables ===================== Boost.Matrix library, with the following features: a) a boost::matrix base container class for 2-dimensional matrices, with the proper behavious and semantics of a container, written following the boost coding guidelines, and with full portability in mind b) specializations for efficient vector (1xN matrix) handling c) operators for readable but efficient vector/matrix math d) operator specializations for matrices and vectors of the most common size (2-4) for most efficient implementation Secondary deliverables ======================= a) performance test suite, for testing optimizations b) unit tests for the whole library providing full operation coverage and code-coverage c) documentation for the whole library in the BoostBook format d) efficient implementation of interoperability of Boost.Matrix with other boost libraries (uBLAS in particular) Bonus deliverables =================== ( if time allows these will be delivered during program timeline, if not, they will be implemented afterwards ) a) optional (compile-time controlled) integration with Boost.SIMD to boost (no pun intended) performance b) performance tests on different compilers/architectures, further optimizations c) support for further boost libraries ( Boost.Assign, sandbox libraries, etc. ) Design issues ============== a) compile-time concept checking to only generare functions that make sense for the given type ( no floating point operations for integral types ) b) usage of templates to unroll the operations at compile-time to allow the compiler to optimize them ( needs to be tested case by case with the performance test suite ) c) usage of expression templates to eliminate temporaries in expressions d) care to keep most useful memory alignment ( to provide ease of use with direct usage in architecture dependent pipelines ) e) design with architecture-dependent optimizations in mind ( ease of expansion ) f) keeping all the standard boost practices, including workarounds for non-conformant compilers Project schedule ================= I plan to do at least weekly progress reports with emphasised design decisions (however well designed in the first phase, reality will probably change the design afterwards at least a little). Progress reports will be directed to the medium established with the mentor (blog, list or only direct communication). This will be my only job once summer starts, and will be treated as such during program coding timeline ( full-time schedule ) -- a week may fall out for a short vacation. Preplanning (April 20 - May 23) -------------------------------- Most of the major design decisions need to be done before the program starts. A end-user interface for the library should be established before the program starts. This will be summed up in a report that will be sent to boost-dev with a request for comments. Phase 1 (Correctness) - (May 24 - June 14) ------------------------------------------- A working basic (non-optimized) implementation, and a full test suite for the basic operations will be created. Goal for this phase is to provide a correct and working implementation. Basic usage document. Phase 2 (Functionality) - (June 14 - July 5) --------------------------------------------- Performance test suite. Compiler-level optimizations ( expression templates, unrolling, etc ). Basic library compatibility ( STL container, uBLAS ). Concept checking. Phase 3 (Optimization) - (July 6 - July 26) -------------------------------------------- Optimizations for vectors, optimizations for specific vector and matrix sizes, optimization checking through performance test suite. Code review for eventual optional architecture optimization ( Boost.SIMD for example ). General optimization of code. Update of documentation. Phase 4 (Finalization and bonuses) - (July 27 - August 10+) ------------------------------------------------------------ Testing on as many architectures as possible ( probably will need some help here ). Fixes. Cleanup of the code where needed. A report of the implementation that again will be posted to boost-dev with a request for comments. Here is included also buffer time if there will be delays in one of the former phases. If not, work will continue with the Bonus deliverables. Brief resume ============= I'm a Computer Science PhD student (2nd year) at the University of Wroclaw (Poland), in the field of Computer Graphics. My interests lie in Game Programming and Design, with a special hunch for Real-time Proceduraly Generated Content. I actively run self-designed courses and lectures at the University ( 3ds MAX course last year, Game Programming lecture this semester, and probably an Advanced C++ course next semester ). Currently, until the end of the semester, I'm working full-time at Tieto corporation, doing a large scale project for Nokia. Previously I worked at a smaller computer game company working on a massive multiplayer game. I've successfully taken part in two last GSoC's creating a Procedural City Generator for the BZFlag project. I consider myself a fairly competent C++ programmer, although I only recently discovered its true strengths ( learned to properly use and write in the style of STL, started reading Boost sources, and got hooked into C++0x ). I'm currently using the language both at work and for my own projects. The latter include a 3D game engine (in progress), and an unannounced space combat/trading game. I am a big fan of roguelike (ASCII) games, and managed to write several roguelikes up to date, the most famous one of them being DoomRL ( http://doom.chaosforge.org ) that did even get mentions in contemporary gaming magazines. Homepage : http://chaosforge.org/ IRC nick : Epyon E-mail : kornel.kisielewicz at gmail.com / epyon at cs.uni.wroc.pl -- regards, Kornel Kisielewicz

7 14

Extrinsec conversions (Was [safebool] Can we generalize it and put it intoutilities?)
by vicente.botet 01 Apr '09

01 Apr '09

----- Original Message ----- From: "Eugene Wee" <crystalrecursion(a)gmail.com> To: <boost(a)lists.boost.org> Sent: Wednesday, April 01, 2009 4:10 AM Subject: Re: [boost] [safebool] Can we generalize it and put it intoutilities? > > Hi, > > On Wed, Apr 1, 2009 at 6:20 AM, Vladimir Batov > <vladimir.batov(a)wrsa.com.au>wrote: > >> I glanced over "explicit conversion operators" in C++0x. It did not struck >> me as >> relevant to safe_bool. Care to elaborate? > > > It is relevant since you can say, define an explicit conversion function to > convert to bool, and yet avoid the very problems with say, also allowing > implicit conversion to int, that the safe bool idiom is used to avoid. In > other words, it is a language feature directly designed to replace the safe > bool idiom, and more. Hi, Thanks for the clarification. Even if the following is not related to the safe bool idiom it is related to conversions. The current standard allows to define intrinsec coversions, i.e. conversions that are defined either as a conversion operator on the from class or as a constructor on the to class. Vladimir StringConvert proposal seems to go towards a conversion from/to strings (If I've understood?). lexical_cast can be seen as an extrinsec converions of unrelated types via a common type stream type. I have proposed a generic convert_to template function that generalize extrinsicaly the explicit convertion of unrelated types. template <typename To, typename From> To convert_to(From&); One difference is that for C++0x explicit conversion you can write From from; To to=To(from); While for unrelated types you are forced to write From from; To to=convert_to<To>(from); The other difference is that constructors and conversion operators can be implicit, while the convert_to function can not. Do you think that it could be an interest in extending the C++0X standard to take care of these extrinsically defined conversions between unrelated types? Have a sens to have extrinsec conversions which implicitly convert? Should this convert_to<T> operator be considered as a friend class of T? I know that this is out of the scope of Boost, but I just wanted to know your opinion before posting to comp.lang.c++.moderated. Apologize if this has already been discused. Best, Vicente

3 2

[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

[gsoc] Concept check
by Kasra 01 Apr '09

01 Apr '09

Hi, I have decided to use the following concept for my gsco proposal regarding boost.crypto. The dilema at the moment what is the minimum contiguous ranges concept? Any suggestiong over the design? concept CryptoBuffer // which is a variable sized buffer that // uses an allocator that securely deletes. concept BlockCipher { typename value_type; typename size_type; typename traits_type; auto key(void) const throw(); template<CryptoBuffer CB> void key(const CB& ) const throw(invalid_key_size); template<CryptoBuffer CB> void encrypt(CB&, const CB& ) const throw(bad_state); template<CryptoBuffer CB> void decrypt(CB&, const CB& ) const throw(bad_state); }; struct crypto_stream_parallel_encryption { }; struct crypto_stream_parallel_decryption { }; struct crypto_stream_parallel : crypto_stream_parallel_encryption, crypto_stream_parallel_decryption{ }; concept ModeOfOperation { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type transform_size; static constexpr size_type state_size; const auto cipher() const throw(); void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(CB0& , const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update_final_block(CB0& , const CB1&); }; concept StreamCipher { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type transform_size; static constexpr size_type state_size; const auto cipher() const throw(); void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(CB0& , const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update_final_block(CB0& , const CB1&); }; concept HashAlgorithm { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type state_size; static constexpr size_type transform_size; void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type finalise(const CB1&); }; Any suggestiong over the design? -- Kasra

1 0

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