December 2005 - Boost - lists.preview.boost.org

updating the references page?
by Esther Schindler 20 Dec '05

20 Dec '05

Informit has several articles related to Boost, many of which are much newer than listed on the boost reference page. To whom should I send a list? Esther Schindler editor, Informit.com (among other things)

2 1

Rational comparison w/ continued fractions
by Daryle Walker 20 Dec '05

20 Dec '05

I interrupted some thread about how Wave processed numbers it read. I mentioned using bignums someday. The thread drifted to bignum representations, including "exact reals." One of the exact-real library web sites mentioned continued fractions, which lead me to the HAKMEM paper. You can find out more at <http://en.wikipedia.org/wiki/HACKMEM>. I was thinking of creating a continued fraction class for us, but then I saw a note about how continued fraction comparison is easier than regular fraction comparison. More importantly, c.f. comparison is just list entry checking, no arithmetic operations. Conversion from r.f. to c.f. involves only division and remainders. These facts combine to make a r.f. comparison that doesn't need multiplications, and therefore avoids overflow. Continued fractions have a form like: p0 + q0 / (p1 + q1 / (p2 + q2 / ... )) where all the p's and q's are integers. We usually simplify the representation by factoring out all the q's to 1's: r0 + 1 / (r1 + 1 / (r2 + 1 / ... )) (The p's change values, except for p0, because of the re-factoring.) We can type out these simplified fractions easily with "[r0; r1, r2, ...]". Rational and irrational numbers map to finite- and infinite-length fraction lists, respectively. Irrational numbers have a unique representation; rational numbers are unique to two forms, where the minor form reduces the last number by 1 and appends a 1 to the list. [x0; x1, x2, ..., xn] == [x0; x1, x2, ..., (xn - 1), 1] Continued fractions are typically difficult to manipulate, but two operations are very easy. 1. Reciprocal [0; x1, x2, x3, ...] <-> [x1; x2, x3, ...] 2. Comparison of two values (as represented by their lists) a. Make sure to normalize the fraction 1. Convert away from the trailing-1 minor form (if rational) 2. Remove any interior zeros with [... x, 0, y, ...] <-> [... (x + y) ...] But note that if x == -y, you'll create another zero and you'll have to do another round. 3. Keep the sign consistent, make sure every integer in the series is non-negative or non-positive. (Keeping the previous rule in mind, only the first list entry can be a zero.) I don't know how to correct lists that violate this. I don't think that normal conversion from a numerator & denominator pair will cause these problems; a conversion will create a list that's already normalized. The conversion involves applying Euclid's GCD algorithm, which needs the "%" operator, which is iffy for negative values, so it would be better to take the absolute values, track the signs separately, and flip the result as appropriate. (Lists with these problems could occur if the list is generated from a rule formula.) b. (I'm assuming that you're using absolute values.) If every element of the two numbers' lists are equal, then the numbers are equal. Otherwise stop at the pair of list entries that are different, using infinity as the place-holder if one list is shorter than another. For that list index K, if K mod 2 is the same as the index for the first (i.e. the whole number part) entry's mod-2, then the less/greater-than status of the two entries is the same as the lists' status, else the statuses are reversed. Example 1: 7/6 (i.e. 1+1/6) vs. 1/2 7/6: [1; 6] 1/2: [0; 2] Difference at first entry 1 > 0 with odd# entry; so 7/6 > 1/2 Example 2: 1/4 vs. 1/3 1/4: [0; 4] 1/3: [0; 3] Difference at second entry 4 > 3 with even# entry; so 1/4 < 1/3 Example 3: 47/21: [2; 4, 5] 9/4: [2; 4] Difference at third entry 5 < Inf with odd# entry; so 47/21 < 9/4 Normal decimal fractions have even faster comparisons, but forming enough digits is harder, especially if they repeat. I'll try to come up with an actual improved member function for boost::rational in few days. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 5

[test] como doesn't like #warning
by Eric Niebler 20 Dec '05

20 Dec '05

This from the regression results for como- 4_3_3- vc7_1: "G:\boost\boost/test/impl/execution_monitor.ipp", line 60: warning #11-D: unrecognized preprocessing directive # warning Debugger check disabled. Either define _WIN32_WINNT or include Boost.Test header in front of winbase.h ^ -- Eric Niebler Boost Consulting www.boost-consulting.com

6 14

Re: [boost] [filesystem] problem with filename length (bug?)
by Allmen, Michael-P57512 20 Dec '05

20 Dec '05

Sorry, forgot that information. Solaris 9 Boost 1.33 -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Thursday, December 15, 2005 7:45 PM To: boost(a)lists.boost.org Subject: Re: [boost] [filesystem] problem with filename length (bug?) "Allmen, Michael-P57512" <Michael.Allmen(a)gdc4s.com> wrote in message news:C7FCC5C93630AB4E80049ED163FFD224B5ED0B@AZ25EXM04.gddsi.com... > Here is the code I am using (the problem also occurs with the > simple_ls.cpp sample)... > > #include <iostream> > #include "boost/filesystem/operations.hpp" > #include "boost/filesystem/path.hpp" > > namespace fs = boost::filesystem; > > int main( int argc, char* argv[] ) > { > fs::path dir( "somedir" ); > > fs::directory_iterator end; > for( fs::directory_iterator i( dir ); i != end; ++i ) { > std::cout << dir->leaf() << std::endl; } > > return 0; > } > > The problem is that once the program finds a file at least 22 > characters long, it will not print any filenames longer than first file correctly. What operating system are you using? What version of Boost? Thanks, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[bug] Visual Studio 2003 versus polymorphic_downcast
by Mat Marcus 20 Dec '05

20 Dec '05

Visual studio 2003 seems to be buggy in a way that can break boost::polymorphic_downcast. Unless I am missing something, it's a rather scary silent failure: ### # include <cassert> class left {}; class right {}; class derived : public left, public right {}; int _tmain(int argc, _TCHAR* argv[]) { derived x; const derived *xp=&x; right *yp=&x; // assert(const_cast<derived*>(xp)==yp); no bug assert(xp==yp); //bug: this fires return 0; } ### This bug causes the assert in polymorphic_downcast to fire when it shouldn't. Here is one possible patched version: template <class Target, class Source> inline Target polymorphic_downcast(Source* x BOOST_EXPLICIT_DEFAULT_TARGET) { #if BOOST_WORKAROUND(BOOST_MSVC, <= 1310) assert( static_cast<const Source*>(dynamic_cast<Target>(x)) == x ); // detect logic error #else assert( dynamic_cast<Target>(x) == x ); // detect logic error #endif return static_cast<Target>(x); } ### The problem is not present in VS 2005. Thoughts? Mat

1 0

More Math Functions for Statistics (and TR2)
by Paul A Bristow 19 Dec '05

19 Dec '05

More Mathematical Functions especially for Statistics +++++++++++++++++++++++++++++++++++++++++++++++++++++ Aficionados of mathematical functions may remember that I proposed some additional functions http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1668.pdf to the choice of Walter Brown which have been added to the C++ TR1 (latest draft) http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1905.pdf The rationale for my proposed functions is that previously standardized functions do not include many functions which have very much wider utility in statistical problems, even the most elementary, like Student's t, Fisher and Chi-sqr tests. To recap, a long list of basic and essential functions were added with the C99 for which rationale is given in http://www2.open-std.org/JTC1/SC22/WG14/www/C99RationaleV5.10.pdf Briefly the total list of functions consists of 1 Original math.h functions, log, exp, pow, sin, cos... 1 So-called IEEE recommended functions, signbit, isnan, isfinite ... 2 Some simplish math functions like lgamma, tgamma, cbrt, acosh. 3 TR1 Bessel functions, Reimann, hypergeometric... 4 TR2 proposed additions, incomplete beta, Fisher, Student, Chisqr probability quantile distributions... I have now produced a first demo of a few of these functions to carry out some very simple, but almost universally applicable, statistical tests - Student's t and Fisher's F-ratio. The example is from analytical chemistry, but could equally well be of school exams, economic comparisons, measurement of lengths, brightness of stars - the list is endless. The demo shows computation of the probability that two methods of extracting tin from foodstuffs give a different result and the probability that one method is more precise than the other. It does NOT require the use of published tables. All the hard and expert work has been done by Stephen Moshier, author of a respected book on mathematical functions, and a long supported (since 1984) and extensive library of mathematical functions in C called Cephes. Moshier has kindly offered to change the library license terms to the Boost terms to support this project. I have merely packaged a few examples of the C functions as C++ functions and placed them in namespaces std::tr2 to show what they would look like in final form. The C versions are required to remain in global namespace to follow the example of the C99 functions which can be used by both C and C++ programs. I am advised that this is a requirement to get the proposal accepted by C WG14 and C++ WG21 Standard groups. I have compiled all the Cephes modules (with a few name changes using macros in the mconf.h configuration header file) and built a library from them. In unitTestfunc1.cpp, I show declarations and definitions of a few sample functions float cbrt(float x) { // Loss of speed over C float version cbrtf? // But not less accurate. // return float(::cbrt(x)); return ::cbrtf(x); // C99 implementation from Cephes, // 32-bit IEEE 754 single precision. } //float cbrt(float x) Some of the 'issues' are: 1 Floating-point format. I have assumed IEEE formats, but try to check and warn if not. All built-in types can vary in precision, especially double and long double: I have shown an example of selecting long double having 53, 80 or 128 significand bits (all IEEE formats). 2 I have only used MSVC 8.0 (but I expect older versions to work too) where long double == 64-bit double. 3 Cephes can be configured to deal with 'wrong' endianness using a macro definition in the configuration header. This might be derived from a Boost header? 4 User Defined Types I have also used Victor Shoup's NTL 128-bit and arbitrary precision library to show that the function definitions can be successfully extended to include User Defined Types such as these. There are a small but significant group of users who want a higher precision than the native long double provides, especially Microsoft compiler users where long double is identical to double and only 64-bit (about 15 decimal digit). (I'm sorry that this makes the sample code rather messy, but you can skip over the NTL part). 5 I have shown some sample tests using the Boost Unit Test framework. These are only a few spot values, calculated using Cephes DOSbox qcalc.exe 100 decimal digit calculator (output to 40 decimal digits) or NTL. These are intended merely to test a few obvious, random, or exact values, a few corner cases, and around some points at which the algorithms are know to change. They aim to check for general algorithm 'sanity' rather than attempt to evaluate accuracy in detail over the whole range. The Cephes functions have already been tested rather fully and their accuracy and tests are reported in the package. 6 In the test example, for simplicity I have concatenated all the declarations and definitions in the same file. These will of course be in separate header and/or source files. 7 I have not concerned myself with efficiency or speed and assumed that the compiler will inline and otherwise optimise away inefficiencies from wrapping. In some cases, the float versions may simply do the calculation in double and return a conversion to float: it may be the best speed and/or accuracy anyway. 8 Implementations will always have to make some compromises between size, speed and accuracy. 9 Cephes deals with errors (for example, from wrong parameter values) by the then conventional method of calling matherr & setting a global math error no, and printing a message, rather than throwing exceptions. But I note that the system-wide error numbers (XENIX) in the Microsoft error.h include files are undocumented, and conflict with the Cephes codes. And C99 (and thus TR1?) no longer REQUIRE a math error to set errno. The simplest solution would be to change the existing matherr function to set errno and NOT print any message: users would always be free to change this module to suit their other requirements. I would NOT wish to implement the C99 exception handling, nor C++ floating_point exceptions. __Detailed__ recommendations about if and how this error handling should be made more 'standard', perhaps using error.h would be welcomed. 10 Cephes could provide test and values for NaNs and infinity etc, but only for some floating- point layouts. These C99 functions are _essential_, but outside the scope of my work at present. 11 I have assumed that compilation and link option choices will deal with floating point instruction set variations, including 'intrinsic' functions like log, exp, sin, cos. This will complicate building the math library and provide potential for confusion at link time. 12 The Cephes code produces a lot of warnings when compiled in 'strict' mode. I have ignored these, although they suggest that the C code does not meet todays 'picky' standards. However a full revision would be a big undertaking with risks of introducing errors: my impression is that most of the warnings look spurious. 13 Cephes implements complex but I have not yet even thought about it ;-) 14 Finally may I reiterate that the objective of this implementation is to persuade the C and C++ Standards groups to standardize the signatures of these functions: it will be possible for better implementations to be produced in the future by both open source and commercial organisations like Dinkumware. Before I undertake the tedious task of wrapping all the proposed TR2 functions (and as many of the C99 and TR1 functions as possible), and presenting the collection for Boost review, I would like feedback from Boosters ever-critical eyes. Bear in mind that (without dealing with complex) there are nearly ***500*** function signatures! I would especially like to avoid a lot of bright new ideas emerging at the review stage, as seems to happen all too often. Speak now or forever hold thy peace, please! Thank you. Paul For those want to see code, a simple demo is at: http://www.hetp.u-net.com/public/mathFuncDemo1.cpp http://www.hetp.u-net.com/public/math2.cpp http://www.hetp.u-net.com/public/math2.hpp and two samples, simple and with UDTs of unit testing: http://www.hetp.u-net.com/public/unitTestFunc1.cpp http://www.hetp.u-net.com/public/unitTestFunc2.cpp -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

3 5

como test problem
by Arkadiy Vertleyb 19 Dec '05

19 Dec '05

Hi all, The following test result: http://tinyurl.com/7e2f7 contradicts to itself by stating that test was "unexpectedly passed" and failed at the same time. Any thoughts on this? Regards, Arkadiy

1 0

[test] Missing implementation for boost::itest::manager
by Markus Schöpflin 19 Dec '05

19 Dec '05

When linking against the test execution monitor lib, the implementation for boost::itest::manager is missing from the library. The header file for the class gets picked up like this: logged_expectations.cpp => logged_expectations.ipp => interaction_based.hpp. It looks like interaction_based is missing from the list of sources (TEST_EXEC_MON_SOURCES) in the libs/test/build/Jamfile Markus

2 1

Re: [boost] [filesystem] problem with filename length (bug?)
by Allmen, Michael-P57512 19 Dec '05

19 Dec '05

1_33_0 -----Original Message----- From: Allmen, Michael-P57512 Sent: Monday, December 19, 2005 7:06 AM To: 'boost(a)lists.boost.org' Subject: RE: [boost] [filesystem] problem with filename length (bug?) Sorry, forgot that information. Solaris 9 Boost 1.33 -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Thursday, December 15, 2005 7:45 PM To: boost(a)lists.boost.org Subject: Re: [boost] [filesystem] problem with filename length (bug?) "Allmen, Michael-P57512" <Michael.Allmen(a)gdc4s.com> wrote in message news:C7FCC5C93630AB4E80049ED163FFD224B5ED0B@AZ25EXM04.gddsi.com... > Here is the code I am using (the problem also occurs with the > simple_ls.cpp sample)... > > #include <iostream> > #include "boost/filesystem/operations.hpp" > #include "boost/filesystem/path.hpp" > > namespace fs = boost::filesystem; > > int main( int argc, char* argv[] ) > { > fs::path dir( "somedir" ); > > fs::directory_iterator end; > for( fs::directory_iterator i( dir ); i != end; ++i ) { > std::cout << dir->leaf() << std::endl; } > > return 0; > } > > The problem is that once the program finds a file at least 22 > characters long, it will not print any filenames longer than first file correctly. What operating system are you using? What version of Boost? Thanks, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[filesystem] BOOST_FILESYSTEM_STATUS_CACHE configuration on SunOS
by Caleb Epstein 19 Dec '05

19 Dec '05

***See: http://tinyurl.com/7pp9r *These test results appear to pre-date line 69 below: 62 // BOOST_FILESYSTEM_STATUS_CACHE enables status_flags cache in 63 // dir_itr_increment. The config tests are placed here because some of the 64 // macros being tested come from dirent.h. 65 // 66 // TODO: "|| defined(__APPLE__)" compiles, but at runtime d_type is alwasy 0. Why? 67 // TODO: find out what macros enable dirent::d_type on various operating systems. 68 # if !defined(__CYGWIN__) && !defined(__osf__) \ 69 && !(defined(__sun) && defined(__GLIBCXX__)) \ 70 && (defined(BOOST_WINDOWS_API) \ 71 || defined(__USE_BSD) || defined(_DIRENT_HAVE_D_TYPE) \ 72 ) 73 # define BOOST_FILESYSTEM_STATUS_CACHE 74 # endif So I expect Filesystem will compile properly on my Monday test run. However I think the macro test should just be for defined(__sun), and not both __sun && __GLIBCXX__. The lack of d_type in dirent is a C library issue, not a C++ library issue and as would affect any compiler on Solaris (e.g. SunPRO CC would hit this too). -- Caleb Epstein caleb dot epstein at gmail dot com

2 2