- Boost - lists.boost.org

NEW lib: Named Variable - safe & convenient output of expressions together with their name
by M G 03 Jun '04

03 Jun '04

Greetings BOOST developers, the "Named Variable Lib" is a lightweight macro & template library which allows you to write: os << NV(character) << NV(std_string); os << NV(array_char_text) << NV(array_char_null); os << NV(p_float)<< NVP(p_float); p_float = 0; os << NVP(p_float); os << NV(the_answer_over_pi); os << NVB(((p_device==0) || f > 1.2) && name=="rsd0a"); to get e.g. character='A' std_string="test" array_char_text[]="text" array_char_null=NULL p_float=0012FD9C *p_float=1.234 p_float=NULL the_answer_over_pi=13.36901522 (((p_device_name==0) || f > 1.2) && name=="rsd0a")=1 written to the std::ostream os (" << std::endl" in C++ source omitted for better readability). Its main goal is to standardize the 5 macros NV,NVP,NVB,NVM,NVMP to let one output variable/expression together with their names conveniently (just one very short macro per expression) and safely (e.g. prevents os << "x1=" << x2;). Apart from that the NV concept could be used for other applications, where one needs a variable/expression and its name as a string. For more info & download of the library goto http://groups.yahoo.com/group/boost/files/Named%20Variable/ Feel free to try & comment ;-) Markus __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

weak_ptr doc problem
by Daniel Wallin 03 Jun '04

03 Jun '04

The weak_ptr docs says this: weak_ptr(); Effects: Constructs an **empty** weak_ptr. Postconditions: use_count() == 0. long use_count() const; Returns: if *this is **empty**, an unspecified nonnegative value; otherwise, the number of shared_ptr objects that share ownership with *this. use_count() seems underspecified and contradicts weak_ptr(). It should return exactly 0 when *this is empty. -- Daniel Wallin

2 1

RE: [boost] Proposed Boost Library for Data Series Analysis
by Tom Brinkman 03 Jun '04

03 Jun '04

Response to Matthew Hurd post: >> Efficiency is often paramount with these types of apps. Being able to do finite difference approaches, backwards and forwards, and in absolute terms is important (often you only want the latest data point). Agreed. >> You have the incremental case covered in your notes. Being able to calculate it at a point in an absolute sense, optional caching of results, working with series of unknown lengths and accuracy / validity enabling would be nice too. Agreed. >> By accuracy / validity enabling I mean, for say, your example of a 5 step moving average, it is not valid for the first four points as these are not an accurate average, so there is a length modification for the result. The value for the first four elements is invalid. The user has to adjust for this when they iterate over the returned vector. Example: (three day moving average) std::vector<double> out; std::transform(in.begin(), in.end(), std::back_inserter(out), moving_average(3)); out[0] = NA out[1] = NA out[2] = NA out[3] = NA std::transform(out.begin()+4, out.end(), std::cout << _1 << "\n"); >> Another simple example would be an exponential moving average where the number of significant digits required will determine how far back you need to go in the series. At another level, quality of service for some functors, the fast or accurate spectrum, is often appropriate. >> Perhaps expression templates might help here. Compile time results for validity calcs for series of known lengths would be helpful where possible. Agreed. Expression templates could be used very effecitively here. I will look into this. >> It would be nice if the algorithms could be simply specified, similar to your approach, and then "mounted" into the appropriate framework. Perhaps SFINAE or another technique could be used to determine an algorithm's capabilities. That is, the framework could juggle the most appropriate methods to use based on the results required. E.g. use incremental if you can otherwise absolute. >> Based on what I've done the past you also end up wanting arbitrary n-dimensional structures with other data types flowing through as well. Being able to associate ids/names with data items and keeping them associated through sorting/ranking. E.g. tag the series with data codes, rank them, and you can get the code for the best. You also want grouping n dimensional constructs and splitting dimensions and "slicing" operators that operate across the current dimension, which, with the appropriate framework, are one in the same. E.g. choose the minimum or sum the results of a bunch of functions. >> Then soon you want to split the computation amongst processors and machines and you want treat the computation as a dataflow graph and parallelise it some way, which I did a few years ago with BGL's precursor the GGCL. A topological sort gets you most of the way there... Also, you can then use things like Metis to partition your computation graph in nice ways. >> I think a way approach it would be an expression template approach with some adaptability in terms of absolute and incremental analytics with some accuracy (at least something like the number of points being chewed up and not valid or some such). Everything else could come on top of this. Sounds very powerful. Is there any additional web information to help me incorporate these ideas. >> You need to ensure that you can easily reuse code out there. No one wants to spend their life writing the zillions of numerical algorithms already out there. If you want a vector ARMA model, there are only a couple out there I think, and they are in FORTRAN, for example, wrap it, don't write it, I'd hope. Agreed. Thank you for your comments and spending the time to look at the library. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

Re: Boost Mathematicians
by Tom Brinkman 03 Jun '04

03 Jun '04

http://mathworld.wolfram.com/ Tens of thousands of visitors view MathWorld each day, and thousands of denizens of the mathematical and internet communities have contributed material over the last five years. As a result of this collaboration, MathWorld has grown to become the web's most extensive single source of educational and reference material about mathematics. If you havn't checked out this site you should take a quick look. I propose that we utilize the MathWorld community as the primary resource for ideas about our boost::math::algorithm library. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

static sized strings
by Martin 03 Jun '04

03 Jun '04

I have tested the sandbox version of the static sized strings. It works fine but there are a few inconveniences that I want to point out. 1. The abstract base class. --------------------------- Having an ABC to handle fixed strings of various lengths is a good idea but it is not very practical. I understand that the main purpose is to allow fixed strings to be passed to functions without using templates. int countwords(const boost::char_string & str); unfortunatly the ABC makes it difficult to pass anything but fixed strings. If you want to pass a string literal, a character array or a std::string you must create a temporary fixed_string<>. countwords(boost::fixed_string<20>("The quick brown fox")); Don't really have a good solution but maybe the base class could use an external buffer with constructors from char* and std::string. class char_string { const char* const extbuf; size_t len; protected: char_string() : extbuf(NULL) {} // not used since derived implements its own buffer public: char_string(const char* c) : extbuf(c), len(strlen(c)) {} char_string(const std::string& str) : extbuf(str.c_str()), len(str.length()) {} ... // virtual basic_string interface } Don't know how to handle non-const char[]. 2. Substrings ------------- One of the applications I can see for fixed_string is when you want to avoid dynamic allocation but still want to use the std::string interface and algorithms. In that perspective it seems strange that substr returns a std::string instead of a fixed_string. 3. resize --------- Still missing a method to update the length to reflect the current string length. I think a resize without arguments would be a good solution. boost::fixed_string str<10> strtime(str.buffer()); str.resize(); 4. operator[] ------------------------- I don't have the standard basic_string interface available but I am pretty sure that operator[] doesn't throw an exception if the argument is outside max_size(). I also looked at the alternative fixed_string implemenatation but since that version doesn't have full std::string interface I didn't test it. I am not sure I like the lazy length calculation for two reasons. - In my view, strlen is normally a "cheap" operation comparable to a function call. If the lazy evaluation prevents a function from being inlined, the benefit is lost. - It is tricky to detect when the length is invalid. With the current implementation, I can't say if the length is valid or not after "str[4] = str [5]" since that depends on the order of evaluation of "str[4]" and "str[5]".

1 0

RE: [boost] Re: Re: Boost Mathematicians
by Hurd, Matthew 03 Jun '04

03 Jun '04

> Behalf Of Thorsten Ottosen > Sent: Thursday, 3 June 2004 4:25 PM > > > "Reid Sweatman" <drunkardswalk(a)earthlink.net> wrote in message > > | Oddly enough, scientists is usually pretty > | conservative folk; they like what they know. > > Is that so odd? Yesterday I talked with a matematician here in Sydney about > Fortran. > He uses Fortran because it is good enough for what he is doing. It would > probably take quite some > time for him to learn C++, so why should he? > > br > > Thorsten There is an often seen misconception that C/C++ should be as fast as it gets as the programming model is close to the instruction model of the machine. In practice FORTRAN is usually faster. At one level, in C++ this slowness this is usually because of temporaries and expression templates and modern optimizing compilers can often mitigate this for typical math calcs. Other abstraction penalties apply. Another level is the fundamental differences in aliasing between the language definitions. FORTRAN as a language does not allow aliasing ambiguities which makes the optimizers job a lot easier and the code can be a lot faster. C/C++ assumes aliasing potential which makes optimizing very hard. A C/C++ compiler may allow aliasing to be disabled for a section of code or for the whole program, but you need to be confident in what you are doing. Very clever global analysis is needed to cure the aliasing problem, and given the potential for run time gymnastics, it may not be possible at all. Have a look at these benchmarks judging Todd V's blitz to FORTRAN: http://www.oonumerics.org/blitz/benchmarks/ Boost's equivalent to Blitz++ is uBLAs. More discussion on C++ versus FORTRAN speed can be found here: http://osl.iu.edu/~tveldhui/papers/iscope97/ I do think it is worthwhile writing C++ to do this stuff as the abstraction is much better for the library client IMO. At some levels the implementation may be tougher for the library writer, as some of the optimizer gymnastics ends up in the expression templates, but given the right framework it may be simply extensible and suitable for even relatively unsophisticated mathematicians to contribute library components. You still need to wrap as you can't hope, nor should you try, to offer all algorithms from all languages. Another lobbed $0.005, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna Sydney _______________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[test] [minmax] failure on gcc 2.95
by Vladimir Prus 03 Jun '04

03 Jun '04

As shown in http://tinyurl.com/3xdyq, Boost.Test fails to build on gcc 2.95 with stlport. The error message is: /boost/head-regression/boost/boost/minmax.hpp: In function `const size_t & boost::std_min<size_t>(const size_t &, const size_t &)': /boost/head-regression/boost/libs/test/build/../src/test_tools.cpp:375: instantiated from here /boost/head-regression/boost/boost/minmax.hpp:26: `min' undeclared (first use this function) Is it possible that authors of either Boost.Test or boost/minmax.hpp take care of this error? Thanks, Volodya

1 0

Borland settings different between Boost and IDE ?
by Nicola Musatti 03 Jun '04

03 Jun '04

Hallo, is it possible that Boost libraries use a different setting for enum handling than the BCB IDE default one? I'm having problems which seem related to enums and the inclusion of some Boost headers in precompiled headers. Cheers, Nicola Musatti

2 2

[program_options] Darwin failure help?
by Vladimir Prus 03 Jun '04

03 Jun '04

The program options library now fails a single test on Darwin, with this output: ../libs/program_options/test/parsers_test.cpp(205): fatal error in "call_test_main": test p.options.size() == 1 failed *** 1 failure detected in test case "call_test_main" The code in question is: putenv("PO_TEST_FOO=1"); parsed_options p = parse_environment(desc, "PO_TEST_"); BOOST_REQUIRE(p.options.size() == 1); So, it seems that after "putenv", the string is is not available in the 'environ' variable. The variable is declared like this: #if defined(__APPLE__) && defined(__DYNAMIC__) #include <crt_externs.h> static char** environ = *_NSGetEnviron(); #else extern char** environ; #endif The Darwin-specific conditinal was sent by Michael LaSpina, so I don't know what it really does, and so don't know why the test fails. I'd appreciate any suggestions. Thanks in advance, Volodya

2 2

RE: [boost] Proposed Boost Library for Data Series Analysis
by Hurd, Matthew 02 Jun '04

02 Jun '04

> -----Original Message----- > Behalf Of Tom Brinkman > Subject: [boost] Proposed Boost Library for Data Series Analysis > > I placed a small tutorial and motivating example for > the proposed boost::data_series library. > > http://groups.yahoo.com/group/boost/files/data_series/ > > Working examples for you to criticize will be added > within the week. Cute code. Nice job. Efficiency is often paramount with these types of apps. Being able to do finite difference approaches, backwards and forwards, and in absolute terms is important (often you only want the latest data point). You have the incremental case covered in your notes. Being able to calculate it at a point in an absolute sense, optional caching of results, working with series of unknown lengths and accuracy / validity enabling would be nice too. By accuracy / validity enabling I mean, for say, your example of a 5 step moving average, it is not valid for the first four points as these are not an accurate average, so there is a length modification for the result. Another simple example would be an exponential moving average where the number of significant digits required will determine how far back you need to go in the series. At another level, quality of service for some functors, the fast or accurate spectrum, is often appropriate. Perhaps expression templates might help here. Compile time results for validity calcs for series of known lengths would be helpful where possible. It would be nice if the algorithms could be simply specified, similar to your approach, and then "mounted" into the appropriate framework. Perhaps SFINAE or another technique could be used to determine an algorithm's capabilities. That is, the framework could juggle the most appropriate methods to use based on the results required. E.g. use incremental if you can otherwise absolute. Based on what I've done the past you also end up wanting arbitrary n-dimensional structures with other data types flowing through as well. Being able to associate ids/names with data items and keeping them associated through sorting/ranking. E.g. tag the series with data codes, rank them, and you can get the code for the best. You also want grouping n dimensional constructs and splitting dimensions and "slicing" operators that operate across the current dimension, which, with the appropriate framework, are one in the same. E.g. choose the minimum or sum the results of a bunch of functions. Then soon you want to split the computation amongst processors and machines and you want treat the computation as a dataflow graph and parallelise it some way, which I did a few years ago with BGL's precursor the GGCL. A topological sort gets you most of the way there... Also, you can then use things like Metis to partition your computation graph in nice ways. I think a way approach it would be an expression template approach with some adaptability in terms of absolute and incremental analytics with some accuracy (at least something like the number of points being chewed up and not valid or some such). Everything else could come on top of this. You need to ensure that you can easily reuse code out there. No one wants to spend their life writing the zillions of numerical algorithms already out there. If you want a vector ARMA model, there are only a couple out there I think, and they are in FORTRAN, for example, wrap it, don't write it, I'd hope. You end up with run time versus compile time issues. People want to interact with this kind of stuff. However, my take on that now is do it at compile time and include the compiler as part of your interactive tools set if need be :-) Anyhow, it is nice to see a start on this. Good luck. $0.005, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0