- Boost - lists.boost.org

Fisher Exact test in boost ?
by Jean-Baptiste Cazier 28 Jul '10

28 Jul '10

Dear all, I am brand new to this mailing list so I apologize in advance for the naivety of my request. I am looking for an implementation of the Fisher exact test in C/C++, and was somehow hoping to find one in boost. I have looked at the documentation of boost and and found many statistical tools, but not the one I am looking for. The closest I got was a discussion in the mailing archive in 2008 on the use of the hypergeometric distribution to perform such implementation Was any progress made since then ? Could I now get the cdf, pmf and sf from an hypergeometric distribution ? or even better a Fisher exact test directly ? Any help will be welcome Thanks Cheers ! Jean-Baptiste

2 4

Re: [boost] [GIL] bits64
by fabien.castan＠free.fr 28 Jul '10

28 Jul '10

> I have been promoting the idea of people contributing any new functionality > of GIL that they find useful by creating a GIL extension that is not > originally in boost. This allows for an opportunity for people to try their > code, flesh out some bugs, suggest changes to the design, etc. We can also > use this as a mechanism to see how popular certain functionality is and use > that to decide which functionality will make it into boost. That way, by the > time it is proposed for inclusion into boost, the code will be more solid. Yes, I have seen it, I use it, and hope to propose new things one day. But adding typedefs is not adding new functionalities. It's the normal usage of the library. If there is a bug here, it's a bug in gil itself not in the added code... So I define it in my code and use it without problem. Maybe we can add those typedefs at least in gil extensions ? If you want I can send you the code.

1 0

[context] user-context switching
by Oliver Kowalke 27 Jul '10

27 Jul '10

I've moved the context switching code from boost.fiber into a new lib - boost.context (uploaded to boost vault). The lib contains assembler for some platforms: i386, x86_64 and arm (aapcs-linux only). It could be used for code implementing cooperative scheduling (such as boost.coroutine and boost.fiber). Oliver

1 0

[gsoc][RFC] Pointer Plus Bits
by Brian Bartman 27 Jul '10

27 Jul '10

Hello, I previously sent out an email to the list about a pointer plus bits like data structure and received some feedback about a pointer plus bits data structure. After taking into consideration all of the different points of view, comments and concerns voiced by the Boost community I have implemented an extension to my bitfield_tuple which allows the user to easily store parts of a pointer and use the extra bits for storage. Here is a basic overview of the bitfield_tuple: Its a tuple like data structure which stores bitfields instead of whole types inside of single tuple. This allows the user to skirt packing limitations of structs and classes in C++ and create bitfields over the storage type of their choice OR leave that decision up to the data structure (the behavior for selecting the storage type is to select the smallest possible unsigned integral type which will hold the all of the bitfields). example of basic bitfield_tuple declaration. #include<boost/integer/bitfield_tuple.hpp> struct red; struct green; struct blue; using namespace boost; using namespace boost::bitfields; typedef bitfield_tuple< member<unsigned char, red, 5>, member<char, green, 6>, member<unsigned int, blue,5> > rgb565_t; The bitfield_tuple takes ordered named template parameters (In the case of the storage type order is ignored. IE no matter where you put the storage< type > template the ending result will be the same). the bitfield_tuple supports the following template named template parameters (all of the templates which follow are located within the boost::bitfields namespace): bit_align< std::size_t> -> increases the offset of the next field to an offset which is divisible by the supplied value unless the current index is divisible by the supplied value then there is no increase. filler<std::size_t> -> bits to be skipped. member<typename, typename, std::size_t> -> this is a basic bitfield parameters it takes are the type the bitfield is to return, a naming type and the width of a bitfield flag<typename> -> boolean version of member. storage<typename> -> uses the supplied type for internal storage. pointer<typename, typename, typename> -> NEW described below. Pointer Member Information: The pointer member takes three template parameters. 1) The type you would like to make a pointer to. 2) The name which can be used (instead of an index, index is also still available to use) to access the pointer. 3) This is an integral_constant or integral_constant like type which is used to make a mask over the value bits of the pointer. This has a default value to leave the last two bits open. You can use leading or ending bits of the pointer for storage by supplying a different mask. Reasoning behind allowing for leading storage bits. There are some systems which do low address allocations and then store values within the higher part of the address. While this is much more rare then the use case of stuffing two bits inside of the end of a pointer I felt that it would be best to provide a way to actually do this. Reasoning behind restricting the mask to an integral_constant or integral_constant like type. The intent for this is to associate a non deduced type with the mask itself, however if people feel better simply using hex to specify the mask I could change the behavior to do that. There are mask creation utilities which can be used to create the mask from a higher level the simply supplying hex. Here are some examples of how to declare a bitfield_tuple with a pointer member: #include <boost/integer/bitfield_tuple.hpp> #include <boost/assert.hpp> using namespace boost; using namespace boost::bitfields; struct ptr; struct color; struct i1; struct i2; typedef bitfield_tuple< pointer<int, ptr> > ptr_1; typedef bitfield_tuple< pointer<int, ptr>, flag<b1>, flag<b2> > ptr_plus_two_bools; typedef bitfield_tuple< pointer<int, ptr>, member<unsigned int,color,2> > ptr_plus_two_bit_color; int main() { ptr_1 p1; int i = 10; p1.get<0>() = &i; BOOST_ASSERT(*p1.get<ptr>() == 10); ptr_plus_two_bools p2; p2.get<ptr>() = &i; ptr.get<b1>() = true; ptr.get<2>() = false; ptr_plus_two_bit_color p3; p3.get<ptr>() = &i; p3.get<color>() = 3; return 0; } The pointer does NOT have to be the first parameter of the bitfield tuple one can simply place things in front of the the pointer and the value mask of the pointer will not be affected. The only thing which is different when this is done is the offset of the pointer within the bitfield_tuples storage, this only changes the location of the bitfield where the pointer is actually being stored. That being said you will always receive the value bits of the pointer in the exact same way they were taken from inside the pointer. -- thanks, Brian Bartman

4 16

Question about boost license
by Marc Elias 27 Jul '10

27 Jul '10

Hello, Allow me to introduce myself, my name is Marc and I would like to use the boost libraries to perform some work on a software with commercial profit. I have some questions about Boost License Policy I would like to know. As I can read in your webpage, most of the Boost libraries are under a single license that allows me to use the libraries for commercial purposes following the instructions you provide in the webpage. You also inform in the webpage that some libraries are under their own licenses. I would like to know, if it's possible, which libraries are under particular licenses and which are these specific licenses. Is it possible to have this information? Thanks a lot for your help. MARC _________________________________________________________________ Accede a tu Hotmail en un solo clic ¡Descárgate Internet Explorer 8 y empieza a disfrutar de todas las ventajas! http://www.ayudartepodria.com/

5 4

Review request: XInt
by Chad Nelson 26 Jul '10

26 Jul '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am officially requesting a formal review for the Extended Integer library (a arbitrary-length integer math library). The final review version is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). Thanks to everyone who offered suggestions and comments. It's a lot better for them, and likely a lot more useful. Here's hoping for a positive and speedy review. :-) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw9BTYACgkQp9x9jeZ9/wQX+gCgi1N29anc96B6EX+pZ5rgrvyu d8wAnjfHyu5JQVMVu6BFQPtYExG3SbZR =25L3 -----END PGP SIGNATURE-----

2 3

New name of bjam.exe
by Vladimir Prus 26 Jul '10

26 Jul '10

Boosters, I am sure that most of you got accustomed to typing "bjam" in console whenever you want to build things. This name is old, and derives from a tool named "jam", which is even older (around for maybe 20 years). However, this name is probably no longer good. First, having a single project be identified by both "Boost.Build" and "bjam" names proves inconveninent from "marketing" and conveninence standpoints, to the point where many users try to read documentation for Boost.Jam, don't find anything there, and become upset. Second, users get the idea that Boost.Build is somehow related to "Classic Jam", which is not true. For those reasons, Rene and I have decided that "bjam.exe" should go. We're thinking about naming the executable simply "build.exe", since no other build tool bothered to take it. Does anybody have comments, or better suggestions? Thanks, Volodya

39 62

[1.44] Snapshot available
by Beman Dawes 26 Jul '10

26 Jul '10

The daily release snapshots are working fully again. That's important because the releases are based on the snapshots. See http://boost.cowic.de/rc/ --Beman

1 0

Bugs in program_options library
by Jorge Lodos Vigil 26 Jul '10

26 Jul '10

Hi The function options_description::find_nothrow throws an exception when there are at least 2 exact matches. Since this function is in the public interface this could be considered a bug (it must not throw). Please note that this function is used several times within the implementation without try clauses. The exception thrown might be being used by callers of the method find, so you cannot just remove it. It is best to implement find and find_nothrow as follows: const option_description& options_description::find(const std::string& name, bool approx, bool long_ignore_case, bool short_ignore_case) const { shared_ptr<option_description> found; vector<string> approximate_matches; vector<string> full_matches; // We use linear search because matching specified option // name with the declared option name need to take care about // case sensitivity and trailing '*' and so we can't use simple map. for(unsigned i = 0; i < m_options.size(); ++i) { option_description::match_result r = m_options[i]->match(name, approx, long_ignore_case, short_ignore_case); if (r == option_description::no_match) continue; if (r == option_description::full_match) { full_matches.push_back(m_options[i]->key(name)); found = m_options[i]; } else { // FIXME: the use of 'key' here might not // be the best approach. approximate_matches.push_back(m_options[i]->key(name)); if (!found) found = m_options[i]; } } if (full_matches.size() > 1) boost::throw_exception( ambiguous_option(name, full_matches)); // If we have a full match, and an approximate match, // ignore approximate match instead of reporting error. // Say, if we have options "all" and "all-chroots", then // "--all" on the command line should select the first one, // without ambiguity. if (full_matches.empty() && approximate_matches.size() > 1) boost::throw_exception( ambiguous_option(name, approximate_matches)); if (!found) boost::throw_exception(unknown_option(name)); return *found; } const option_description* options_description::find_nothrow(const std::string& name, bool approx, bool long_ignore_case, bool short_ignore_case) const { try { const option_description& d = find(name, approx, long_ignore_case, short_ignore_case); return &d; } catch(const std::exception&) { return NULL; } } This modification uncovers a bug in function cmdline::finish_option (cmdline.cpp) where find_nothrow is being called assuming that no exception will be thrown. The first part of this function might be modified to: void cmdline::finish_option(option& opt, vector<string>& other_tokens, const vector<style_parser>& style_parsers) { if (opt.string_key.empty()) return; const option_description* xd; try { // First check that the option is valid, and get its description. xd = &m_desc->find(opt.string_key, is_style_active(allow_guessing), is_style_active(long_case_insensitive), is_style_active(short_case_insensitive)); } catch(const std::exception&) { if (m_allow_unregistered) { opt.unregistered = true; return; } throw; } const option_description& d = *xd; // Canonize the name opt.string_key = d.key(opt.string_key); ........ } Now it can throw the correct exception thrown by the find method. This is the only way callers could know the correct exception. It was apparently working before because find_nothrow was throwing exceptions not captured within cmdline::finish_option. You may chose to eliminate the xd variable altogether and initialize and use d within the try clause. What is important is to call find instead of find_nothrow. The following test would have detected these problems and the one solved in https://svn.boost.org/trac/boost/ticket/4159: // Multiple arguments test_case test_cases2[] = { {"--fname file --fname2 file2", s_success, "fname: file fname2: file2"}, {"--fnam file --fnam file2", s_ambiguous_option, ""}, {"--fnam file --fname2 file2", s_ambiguous_option, ""}, {"--fname2 file2 --fnam file", s_ambiguous_option, ""}, {0, 0, 0} }; test_cmdline("fname fname2", style, test_cases2); This test may be added at the end of the test_guessing function in cmdline_test.cpp. I have created the ticked 4469 (https://svn.boost.org/trac/boost/ticket/4469) with this information. Thank you. Best regards Jorge

1 0

[chrono] [thread] boost.chrono changes to boost::condition_variables
by Morgan Henry 26 Jul '10

26 Jul '10

Hello, I've been exploring the boost.chrono candidate library as a basis for some fixes to boost::condition_variables::timed_wait(). I have some questions: 1) What is the current state of the chrono library, and its likely path into boost? 2) Are the chrono API changes to boost::condition_variables likely to be accepted into the boost.thread library in their current form? (i.e introduction of wait_for(), wait_until(), and the introduction of a new explicit dependency from boost/thread/condition_variables on chrono::time_point etc...) 3) Are there any other planned changes to boost::condition_variables::timed_wait to allow use of POSIX clocks other than CLOCK_REALTIME? My ultimate goal is to provide an implementation of boost::condition_variables that allows access to the POSIX clock CLOCK_MONOTONIC for use through boost::condition_variables::timed_wait(). Specifically, providing an implementation that uses pthread_condattr_setclock(&attr, CLOCK_MONOTONIC) at boost::condition_variables initialisation, and use of pthread_cond_timedwait(..., &t) with clock_gettime(CLOCK_MONOTONIC, &t) in boost::condition_variables::timed_wait() and friends This change would provide reasonable behaviour of boost::condition_variables::time_wait() in presence of ongoing changes to the system clock. boost.chrono contributes to this goal by providing a clock abstraction and accessors to the appropriate POSIX clocks through class monotonic_clock, class system_clock, etc... Further to this, changes to boost::condition_variable::timed_wait() and similar would be required to use clock_gettime(CLOCK_MONOTONIC, &t) rather than boost::get_system_time() for calculations when the monotonic_clock is specified. I'm currently considering whether to trust that the boost.chrono API changes to the boost::condition_variables API are robust, and likely to persist for the future. Or to propose alternative changes localised to boost::condition_variables that achieve the goals above without the strong dependency on boost.chrono. Thanks for any comments or information about the above. Morgan http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.

3 5