- Boost - lists.boost.org

Re: [boost] Request for interest in new library : Bit Logic
by Art Stamness 01 Feb '07

01 Feb '07

(oops hit reply-to-sender, not list ) Begin forwarded message: > From: Art Stamness <artstamness(a)yahoo.com> > Date: January 31, 2007 5:11:21 PM PST > To: me22 <me22.ca(a)gmail.com> > Subject: Re: [boost] Request for interest in new library : Bit Logic > > On Jan 31, 2007, at 4:21 PM, me22 wrote: > >> On 1/31/07, Art Stamness <artstamness(a)yahoo.com> wrote: >>> Any feedback, positive, negative, suggestions is always appreciated. >>> Also if there is a better suggestion for a name, I am open to it. I >>> realize the Boost.Logic library has a very different purpose than >>> this one, and don't want them to be confused. >>> >> Boost.Bitwise, maybe? >> >> Typo: http://www.emulogic.com/bit_logic/bit_vector/index.html >> "middle of the container is dones in" > > Thanks, corrected now. > >> Regarding the implementation, smallest_bit_storage would probably be >> better off using Boost.Integer's facilities or a trick like is using >> in uint_t to avoid requiring the specifically-sized types. > > Those types are limited by the largest integral type of the system. > This library is intended for modeling small and large types. I > should have made it more clear in the examples in the > documentation. Ex. a bit_array<100> is a perfectly valid type. > while a boost::int_t<100> is not. > >> However, what's the main advantage of your code over >> Boost.Dynamic_Bitset and std::bitset? It seems (from a quick look) >> that your bit_array is close to std::bitset and your bit_vector is >> close to at least one of dynamic_bitset and vector<bool> (the latter >> being specialised for packing). > > True, these types are similar to the std::bitset / > boost::dynamic_bitset / std::vector<bool> in that they are used to > represent bit data. However they have a very different operational > semantic. These types are intended to model bit containers for > arbitrary logic functions. Things that are commonly found when > modeling hardware systems ( you can find why i do this under the > "Motivation" section ). > > For instance, taking 4 bits from one type and 4 bits from another, > doing a logical exclusive-or on those bits, and placing it in 4 > bits of a third type is a 1 line operation. > > c.select(15,12) = a.select(7,4) ^ b.select(3,0) ; // a,b,c can all > be bit_array / bit_vector / bit_container ( adapted type ) > > This very closely mimics what is found in hardware description > languages ( which is my background ) . > > c[15:12] = a[7:4] ^ b[3:0] ; // Same operation in Verilog > > This library is intended to provide fixed , and resizable types, > that can be used to model n-bit long logical operations in a clear > semantic description, while also providing some STL container like > interface for use with STL algorithm. > > The above listed operations would be very difficult to do with any > of the 3 listed types. > > Thank you for taking the time to look and comment, I hope I have > answered your questions. > > -Art >

2 2

[thread] regressions for msvc-8.0 x64
by Roland Schwarz 01 Feb '07

01 Feb '07

I am unsure how this "regression" should be handled. Since this _is_ a new compiler it is not really a regression, but on the other hand the compilers toolset name is the same as for x32. 1) Is there a way to explicitly markup as expected to fail conditioned on x64 ? 2) I do not have yet an x64 compiler so I will not be able to implement the tss cleanup for static linking for 1.34. I'll do this later. Roland

2 2

Re: [boost] whitespace and user-defined types in lexical_cast
by Alexander Nasonov 01 Feb '07

01 Feb '07

30.01.07, 21:03, John Salmon <john(a)thesalmons.org>: > The patch satisfies that test on my system (Linux, gcc-3.3.3). I was > surprised that such a test was not already in the regression suite. > Something like it obviously should be, so I added some very similar > tests just to be sure. These are in the original patch: Thanks. I'll add them. > Yes. There have been a few discussions over the years. There are two > basic themes: > 1 - somebody thinks that lexical_cast ought to work on a type whose > operator>> isn't smart enough to handle a non-default skipws flag. > The response is typically "your operator>> is broken", followed by > more or less discussion about whether lexical_cast should accommodate > "broken" operator>> anyway. We are repeating this theme. > 2 - a desire for consistency between the handling of leading > whitespace and trailing whitespace. > I would suggest that the fact that questions of type 1 keep coming up > is an indication that the current behavior is surprising and > alternatives should be explored. If we can change it so that it is > less surprising to "newbies" without breaking anything else and > without introducing new complexity, I think we should. OK. > I would suggest that the answer to questions of type 2 is to observe > that it's not trailing whitespace that causes the exception, it's > trailing *anything*. As such, it should be clearly documented. In > fact, the proposed text for the specification of lexical_cast in TR2 > makes this very clear. I'll make sure it's documented in boost. > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1973.html Thanks for reminding me of this text. I found few inconsistencies with the boost documentation. -- Alexander Nasonov

1 0

Regression count further dropping down ...
by Roland Schwarz 01 Feb '07

01 Feb '07

Most of the issues of borland-5.8.2 and msvc-6.5 have been resolved. 1) The next major candidate seems to be: intel-linux-9.0 Anyone working on this already? 2) msvc-6.5 test library Joaquin has provided a patch for which I asked Gennadiy for permission to apply. Roland

1 0

Accumulators review
by John Maddock 01 Feb '07

01 Feb '07

This is the first part, of what will probably end up a multi-part review. First the headline - I do think that the library should be included in Boost - although I do have some reservations as noted below. This part-review covers the documentation and a few simple tests I've conducted. Later I'll try writing some accumulators so that I can comment better on the design. Documentation review ~~~~~~~~~~~~~~~~~~~ Tutorial: ~~~~~~~~~ I'm fairly sure that the whole accumulator_set_wrapper business could be completely avoided with a TR1 conforming reference_wrapper - which unfortunately we don't have in Boost just yet - none the less this may be worthwhile mentioning. The "push all the data in this sequence" idiom seems like a very common use case to me, is it not worthwhile supporting this directly via a couple of member functions: template <class It> accumulator_set& accumulator_set::push_range(It begin, It end); template <class Seq> accumulator_set& accumulator_set::push_sequence(Seq const& s); Typo in "This will calcualte the left" Statistic accumulators: ~~~~~~~~~~~~~~~~~~~~~~ Kurtosis ~~~~~~~~ This is going to confuse folks - I know it's got Paul and I into trouble already! You're returning the "Kurtosis Excess" rather than the "Kurtosis Proper". In the Math Toolkit stats functions we called these functions "kurtosis" and "kurtosis_excess", and I'd favour similar naming here, or at least a strong warning to the effect that there are multiple definitions in the literature - otherwise unwary users will get into all kinds of trouble. Differing implementations? ~~~~~~~~~~~~~~~~~~~~~~~~~~ feature_of and as_feature get mentioned in the tutorial, along with a sentence to say that there can be different implementations of the same feature, but there is no explanation of how this works, and the links to the reference pages for as_feature and feature_of are distinctly detail free :-( This all leads on to the algorithms used for the mean and variance etc: I assume that these are of the "naive" variety? Perfectly satisfactory for simple cases, but there are well known pathological situations where these fail. I'm also missing accessors for: the standard deviation, "unbiased" variance, and the unbiased (N-1) standard deviation. I realise I could write these myself, but they would seem to be common enough cases to warrant inclusion in the library. As it stands, I had to jump through hoops to get data I could compare with "known good values". BTW, I assume that there are no accumulators for Autocorrelation Coefficient calculation? Which leads on to a quick comparison I ran against the "known good" data here: http://www.itl.nist.gov/div898/strd/univ/homepage.html The test program is attached, and outputs the relative error in the statistics calculated. Each test is progressively harder than the previous one, the output is: PI data: Error in mean is: 0 Error in SD is: 3.09757e-016 Lottery data: Error in mean is: 6.57202e-016 Error in SD is: 0 Accumulator 2 data: Error in mean is: 9.25186e-015 Error in SD is: 2.71685e-012 Accumulator 3 data: Error in mean is: 5.82076e-016 Error in SD is: 0.0717315 Accumulator 4 data: Error in mean is: 9.87202e-015 Error in SD is: -1.#IND As you can see the calculated standard deviation gets progressively worse, in the final case, the computed variance is actually -2, which is clearly non-sensical (and hence the NaN when using it to compute the standard deviation) :-( I haven't tried to debug these cases: stepping through the accumulator code is not something I would recommend to anyone frankly (having tried it previously). No doubt other torture tests could be constructed for the mean - exponentially distributed data where you see one or two large values, followed by a large number of very tiny values springs to mind - this is the sort of situation that the Kahan summation algorithm gets employed for. I'm not sure what one should do about this. These certainly illustrate the kinds of trap that the unwary can fall into. It's particularly a problem for the "scientist in a rush" who may not be either a C++ or statistical expert (whether (s)he thinks they are or not!) but needs a library to quickly and reliably calculate some stats. Better documentation would certainly help, but guidance on (or provision of - perhaps by default) better algorithms might be welcome as well. That's all for now, Regards, John.

6 20

request to patch libs/serialization/build/Jamfile.v2 for support of msvc-6.5
by Roland Schwarz 01 Feb '07

01 Feb '07

I tried to port parts of the libs/serialization/build/serialization.jam to bbv2 for better support of the msvc-6.5 compiler. I am currently running a regression which seems to have far lower failing tests. To build with this compiler it is necessary to check out the SPIRIT_RC_1_6_2 branch to a directory first. In the environmet or better in site-config the statement path-constant SPIRIT_RC_1_6_2 : "H:/Projects/boost/SPIRIT_RC_1_6_2" ; has to be added. Of course the shown path needs to be replaced with your checkout path. (Forgetting to do this will emit an error message with instructions.) Unfortunately this approach does not help with borland-8.5.2 because it still does not compile with SPIRIT_RC_1_6_2 in place. Any help on this highly appreciated! (patch attached) Roland ? patch.diff Index: Jamfile.v2 =================================================================== RCS file: /cvsroot/boost/boost/libs/serialization/build/Jamfile.v2,v retrieving revision 1.7 diff -u -r1.7 Jamfile.v2 --- Jamfile.v2 6 Mar 2006 08:20:39 -0000 1.7 +++ Jamfile.v2 26 Jan 2007 19:47:47 -0000 @@ -8,6 +8,8 @@ project boost/serialization : source-location ../src + : requirements + <conditional>@require-boost-spirit-support ; SOURCES = @@ -68,3 +70,32 @@ : : <link>shared:<define>BOOST_SERIALIZATION_DYN_LINK=1 ; + +# building this library needs the 1.6 version of spirit +# for certain compilers +rule require-boost-spirit-support ( properties * ) +{ + local result ; + local req-legacy = false ; + + if <toolset-msvc:version>6.5 in $(properties) { req-legacy = true ; } + if <toolset-borland:version>8.5.2 in $(properties) { req-legacy = true ; } + + if $(req-legacy) = true + { + if $(SPIRIT_RC_1_6_2) { + # using the <cxxflags> for include will ensure it comes before + # the regular boost includes + result += <cxxflags>-I$(SPIRIT_RC_1_6_2) ; + } + else { + echo "**** spirit 1.6x required to build serialization library with this compiler ****" ; + echo "**** You wil need to get branch SPIRIT_RC_1_6_2 from CVS and add ****" ; + echo "**** path-constant SPIRIT_RC_1_6_2 : your_path_to_checked_out_branch ; ****" ; + echo "**** to site-config.jam . ==> skipping build for now. ****" ; + result += <build>no ; + } + } + + return $(result) ; +}

7 17

[Boost-bugs] [ boost-Feature Requests-1649241 ] PocketPC 2003/2005 MSVS8
by SourceForge.net 31 Jan '07

31 Jan '07

Feature Requests item #1649241, was opened at 2007-01-31 14:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1649241&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PocketPC 2003/2005 MSVS8 Initial Comment: There is any support to build boost for use it on MSVS8 for PocketPC 2003 and 2005?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1649241&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [Review] Review of the Accumulators library begins today Jan 29
by Steven Watanabe 31 Jan '07

31 Jan '07

AMDG Eric Niebler wrote: > Hi, Steven, > > Steven Watanabe wrote: > >> accumulators.qbk lines 35-37 >> [def _mpl_ [@../../libs/mpl MPL]] >> [def _mpl_lambda_expression_ >> [@../../libs/mpl/doc/refmanual/lambda-expression.html MPL Lambda >> Expression]] >> [def _parameters_ [@../../libs/parameters Boost.Parameters]] >> these links are bad >> > > > Thanks. I think I was overly-optimistic when I wrote that. The links > would work if Accumulators were in it's rightful (a-hem) place in the > Boost tree. ;-) > unless I missed something libs/accumulators/doc/../../libs/ == libs/libs/ Which I think is not what you intend. Somehow in the user_s_guide.html this becomes libs/accumulators/libs/ I'm not quite sure whether this is a quickbook bug or the file was built as though it were in libs/accumulators/doc/html/ > >> post_construct() >> Unless for some obscure reason that I am missing it is just >> too difficult, I would strongly prefer to make sure the constructors >> are called in the correct order. >> >> The whole dance with fusion::vector is unnecessary. >> It would be simpler to use >> struct accumulator_tuple_base { >> template<class Args> >> accumulator_tuple(const Args&) {} >> } >> template<class T, class Base> >> struct accumulator_tuple : T, Base { >> template<class Args> >> accumulator_tuple(const Args& args) : T(args), Base(args) {} >> }; >> Since every accumulator is put before all the >> accumulators that depend on it in make_accumulator_tuple >> you can write >> typedef >> typename mpl::reverse_fold< >> sorted_accumulator_vector >> , accumulator_tuple_base >> , accumulator_tuple<mpl::_2, mpl::_1> >> >::type >> type; >> Then every accumulator is constructed after any >> others that it depends on. As a bonus the only >> limit to the number of accumulators is whatever >> the compiler can handle. >> > > > > This would be a valid design choice, but it would involve reinventing a > lot of Fusion. I use Fusion both to generate the accumulator set, to > process the accumulators, and to find accumulators that match Fusion > predicates. Code reuse is good. > I'm not suggesting that you reinvent the fusion algorithms. I just think that fusion::vector is not necessarily a good sequence to use when the constructor parameters are all identical. Also if you write the sequence then you can guarantee the order of initialization. template<class From, class To> struct match_cv : mpl::if_<is_const<From>, const To, To> {}; struct accumulator_set_tag {}; struct accumulator_set_impl_base { typedef accumulator_set_tag fusion_tag; template<class Args> accumulator_set_impl(const Args&) {} } template<class T, class Base> struct accumulator_set_impl : T, Base { typedef T value_type; typedef Base next_type; accumulator_set_impl(const accumulator_set_impl& other) : T(static_cast<const T&>(other)), Base(static_cast<Base&>(other)) {} template<class Args> accumulator_set_impl(const Args& args) : T(args), Base(args) {} }; struct accumulator_set_iterator_tag {}; template<class Set> struct accumulator_set_iterator { typedef accumulator_set_iterator_tag fusion_tag; accumulator_set_iterator(Set& s) : set(s) {} Set& set; }; template<> struct boost::fusion::extension::begin_impl<accumulator_set_tag> { template<class Set> struct apply { typedef accumulator_set_iterator<Set> type; type call(Set& set) { return(type(set)); } }; }; template<> struct boost::fusion::extension::end_impl<accumulator_set_tag> { template<class Set> struct apply { typedef accumulator_set_iterator<typename match_cv<Set, accumulator_set_impl_base>::type> type; type call(Set& set) { return(type(set)); } }; }; template<> struct boost::fusion::extension::next_impl<accumulator_set_iterator_tag> { template<class Iterator> struct apply { typedef typename T::set_type set_type; typedef accumulator_set_iterator< typename match_cv<set_type, typename set_type::next_type>::type& > type; type call(Set& set) { return(set.set); } }; }; template<> struct boost::fusion::extension::deref_impl<accumulator_set_iterator_tag> { template<class Iterator> struct apply { typedef typename T::set_type set_type; typedef typename match_cv<set_type, typename set_type::value_type>::type& type; type call(Set& set) { return(static_cast<type>(set.set)); } }; }; > Regarding post_process(), I decided at the time, after discussing this > with Joel de Guzman (of Fusion) and Dave Abrahams, that relying on the > construction order of accumulators within a set would be a mistake. It > would rule out size optimizations like compressed_pair, where empty > accumulators are optimized away via the Empty Base Optimization. Fusion > doesn't do this optimization today, but it may in the future. > But EBCO can't help you anyway. Two distinct sub objects of the same type (accumulator_base) cannot share the same address. I assumed that you didn't want to rely on fusion initializing the elements in order, that was part of the reason I suggested rolling your own fusion sequence. > > >> What happens if you freeze a feature that another feature depends on? >> #include <iostream> >> #include <boost/accumulators/accumulators.hpp> >> #include <boost/accumulators/statistics/mean.hpp> >> #include <boost/accumulators/statistics/sum.hpp> >> >> using namespace boost::accumulators; >> >> int main() { >> accumulator_set<double, features<tag::mean, droppable<tag::sum> >> > > accum_set; >> accum_set(1.0); >> accum_set(2.0); >> accum_set.drop<tag::sum>(); >> accum_set(3.0); >> std::cout << mean(accum_set) << std::endl; //prints 1 >> } >> This behavior can easily cause surprises. It must >> be fixed to print 2. I'm not quite sure how to implement >> it correctly. I think that probably you need to store the >> result at the point that drop is called for external lookup >> and continue to collect data for internal usage. Of course, >> this only applies in the face of dependencies. >> > > > The code is doing something a little unusual, but the result looks > correct to me. What do you think the result should be, and why? > The result should be 2 because 1.0 + 2.0 + 3.0 / 3 = 2.0 Users of particular accumulators should not have to care about the internal dependencies. The mean should return the mean of all the values that have been added regardless of whether count/sum have been dropped. > >> accumulators_fwd.hpp #define's >> FUSION_MAX_VECTOR_SIZE/FUSION_MAX_TUPLE_SIZE >> This is a very bad idea as it might make >> make the value smaller than it would otherwise >> have been. Please just check FUSION_MAX_VECTOR_SIZE >> and issue a #error directive if it is too small. >> > > > I had it that way at first, but changed it due to user feedback. The > idea is to make it so that you can just #define > BOOST_ACCUMULATORS_MAX_FEATURES and not have to worry about configuring > Fusion. > > > Consider. file a.cpp #include <boost/accumulators/accumulators.hpp> #include <boost/fusion/sequence/container/vector.hpp> file b.cpp #include <boost/fusion/sequence/container/vector.hpp> #include <boost/accumulators/accumulators.hpp> I'm not absolutely certain that this actually causes a problem with ODR, but even if it doesn't now it is very fragile. > >> The docs need to state clearly what happens when >> more than one accumulator maps to the same feature. >> > > > Right. The first accumulator with a particular feature is the one that > gets used. Any others with the same feature are ignored. > And the ones that are specified in the sequence are processed before those found indirectly. In Christ, Steven Watanabe

3 2

[graph] subgraph problems
by Hailin Jin 31 Jan '07

31 Jan '07

I compiled and ran the subgraph.cpp which comes with the library (in example directory). I got results which are different from subgraph.expected. Here are my outputs: G0: 0 --> 1 1 --> 2 3 2 --> 5 3 --> 4 --> 1 5 5 --> 3 0(0,1) 1(1,2) 2(1,3) 6(2,5) 3(4,1) 4(4,5) 5(5,3) G1: 0 --> 2 1 --> 2 2 --> 6(0,2) 4(1,2) G2: 0 --> 1 1 --> 0(0,1) I also have a question: in the output, the indices for the both subgraphs start from 0 which makes sense to me. However, why don't the edge index start from 0, as well? It looks like the edge index matches their corresponding indices in the main graph. I don't think it makes sense. Moreover, it creates problems when I try to attach properties to edges because the maximum edge index for a subgraph is larger than the number of edges in that subgraph. Thanks. Hailin

1 0

Re: [boost] [Review] Review of the Accumulators library beginstoday Jan 29
by Steven Watanabe 31 Jan '07

31 Jan '07

AMDG "John Maddock" wrote: > Right: and for some accumulators the addition of two accumulators may not be > possible at all. But can't we make this a conceptual requirement that if > you try and combine two accumulator sets, then each accumulator must have a > "combine" method (otherwise you get a compile time error). The "combine" > methods for min/max/sum/count etc are all trivial aren't they - and could be > added fairly easily ? But Eric would know the details :-) > > John. Why not let accumulator_set support a fusion sequence interface? Then combine/reset could be implemented using fusion::for_each, right? In Christ, Steven Watanabe

1 0