- Boost - lists.boost.org

Re: [boost] [Spirit-devel] RFC Generic data structure traversal / manipulation library
by dan marsden 15 Jan '08

15 Jan '08

Hartmut Kaiser wrote: >IIUC, the traversal library is designed to help traversing arbitrary data >structures and to apply local _value_ changes. My question is: >Is the used concept extensible in a way allowing for _structural_ changes of >the traversed data structure? This would make it usable for tree >transformations, which would be especially interesting if used with >Spirit.Qi (parsing) and Spirit.Karma (generation). Currently, the most straightforward way to make structural changes to the tree is at nodes where variants are present. Obviously then switching to a subtree of a different type is straightforward. Optional and pointers provide limited scope for eliminating subtrees in a similar way. As for arbitrary transforms from type A to type B, this is probably the biggest open question for the library (IMO). Currently local value changes are pretty well supported within a framework of standard traversals which can be tweaked for certain types. To what extent the library can / should support traversals in which custom behaviour is required at the majority of the nodes is an area I'm currently giving thought to. Ideally I'd like to support at lot more use cases than this first iteration can manage, as things mature, and I incorporate feedback. Cheers Dan __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

2 1

Re: [boost] RFC Generic data structure traversal / manipulation library
by dan marsden 15 Jan '08

15 Jan '08

Larry Evans wrote: >Larry Evans wrote: >> dan marsden wrote: <snip> >> Page: >> >> http://spirit.sourceforge.net/dl_docs/traversal/html/traversal/quick_start_… >> >> contains: >> >> BOOST_FUSION_ADAPT_STRUCT(demo::dept, >> (std::string, name) >> (std::vector<demo::unit>, units)) >> >> I'm assuming demo is a namespace; yet, there's no declaration on that >> page. Also, although I could guess what >> >Sorry, hit wrong button. Continuing: > >Although I could guess what BOOST_FUSION_ADAPT_STRUCT does, it would >help to provide the reference: > >http://spirit.sourceforge.net/dl_more/fusion_v2/libs/fusion/doc/html/fusion… > >I couldn't find any doc on my local copy of fusion, and the boost.org >docs: > >http://www.boost.org/libs/libraries.htm > >had nothing; so, I had to search the mailing list for some location >before I found adapt_struct.html. Thanks for the various bits of feedback, I'm incorporating them into the documentation. If people are interested in the latest stuff, its current hosted in the Spirit Subversion repository at: https://spirit.svn.sourceforge.net/svnroot/spirit/branches/traversal/ I'll also aim to keep the online docs / source reasonably up to date as the library progresses. Cheers Dan ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

1 0

Re: [boost] [gacap]Is any interesting to "Generating All Combinations and Permutations"？
by hervebronnimann＠mac.com 15 Jan '08

15 Jan '08

Ben, Phil: happy new year. Yes, ben, proposal will only have functions, but boost can (and should) accept more. You can go ahaed and start integrating gacap into proposed boost library. I put it on the prviously mentioned web site, and can do a check into the subversion repo with my version and your changes when all is ready. HB Sent via BlackBerry from T-Mobile

1 0

[Interval] Bug when constructing from an unsigned integer type
by John Maddock 15 Jan '08

15 Jan '08

This compiles: boost::interval<double> in(1u); but creates a nonsense interval. IMO this should work? Likewise the same problem manifests itself when constructing from an unsigned long long (and in this case you really do want a true interval to be created). John.

2 6

Additions to Random/Math
by Andrew Sutton 15 Jan '08

15 Jan '08

I finally got around to committing my additions to the Random and Math libraries this morning. I haven't been able to make much progress since early december due to a) the holidays and b) a burning desire to graduate some time this decade - I've been working on my prospectus. Here's a quick summary of the commit. = Random = - Added 6 or 7 new distributions for random number generation - Added a new gamma distribution that correctly takes 2 parameters - Added a fixed lognormal distribution that correctly allows for a negative mean - Added a new program in libs/generator that will generate random numbers given a distribution and some parameters. Results are printed to cout and comparisons with the statistical distribution (in Boost.Math) are printed to cerr. Works nicely with gnuplot = Math = Added 2 new stubs of distributions (skew normal and geometric). Implemented an alternative version of the extreme_value distribution that supports both min and max variations. This is called extreme_value_i_distribution (i == 1). = What's Missing = Formal testing (outside of the generator tool above). Documentation I'll try to add missing features over the next couple months, but I can't make any guarantees. If authors are worried about "polluting" an existing project, I can easily re-extract them into a new top- level directory in the sandbox since there were no modifications to existing code. Andrew Sutton asutton(a)cs.kent.edu

2 3

[Threads] Dropped support for VC7.0 and earlier?
by John Maddock 15 Jan '08

15 Jan '08

Looks like Boost.Threads no longer compiles with VC7.0 and earlier, is this a deliberate change, or was it unintentional? Just checking, thanks, John.

2 1

the review of the switch library ends today, January 13th
by Stjepan Rajko 15 Jan '08

15 Jan '08

The review of the Switch library submitted by Steven Watanabe ends today (Sunday, January 13th). I would like to thank Steven for submitting a very useful library, as well as all those who have submitted reviews and/or contributed to the discussion (especially Tobias Schwinger and Joel de Guzman who have put in quite a bit of effort towards enhancing the design of the library). I will send a more detailed summary of the review as well as a decision in the following days. I currently have only 3 reviews to base a decision on, so any additional votes that anyone would like to contribute in the very near future would be very welcome. Regards, Stjepan

3 2

Re: [boost] [Boost-users] [switch_] Compound Cases [was Case Concept]
by Steven Watanabe 15 Jan '08

15 Jan '08

AMDG Joel de Guzman wrote: > Tobias Schwinger wrote: > > >>>> (c0,c1,...,cN) being just another 'Case' rather than a 'Sequence'. >>>> >>> o..k... Hmm.. so how would the resulting case object for this >>> expression look like: >>> >>> case_c<1>(f1), case_c<2>(f2) >>> >>> ? >>> >> template< class SeqCases > >> struct sequenced_case >> { >> <snip> >> > > Sounds good to me! I like it. So, this involves the variation where > a case has an MPL sequence of labels. I knew there's something in > that that I like. Intuition, I guess. That is also why I use the > name case_ regardless of number. A compound case is just another > case anyway. Does not matter how many labels it serves. > > Not sure how, implementation-wise, this works for Steven. Steven? > If this pans out, I'll refine the concept one more time. > It's trivial to implement: #define BOOST_SWITCH_CASE(z, n, data)\ case mpl::at_c<typename C::labels, n>::type::value: return(c.apply<R>(mpl::int_<n>())); My concern is 1) fall-through can't easily be added to the interface. 2) It seems like just another interface for a fusion sequence. Is sequenced_case to be public? If so, we need another concept for its interface... In Christ, Steven Watanabe

2 4

Re: [boost] Is there any interest in a template geometry library?
by 吴黄 15 Jan '08

15 Jan '08

------------------ 吴黄 2008-01-15 ------------------------------------------------------------- 发件人：Barend Gehrels 发送日期：2008-01-14 21:36:12 收件人：抄送：主题：[boost] Is there any interest in a template geometry library? Hi, Is there any interest in a template geometry library? I am a Chinese graduate student majoring CAD/CG in Hefei University of Technology, and I'm very interest in the template geometry library. The library we are developing is basic 2D geometry library. In this library, data structures are small and simple (but polygons can still have holes). Nevertheless, the library provides a lot of useful algorithms such as point-in-polygon, line intersections and polygon clipping. We at Geodan are developing our library since 1995, and recently restructured, simplified and enhanced the geometry core. Now that it is clean and well designed, and still with years of experience, we aim to publish it in Boost under the Boost Software License. How about is your experience now? How long to publish the library? I want to have a sight on the library as soon as possible. To give some impressions, points are like this: template <typename T> class point { (...) inline const T& x() const (...) inline const T& y() const (...) }; and lines are completely empty, like this: template <typename P> class linestring : public std::vector<P> { }; (Besides that you can also specify another container). Data and algorithms are separated, Why not to put the data and algorithms together for encapsulation? Because I think the parameter type which algorithm operates is very limited, not generic, just one or two. so there are algorithms like: template <typename P, typename POL> bool point_in_polygon(const P& p, const POL& pol); and like this: template <typename S1, typename S2, typename MP> intersection_result intersection_segment(const S1& segment1, const S2& segment2, MP& multipoint); but also generic wrappers like a "within" algorithm which is defined for all relevant geometry types template <typename P1, typename P2> inline bool within(const P& p, const polygon<P2>& poly) Because the library is completely templatized, you can use your own geometry types, and/or container types (provided that they follow the basic interface). The library follows std:: and boost:: standards and conventions, as well as the OGC (The Consortium on Standards in Geographical Information Systems) conventions. I know there have been discussions before on geometry libraries and on CGAL, e.g. http://lists.boost.org/Archives/boost/2007/03/117582.php. We are using boost in our library since about 2000. Where could i get the library and documentation from? If there is interest I will complete the documentation and examples according to Boost standards, and prepare a submission. Barend Gehrels ------------------------------------- Barend Gehrels ------------------------------------- Geodan Holding b.v. President Kennedylaan 1 1079 MB Amsterdam, the Netherlands ------------------------------------- E-mail: barend.gehrels(a)geodan.nl Website: www.geodan.nl ------------------------------------- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[random] uniform_int is biased
by Peter Dimov 14 Jan '08

14 Jan '08

I've observed that the sum of one million [-1..+1] random numbers produced by boost::uniform_int<> is consistently negative, usually between -3000 and -5000. Looking at the source reveals that the [0..N) -> [0..2] case, where N is 2^32, appears to be done with return (r / F) % 3, where F is 2^24. So, unless I'm missing something, this only uses 8 bits of the engine, and since 256 is not evenly divisible by 3, there is a slight bias of 1/256 which corresponds to -3906.25. Leaving aside the aggressive trimming of the low-order bits, which I believe is unnecessary when using mt19937 (is there ever a reason to use any other engine?) I still don't understand why we don't just use return r / K; where K is N / 3 and the values that exceed the target range are rejected to eliminate the bias entirely. This appears to simplify the code since (a) the separate "do we need rejection" test no longer needs to be done and is folded into the main case and (b) it uses the high-order bits, so it should work for LCGs as is.

1 0