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

[Review] Polynomial library review begins today
by John Maddock 17 Mar '09

17 Mar '09

The review of Pawel Kieliszczyk's Polynomial library begins today and ends on Thurs 19th March. Download of the zip file from the vault is here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=polyno… Otherwise the library is present in the sandbox here: https://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/ And the docs can be read online here: https://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/libs/docs/index… The polynomial library contains a single class - polynomial<FieldType> - used for the manipulation of polynomials, along with a selection of algorithms which operate upon them. The library is an extension/rewrite of the existing "implementation detail" polynomial class in Boost.Math, and was written as part of last years Google Summer of Code under the mentorship of Fernando Cacciola. What to include in Review Comments ~~~~~~~~~~~~~~~~~~~~~~~~~ Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. The goal of a Boost library review is to improve the library through constructive criticism, and at the end a decision must be made: is the library good enough at this point to accept into Boost? If not, we hope to have provided enough constructive criticism for it to be improved and accepted at a later time. The Serialization library is a good example of how constructive criticism resulted in revisions resulting in an excellent library that was accepted in its second review. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Many reviews include questions for library authors. Authors are interested in defending their library against your criticisms; otherwise they would not have brought their library up for review. If you don't get a response to your question quickly, be patient; if it takes too long or you don't get an answer you feel is sufficient, ask again or try to rephrase the question. Do remember that English is not the native language for many Boosters, and that can cause misunderstandings. E-mail is a poor communication medium, and even if messages rarely get lost in transmission, they often get drowned in the deluge of other messages. Don't assume that an unanswered message means you're being ignored. Given constructively, criticism will be taken better and have more positive effects, and you'll get the answers you want. John Maddock. Review Manager for Polynomial Library.

11 14

Re: [boost] [C++-sig] [Python] GSoC and Python 3.0 Support
by Stefan Seefeld 17 Mar '09

17 Mar '09

Niall Douglas wrote: > > I would say that any GSoC project should choose *one* of the above > rather than try combining them. Better to do one thing well and in > stages than many things at once (unless you have loads of spare > time!). > I agree. (I wouldn't mind seeing projects for all of the above, but they definitely shouldn't be combined into one.) >>> Thanks! Seems there's a lot of interesting. So would anyone willing to >>> mentor this? >>> >> Sadly, I suspect that finding a mentor will be difficult (perhaps even more >> difficult than the actual project). Off the top of my head, the following >> folks come to mind: >> - Dave Abrahams >> - Stefan Seefeld >> - Ralf Grosse-Kunstleve >> - Roman Yakovenko >> You might try contacting them off list or on c++-sig (cc'ed on this email). >> I'm willing to participate, in particular, if other folks such as David are part of such a team, too. (While I believe I understand enough of both C++ and Python, lots of boost.python is still very obscure, so having David being part would greatly help. May be we could take the opportunity and collectively work on the (internal) boost.python docs, too. David, I notice you already indicated support. Could we team up for this ? (I will be out on vacation for about two weeks during the summer. Other than that I should be available throughout the summer.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

7 8

[fusion] C++0x support?
by Ein Held 17 Mar '09

17 Mar '09

Hello is there any chance for c++0x support (rvalue forwarding for the containers' constructors and operator=s' in particular) for fusion in 1.39? If noone is up to adding support for this to fusion, my collegues and me would love to implement it. Thank you

5 10

Re: [boost] [Review] Polynomial library review begins today
by Chris Card 17 Mar '09

17 Mar '09

On Tue, 10 Mar 2009 12:23:07 -0000, John Maddock <john(a)johnmaddock.co.uk> wrote: > The review of Pawel Kieliszczyk's Polynomial library begins today and > ends on Thurs 19th March. I just saw this and I have a few comments on the interface to the Polynomial class. 1. the name FieldType is mathematically misleading since the instantiating type is very likely not to be a field (e.g. int or a multiple precision integer type). 2. the Polynomial class provides a fairly minimilist set of supported functions. This may well be deliberate (if so, apologies), but I would like to see a richer interface including such things as - content (gcd of coefficients, where that makes sense) - polynomial discriminant - resultant of 2 polynomials - evaluation of homogeneous polynomial ( f(x) = sum c_i x^i, f(a,b) = sum c_i a^i b^(d-i) ) - evaluation at a polynomial (f(g(x))) - Pseudo-division of polynomials - finding roots over C - finding roots over F_p - factorisation over Z - factorisation over F_p Chris

1 0

convert_to: generic conversion between unrelated types
by vicente.botet 16 Mar '09

16 Mar '09

Hi, I need to convert to two unrelated types as chrono::duration and posix_time::time_duration. I have defined a generic function conver_to which use the constructor or conversion operator is the exists. Otherwise the user needs to specialize partially or completly) this function with the unrelated types. This function could be specialized with string and use Boost.StringConvert. In case there is an interest I have attached the files. Best, Vicente

1 0

ASIO certificate help.
by Mohammed Rasmy 16 Mar '09

16 Mar '09

1 0

Boost.Chrono where we are?
by vicente.botet 16 Mar '09

16 Mar '09

Hi, In November 2008, Beman said: "The Chrono library in the sandbox is now more-or-less feature complete." This library is esential to conform some boost libraries implementing standard libraries as Boost.Thread and Boost.Future as much as possible to the standard. It will be used also on the Boost.ThreasPool library and I would like also to use it on my AsynchronousExecutors library. Can we expect to have Boost.Chrono for review soon? Thanks, Vicente

1 1

request for discussion - yet another approach to automated memory management that solves the cycles problem and is very efficient
by Achilleas Margaritis 16 Mar '09

16 Mar '09

Dear boost members, The file 'mm2.zip' (in boost vault/memory) contains yet another solution for automatic memory management. The solution has the following attributes: 1) it solves the problem of cycles. 2) it releases resources deterministically. 3) it does not scan the graph of objects for reachability. It uses simple numeric values (i.e. keys) to determine if an object can be collected or not. The idea is very simple: pointers obtain keys during their construction (a simple global variable that is incremented). The key remains constant throughout the lifetime of a ptr. During pointer release, the pointers that point to an object are scanned: if there is no pointer that points to the object that has a lower key from the key of the releasing pointer, then the object can be deleted. The pointer semantics are normal C pointer semantics, except for the construction: the solution requires that pointers that are lvalues should obtain a key before the heap object that they will be assigned to. i.e. you can't do this: ptr p1 = new object; You have to do this: ptr p1; p1 = new object; All the operations have O(1) complexity, except the release operation, which has O(N) complexity, whereas N is the number of pointers that point to an object. Practically, the complexity is minimal, because it is rare to have that many different pointers to a single object (I think :-)). I have no idea if it works for all cases. The file 'main2.cpp' contains a lot of tests, which all pass. I have also included the benchmark of the Boehm GC modified to use my special ptr classes. In my machine, an Athlon 64 2.2 GHz, the benchmark is executed, using boost pools, at roughly 1900 milliseconds, whereas the Boehm gc benchmark, using the Boehm gc collector, is executed at roughly 1200 milliseconds (and the Java benchmark at roughly 600 milliseconds). The amazing thing is that it looks like it works, but I am not sure. I am sure there is a catch :-).

9 17

Re: [boost] [geometry] robustness approaches
by Simonson, Lucanus J 16 Mar '09

16 Mar '09

Barend Gehrels wrote: > You'll probably found this on the mails and not on the library > itself. It has no circles so it is a bit unfair to compare the > approaches like this. It focusses on integer arithmetic and 45/90 > angled polygons so it is different, more or less complimentary. I'm a little hurt to hear you say this. I keep repeating that I currently handle arbitrary angle polgon set boolean operations and that the implementation is 100% robust for integer coordinates but not so for floating point. There are practically no robustness issues with 90 polygons and only very little with 45 polygons, so why would I discuss it if I didn't need to concern myself with it? When I talk about robustness I'm talking about my arbitrary angle polygon clipping implementation. Allow me to demonstrate this capability more clearly. I have just exercised my arbitrary angle polygons booleans with floating point coordinates. It worked and successfully XOR-ed a hand with a spiral which is a visually appealing but trivially small test case of mine. I can't claim that it is 100% robust for floating point coordinates (yet) but I do have working code. I have attached both sets of outputs the image of the result as well. It is clearly correct. Just because I don't claim floating point robustness doesn't mean the algorithm doesn't work or can't produce correct results. I just haven't designed in and verified 100% robustness for floating point. Regards, Luke

2 3

question regarding g++ 4.3.2 and maybe others
by Robert Ramey 16 Mar '09

16 Mar '09

On my local system I'm trying to build/test with gcc 4.3.2. The library builds with nocomplaint, but when I build/run the tests I get:Info: resolving typeinfo for boost::serialization::detail::extended_type_info_typeid_0 by linking to __imp___ZTIN5boost13serialization6detail27extended_type_info_typeid_0E (auto-import/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.) My site-config.shows gcc : 4.3.2 : g++-4 ;should it show some compile time switch besides this? Or ?Robert Ramey

2 3