- Boost - lists.boost.org

Specific-Width Floating-Point Typedefs
by Paul A. Bristow 04 May '13

04 May '13

There has recently been some discussion on improving portability of programs using floating-point. Drawing on the benefits from definition of typedefs for int32_t, int64_t, int128_t . we have drawn up a proposal to add similar typedefs for floating-point. Our draft document (in both html and pdf) is at https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/html/i… https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/precis… We hope to propose this to the SG6 Numerics subgroup of WG21 ISO C++ standards body. But would welcome comments from Boosters to help us improve this proposal. Thank you. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

8 17

date libary construction
by Shamsher Siddiqui 04 May '13

04 May '13

i am deeply regretting for not responding your Question and for not posting the google summer of code Proposal . my pre semester exams are going on so i was busy in preparing which is ending on 7 may which is coming tuesday so i will be always not active during this period but i will try to respond to discussion which happening on the mailing list . i am finally sending only the proposal part . Proposal for DATE LIBRARY 1)Construction of Date: According to paper [2] there were many benchmark set but date should be represented in both ways i.e field and serial .Field and serial representation have their advantage over each other under certain operation . No invalid dates can be entered considering range cheaking ,non existent date if entered bad_date exception is thrown during the time of constructing the date. Constructing constant object for day,week_day. Date construction concrete structure <template class date_concrete> class date_pre { //year, month,week day //constructors //basic accessors declaration //conversion accessors //airthematic operation //camparison operator for date camparison } 2) Arithematic Operation On date Date airthematic can be done on three units i.e day,month,year.In chrono date ::calendar(Gregorian calendar) length of month and year is not fixed : day arithematic Adding number of days to date until range doesn’t exceed Implementing last day arithmetic to avoid the bad date excepti Eg. aug/last/2011 +months(1)= sep/30/2011 aug/31/2000 +months(1)=sep/31/2000 //invalid date bad date excep thrown month arithmetic Month arithmetic is quite complex compared to day arithmetic since number of are not fixed . (month day <=28 || month day =last day ) always add month month day =29 cheak for leap year and than add month Month day>=30 add but don’t add if resulting month is feb Using constant objects for month arithmetic. year arithematic Always add year to date considering the condition of leap year Reversal of date back to original date Usage of last day during year arithematic 3) InterConversion field representation & serial representation Some operation are quite fast on field but airthematic operation are much faster on serial campared field representation .So it is necessary to provide the inter-coversion so that it can be easily converted from one representation to another. Constructing bi-directional conversion of serial and field by making use of memoization optimization techinique. 4)Gregorian calendar implementation This Gregorian calendar will be a hybrid calendar that support both Julian and Gregorian calendar with a single discontinuity(the day on which Gregorian calendar was adopted ).The only difference between gregorian and julian is leap year calculation and before day of adoption of Gregorian calendar ,Julian calendar is implemented in this date library. The concrete draft for implementation for calendar template< typename ymd_type ,type name date _int _type > class gregorian_calendar { public : typedef ymd_type ymd _ type ; typedef typename ymd_type : : month_type month_ type ; typedef typename ymd_type : :day_type day_type ; typedef typename ymd_type : : year_type year_type ; typedef date_ int _type date_int_type ; static unsigned short day_of_week (const ymd _type &ymd ) ; static int week_number (const ymd_type &ymd ) ; static date_int_type day_number(const ymd_type &ymd ) ; static ymd_type from_day_number(date_int_type) ; static date_int_type julian_day_number(const ymd_type &ymd) ; static bool is_leap_year(year_type) ; static unsigned short end_of _month_day( year_type y ,month_type m ) ; static ymd _ type epoch() ; static unsigned short days _ i n _week(); }; 5)Building date iterator ,date output and date input Date Iterator will generate the date based on initial condition and end.Bidirectional iterator will do all the generation of series of date.Various iterators which will be implemented are day ,week ,month ,year Iterator. date output same as H. Hinnant. Questions: 1)could you explain us why do you think a class template date is a good alternative? i am using the template class since it will implement the user extensibility .This is very important feature for developer but not for normal user because developer likes to customise code it will give them to add or modify without removing features. 2) What is the expected service of the concrete classes? Which concrete representations would you provide? i have made the concrete class to show some of details of the date library which i am going to implement . <template date_concrete> class date_pre { /*year, month,week day construction of date_field i.e serial and field based reprasentation*/ /*details of constructor 1)date_pre(); //default constructor to initialise the date with the initial default value set 2)date_pre(year_type year,month_type month,day_type day); /*this constructor will initialize the date with values given by the user . but the constructor argument arrangement can be differ according to user or the country date format used */ 3)date_pre(year_type year,month_type month,week_of_month_type week_number,weekday_type wd); //this will constructs the date like monday in week 20 of 2013 4)date_pre(special day sp); //this will day construct the date with the special values like mothers day ,christmas in year //basic accessors declaration //conversion accessors //airthematic operation //camparison operator for date camparison //Coversion of calendar }; these all same as in H. Hinnant proposal except the conversion of Julian calendar to gregorian calendar . 3) How would you implement the memoizer for conversions? Would it be thread safe? Could you post an example how your date_pre and gregorian claendar classes are used? in summary, how your proposal improc-ves H.H implementation or my prototype? since pre semester are going so can i answer to this 2 question after coming tuesday ie 7 may 2013 sorry again for not answering ur questions i will try to be active on the mailing list during my pre semester xam Thanking You Shamsher Ahmed

1 0

[gsoc-2013] Physics Library Abstraction Layer
by Preston Hamlin 04 May '13

04 May '13

Attached is my current proposal in PDF format, as I am a bit wary of pasting several pages worth of formatted text into an email. Well wishes, -Preston

3 3

GSoC 2013 Boost mentors discussions
by Vicente J. Botet Escriba 04 May '13

04 May '13

Hi, I would like to share privately some comments with the GSoC 2013 Boost mentors. How can we do it? How to know who is a mentor? Do we have a know e-mail for all of them? Best, Vicente

7 12

Re: [boost] [operators] moving forward use return by reference for compilers with proper support?
by Niall Douglas 04 May '13

04 May '13

> Operators returning rvalue references are NOT safe. The C++98/03/11/14+ rules > apply to this scenario: > > X temporary(); > const X& r = temporary(); // ok, lives as long as r does > X&& r2 = temporary(); // ok, lives as long as r2 does > > They do NOT apply to this scenario: > > X&& func(X&& x) { return std::move(x); } > const X& r3 = func(temporary()); // DANGLING REFERENCE > X&& r4 = func(temporary()); // DANGLING REFERENCE > > The Standardization Committee made this mistake when applying rvalue > references to string's operator+(), which was fixed before C++11 was released. I completely agree. 99.9% of the time the only reason to *ever* return rvalue refs from an operator() is when you're passing through a parameter. Otherwise, return by value and leave the compiler's optimizer do its job. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

2 1

GSoC 2013 Bernoulli Numbers
by David Joy 03 May '13

03 May '13

Hi, I'm an Open University student completing my Open degree this summer (CompSci / Pure- & Applied Maths / Classical History) and am very interested in the Bernoulli numbers project for the Google Summer of Code. As well as the OU I've done quite a bit of mathematics elsewhere (Durham and KCL). Enclosed is my (naive) response to your challenge to implement the Akiyama–Tanigawa algorithm. I use the Boost framework for rational numbers, so as not to lose precision (though haven't yet adapted the solution for arbitrary precision numbers). [It would be more aesthetically pleasing if I could write the main algorithm in a STL-style so that it iterates of the vector, rather than explicitly using an index.] I have yet to get to grips with Boost.Test, but the enclosed shell script can generate a list of results, which matches the table found on the Bernoulli Number Page <http://www.bernoulli.org/> out to B_20. All code criticism gratefully accepted, David Bernoulli.cpp <http://boost.2283326.n4.nabble.com/file/n4646219/Bernoulli.cpp> Bernoulli_test.sh <http://boost.2283326.n4.nabble.com/file/n4646219/Bernoulli_test.sh> -- View this message in context: http://boost.2283326.n4.nabble.com/GSoC-2013-Bernoulli-Numbers-tp4646219.ht… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4

Re: [boost] GSoC Boost.Multiprecision project
by Jyotesh Choudhari 03 May '13

03 May '13

Hello, > Hi Jyotesh. >> Thank you for your valuable feedback. I have written >> project proposal for the first time in my life. So, I did >> not know what details to include. I have made some >> changes to my proposal as per your suggestions. > The proposal is a lot better. Now you need to submit > it to Google's melange site. > Please note that the proposal must be submitted > to Googles melange site. Some candidates have > been sending the proposals directly to us, and > this is incomplete. I have uploaded my proposal on http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/jyoteshr… >> I was studying the code for cpp_bin_float and I >> have some doubts in my mind. >> 1. What are eval_ops_signed_type, eval_ops_unsigned_type and >> eval_ops_float_type? > Eval-ops are the global binary arithmetic operatory, > and the eval_ops-types are those types that will be > supported for global binary math with the radix-2 > back-end. >> 2. What is the use of following lines? >> typedef mpl::list<eval_ops_signed_ type>? signed_types; >> typedef mpl::list<eval_ops_unsigned_type> unsigned_types; >> typedef mpl::list<eval_ops_float_type>? ? float_types; > It's Boost's way of creating a list of built-in types. > Again, these are the types that will be supported for > global binary math. >> These are not used in the class elsewhere. Similar lines >> are present in cpp_dec_float.hpp also and not used >> elsewhere in the class. > They are used by the multiprecision::number front-end > to actually implement global binary math ops. >> 3. In the function from_float_type, I think the variable >> number_of_digits should be initialized to zero before >> using it in while loop. > cpp_bin_float is in a rudimentary state right now. > It is not even close to working. That's the point of > the GSoC project. So stuff might not be quite right > yet. Thank you solving my doubts. I will see the code multiprecision::number also to see how above types are used. >> Lastly, I have seen on mailing list, that some of the >> students are submitting code samples. > It's too late for code. Get your best shot at a good > proposal onto melange. If you would like to submit > code sample, you can do it after your proposal is up. > Good luck. > Sincerely, Chris. Thanks and regards, Jyotesh Choudhari

1 0

Voronoi benchmark update
by Sebastien Loriot 03 May '13

03 May '13

Hello, I'm involved in the CGAL Project, and saw the Voronoi benchmark. It would be nice if you could change the CGAL code slightly, as it is not as bad as it currently seems. Attached is the diff to the trunk of boost. Concerning the Voronoi diagram of points, a CGAL user, would use the Delaunay_triangulation_2 class. Concerning the Voronoi diagram of segments (that do not intersect) one would make a better choice for number types and traits classes. Also one better first inserts the endpoints and then the segments (I agree, this should definitely go into a member function). Admittedly our examples could be better. Cheers, Sebastien

3 4

[gsoc-2013] Physics Library Abstraction Layer
by Preston Hamlin 03 May '13

03 May '13

On Sun, Apr 21, 2013 at 9:37 PM, Michael Marcin <mike.marcin(a)gmail.com>wrote: > On 4/19/2013 8:59 PM, Preston Hamlin wrote: > >> >> I have completed a draft proposal and would appreciate some feedback: >> >> https://www.dropbox.com/s/**7xhha0a3ahk5p6r/preston_** >> hamlin_gsoc_proposal_draft.pdf<https://www.dropbox.com/s/7xhha0a3ahk5p6r/preston_hamlin_gsoc_proposal_draf…> >> >> >> > Seems like a fine proposal. > > Do take note of boost coding guidelines. > > -- > Use the naming conventions of the C++ Standard Library (See Naming > conventions rationale): > > * Names (except as noted below) should be all lowercase, with words > separated by underscores. > * Acronyms should be treated as ordinary names (e.g. xml_parser instead of > XML_parser). > * Template parameter names begin with an uppercase letter. > * Macro (gasp!) names all uppercase and begin with BOOST_. > -- > > http://www.boost.org/**development/requirements.html#**Guidelines<http://www.boost.org/development/requirements.html#Guidelines> > > Prefer object interfaces to pointers. > > For example instead of: > bxPhysics* physics(___); > > prefer: > boost::physics::physics physics_(____); > > Although on second thought naming might need some more thought here. > > What exactly is it that PxCreatePhysics creates? Is it a physics context > like an OpenGL context? Is it more like a physics service like a > boost::asio::io_service? Is it a physics simulation? Is it physics object > factory? > > I'm not sure but I think it's almost certainly not just a physics. > > > In any event it looks good to me. > > My apologies for the belated response. With ACM duties and finals week I have had no more than a few minutes to sit down. I typically try to follow the Google style guide for coursework and the like, so changing naming conventions is but a minor change. The PxPhysics object is used to create and maintain a "realm" of physics. It keeps track of collision methodologies and is essentially the backbone of how edges and vertices interact with one-another. It is build on top of a PxFoundation object which provides the "foundation" of the program, including callback management and some behind-the-scenes memory allocation. The PxScene object manages the elements of a particular "scene" or "world" including pointers to the various objects and gravity. I am not sure how (other than routing messages between objects) boost::asio::io_ would provide much of anything in terms of physics. It is similar to a context like a Device Context or OpenGL Rendering Context but is not used directly and instead used in the creation of more modular objects which are linked to it upon creation. There are no built-in emitters (something that could be provided in this project) and the documentation states that the non-fluid particle system uses rigid bodies that interact with the world but not eachother, which makes sense. I was unsure how prefixes should/would be used in a project like this, which is why I used the "bx" prefix. One thing to note is that PhysX uses a 3-vector class to hold vector data. It is pretty basic but also moderately fleshed out in the source. Would compatibility with the uBLAS matrices (as vectors are to be consolidated) be desirable? The PhysX design uses pointers for just about everything, so that could mean some interesting design considerations. I will be spending the Summer assisting one of my professors with his research project (half-time) and will update my proposal accordingly. Also, if I have some free time this weekend, I can crank out some *rough* proof of concept code if it is desired. Many thanks, -Preston

1 0

[GSOC 2013]Boost.Math Proposal
by Nikhar Agrawal 03 May '13

03 May '13

Hi everyone, I have been in touch with mentors for the project "Boost.Math Bernoulli Numbers and Applications to Special Functions" for the past three weeks. And after regular interactions and assignments and suggestions from them, I have finally posted my proposal. I was a little late because in submitting the proposal because of my end semester examinations. But that now they are over, I have all the free time to completely concentrate on the project. Here's the link to the proposal. http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/nikhar/1 I'd be really grateful if you guys could review it and suggest improvements. Thanks a lot. :) Nikhar P.S.:- If anyone wants I could also forward the conversations I've had with the mentors until now and I could upload the assignments I've done if anyone's interested.

1 1