RE: [boost] Re: BOOST TEST and strict /Za no lanugage extensionsoption -virturenot fully rewarded?
Not that I can find but I'm not an expert either. Gurus? C++ code to do it perhaps - see my other post. Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gennadiy Rozental | Sent: Thursday, September 04, 2003 2:09 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: BOOST TEST and strict /Za no lanugage extensions | option -virturenot fully rewarded? | | | | "Paul A. Bristow" <[EMAIL PROTECTED]> wrote in message | news:[EMAIL PROTECTED] | > In trying to be virtuous and test everything compiled in strict mode as I | write | > it, I am finding myself thwarted by BOOST minimal_test otherwise excellent | test | > system. | > | > I aim to compile and test all my code with MSVC 7.1 in strict mode (option | /Za - | > no language extensions and warning level 4). | > | > But in practice this is impossible using the minimal_test.cpp | > because #include also compiles Windows specific structured exception | handling | > modules like winNT.h and these require MS extensions to compile - | otherwise | > zillions of errors. | | > Is there any easier way round this so that minimal_test can be used | without | > linking with a library? | > | > Paul | | I am not an expert in MSVC pragmas. Is there one that force usage of | extencions in specific part of the code? | | Gennadiy. | | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] BOOST TEST and strict /Za - can theMS lanugageextensions option be enabled in a program
I suspect (but have not got enough Hungarian language skills and MS Internals to get it to work) that a solution is to switch on the LanguageExtensions using two functions: HRESULT __stdcall get_DisableLanguageExtensions( /* [out, retval] */ VARIANT_BOOL* retVal ); HRESULT __stdcall put_DisableLanguageExtensions( /* [in] */ VARIANT_BOOL NewValue ); Ones seems to get into a Catch-22 in that these can only work if LanguageExtensions are already enabled! Can any Windows Gurus can advise? However I also find that linking with a test_tools static library is not too inconvenient. It can be built non-strict, but the actual test modules can be compiled fully strict, though they produce some warnings which look ignorable and/or fixable. Probably Gennadiy can find some more fun activities than fixing them ;-) So I think this is acceptable unless a better solution can be found easily. Only execution_monitor.cpp seems to require MS language extensions (because it calls winnt.h etc). Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Thursday, September 04, 2003 1:40 AM | To: Boost mailing list; Boost | Subject: Re: [boost] BOOST TEST and strict /Za no lanugage extensions | option - virturenot fully rewarded? | | | At 09:56 AM 9/3/2003, Paul A. Bristow wrote: | | >In trying to be virtuous and test everything compiled in strict mode as I | | >write it, I am finding myself thwarted by BOOST minimal_test otherwise | >excellent test system. | > | >I aim to compile and test all my code with MSVC 7.1 in strict mode | (option | >/Za - | >no language extensions and warning level 4). | > | >But in practice this is impossible using the minimal_test.cpp | >because #include also compiles Windows specific structured exception | >handling modules like winNT.h and these require MS extensions to | >compile - otherwise zillions of errors. | > | >It is possible to avoid this by compiling these modules separately with | >extensions enabled, building a library, then to compile MY | modules >strictly, and then linking to the library, but this is a bit more | >cumbersome than minimal_testing. | > | >This problem will also apply to all testing of Boost library items using | >the minimal test if we try to raise the code quality bar to 'strict' | >compilation. | > | >Is there any easier way round this so that minimal_test can be used | without | >linking with a library? | | If Gennadiy can somehow make boost/test/minimal.hpp (and dependencies) work | /Za, that's great. But he is already providing a full object-library based | solution, as well as the header implemented solution. Not to mention three | separate levels of functionality (execution tools, test tools, full unit | test). I'd hate to see added complexity to solve a problem that can already | be dealt with just by using the object-library version of the tools. | Minimal test was designed to be just that - minimal. It isn't expected to | be useful in as wide a range of uses as the library as a whole. | | Just my 2 cents... | | --Beman | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] BOOST TEST and strict /Za no lanugage extensions option-virturenot fully rewarded?
But do the 'emulating' compilers also have the same pragma warning disable system? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Ulrich Eckhardt | Sent: Wednesday, September 03, 2003 9:12 PM | To: Boost mailing list | Subject: Re: [boost] BOOST TEST and strict /Za no lanugage extensions | option -virturenot fully rewarded? | | | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | On Wednesday 03 September 2003 15:56, Paul A. Bristow wrote: | > #ifdef _MSC_VER // or BOOST_MSVC? | > #pragma warning (disable : 4511) // copy operator could not be generated | > #pragma warning (disable : 4512) // assignment operator could not be | > #endif // _MSC_VER | | In this case, BOOST_MSVC is the right one, possibly with a version. | The reason | is that other (IMO thus broken) compilers also define that symbol ... | However, I seem to remember that that is documented. If not, I'm probably | confusing this with STLport sources. | | Uli ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] BOOST TEST and strict /Za no lanugage extensions option- virturenot fully rewarded?
Point taken - but if there is an easy solution that has escaped my notice... Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Thursday, September 04, 2003 1:40 AM | To: Boost mailing list; Boost | Subject: Re: [boost] BOOST TEST and strict /Za no lanugage extensions | option - virturenot fully rewarded? | | | At 09:56 AM 9/3/2003, Paul A. Bristow wrote: | | >In trying to be virtuous and test everything compiled in strict mode as I | | >write it, I am finding myself thwarted by BOOST minimal_test otherwise | >excellent test system. | > | >I aim to compile and test all my code with MSVC 7.1 in strict mode | (option | >/Za - | >no language extensions and warning level 4). | > | >But in practice this is impossible using the minimal_test.cpp | >because #include also compiles Windows specific structured exception | >handling modules like winNT.h and these require MS extensions to | >compile - otherwise zillions of errors. | > | >It is possible to avoid this by compiling these modules separately with | >extensions enabled, building a library, then to compile MY | modules >strictly, and then linking to the library, but this is a bit more | >cumbersome than minimal_testing. | > | >This problem will also apply to all testing of Boost library items using | >the minimal test if we try to raise the code quality bar to 'strict' | >compilation. | > | >Is there any easier way round this so that minimal_test can be used | without | >linking with a library? | | If Gennadiy can somehow make boost/test/minimal.hpp (and dependencies) work | /Za, that's great. But he is already providing a full object-library based | solution, as well as the header implemented solution. Not to mention three | separate levels of functionality (execution tools, test tools, full unit | test). I'd hate to see added complexity to solve a problem that can already | be dealt with just by using the object-library version of the tools. | Minimal test was designed to be just that - minimal. It isn't expected to | be useful in as wide a range of uses as the library as a whole. | | Just my 2 cents... | | --Beman | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [date_time] time_duration
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams | Sent: Wednesday, September 03, 2003 8:08 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: [date_time] time_duration | |> | > Yikes! They probably all should be plural. Problem is the abbreviated | > 'millisecs' doesn't sound right to me, so perhaps that's the reason | | Well, abbrevs just don't sound right. Bite the bullet and use the | full names, please! Yes - millseconds, microsconds, nanoseconds ... please. And time_point shounds VERY MUCH better to me (than ptime or time). And I suggest first_day_of_week_after first_day_of_week_before last_day_of_week_in_month first_day_of_week_in_month so first_day_of_week_after my_date(Monday); will now make sense to almost any reader. "Boost has always favoured clarity over curtness" Paul PS Isn't time from C time in global namespace? Not a macro but still a PITA! PPS It would be great if Jeff could find the time to produce version 2. There is so much that seems right to me. Forget about MSVC 6 and gcc 2.x and break out! Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: circular_buffer ver. 3.3 [long]
I confirm that the test works on MSVC 7.1 debug and release apparently without warnings at level 4. As noted in another related post, it is not possible to check without separate compilation of the unit_test modules because these produce warnings and the exectuionmonitor requires language extensions to compile winnt.h. The test suite appears to be commendably thorough. A minor point: in the excellent documentation the link at 'documentation' is broken. "For more information how to use the circular buffer see the documentation. " The docs example compiles free of warnings _without_ MS language extensions, so I think we can be reasonably confident that the code is strictly Standard. I did note that #include should I think be .hpp? Circular buffer documentation is still at 3.1 whereas code is 3.3. More over-commented examples of usage would also always be welcome of course. Use of other containers... Looking good! Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | From: "Jan Gaspar" <[EMAIL PROTECTED]> | Subject: circular_buffer ver. 3.3 | > | > Another beast was born. You can find it at | > http://groups.yahoo.com/group/boost/files/circular_buffer.zip | | | This circular_buffer works on MSVC 6.5 and Intel C++ 7 and also compiles on | BC++B 6.4. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BOOST TEST and strict /Za no lanugage extensions option -virturenot fully rewarded?
In trying to be virtuous and test everything compiled in strict mode as I write it, I am finding myself thwarted by BOOST minimal_test otherwise excellent test system. I aim to compile and test all my code with MSVC 7.1 in strict mode (option /Za - no language extensions and warning level 4). But in practice this is impossible using the minimal_test.cpp because #include also compiles Windows specific structured exception handling modules like winNT.h and these require MS extensions to compile - otherwise zillions of errors. It is possible to avoid this by compiling these modules separately with extensions enabled, building a library, then to compile MY modules strictly, and then linking to the library, but this is a bit more cumbersome than minimal_testing. This problem will also apply to all testing of Boost library items using the minimal test if we try to raise the code quality bar to 'strict' compilation. Is there any easier way round this so that minimal_test can be used without linking with a library? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] PS The unit test modules (exception execution monitor) all compile in 'strict' with the following warnings, if this is any help. Most look easily fixable or ignorable, for example with #ifdef _MSC_VER // or BOOST_MSVC? #pragma warning (disable : 4511) // copy operator could not be generated #pragma warning (disable : 4512) // assignment operator could not be generated #endif // _MSC_VER -- Rebuild All started: Project: unit_test, Configuration: Debug Win32 -- Deleting intermediate files and output files for project 'unit_test', configuration 'Debug|Win32'. Compiling... execution_monitor.cpp i:\boost_1_30_2\libs\test\src\execution_monitor.cpp(156) : warning C4100: 'retVal' : unreferenced formal parameter i:\boost_1_30_2\libs\test\src\execution_monitor.cpp(186) : warning C4535: calling _set_se_translator() requires /EHa the command line options /EHc and /GX are insufficient Compiling... unit_test_suite.cpp I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(64) : warning C4121: 'boost::unit_test_framework::detail::unit_test_monitor' : alignment of a member was sensitive to packing I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(68) : warning C4512: 'boost::unit_test_framework::detail::unit_test_monitor' : assignment operator could not be generated I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(34) : see declaration of 'boost::unit_test_framework::detail::unit_test_monitor' I:/boost_1_30_0\boost\test\unit_test_log.hpp(82) : warning C4512: 'boost::unit_test_framework::checkpoint' : assignment operator could not be generated I:/boost_1_30_0\boost\test\unit_test_log.hpp(78) : see declaration of 'boost::unit_test_framework::checkpoint' unit_test_result.cpp I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(64) : warning C4121: 'boost::unit_test_framework::detail::unit_test_monitor' : alignment of a member was sensitive to packing I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(68) : warning C4512: 'boost::unit_test_framework::detail::unit_test_monitor' : assignment operator could not be generated I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(34) : see declaration of 'boost::unit_test_framework::detail::unit_test_monitor' i:\boost_1_30_2\libs\test\src\unit_test_result.cpp(85) : warning C4100: 'where_to' : unreferenced formal parameter i:\boost_1_30_2\libs\test\src\unit_test_result.cpp(86) : warning C4100: 'where_to' : unreferenced formal parameter i:\boost_1_30_2\libs\test\src\unit_test_result.cpp(214) : warning C4100: 'test_case_name' : unreferenced formal parameter C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(1244) : warning C4172: returning address of local variable or temporary i:\boost_1_30_2\libs\test\src\unit_test_result.cpp(133) : see reference to function template instantiation 'const _Ty &std::max(const _Ty &,const _Ty &)' being compiled with [ _Ty=boost::unit_test_framework::unit_test_counter ] unit_test_parameters.cpp unit_test_monitor.cpp I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(64) : warning C4121: 'boost::unit_test_framework::detail::unit_test_monitor' : alignment of a member was sensitive to packing I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(68) : warning C4512: 'boost::unit_test_framework::detail::unit_test_monitor' : assignment operator could not be generated I:/boost_1_30_0\boost\test\detail\unit_test_monitor.hpp(34) : see declaration of 'boost::unit_test_framework::detail::unit_test_monitor' I:/boost_1_30_0\boost\test\unit_test_log.hpp(82) : warnin
RE: [boost] date_time naming
Although I an growing to like date_time, I have to agree that some names are less than ideal. I found kday less than intuitive. Documentation of the labyrinthine (with good reason) structure is also weak (or even wrong?) It seems to me that these observations at this stage highlight a weakness of the current review process. Until code gets Boost acceptance status, too few are prepared to really use it in anger on real projects, and only then do lots of 'issues' start to surface. But by then, changes cause grief to existing users, so there is a reluctance to 'improve' things like naming. Do we need a 'still may be subject to significant change' status to distinguish from a 'pretty much tried and tested' status? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams | Sent: Tuesday, September 02, 2003 9:50 PM | To: boost | Subject: [boost] date_time naming | | | | I'm just getting started with the date_time library, and I think I'm | gonna like it. I have some quibbles with the naming choices though | (shocking! me of all people!) For example, why is the nested | namespace called posix_time instead of, simply, posix? Once you're in | a date_time context it seems to me that _time adds nothing. | Similarly, what's the "p" in ptime stand for? I can guess, but I can | guess it's also redundant ;-) | | | | -- | Dave Abrahams | Boost Consulting | www.boost-consulting.com | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] int64_t with MSVC 7.1 & 'strict' /Za option
Thanks. Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of John Maddock | Sent: Friday, August 29, 2003 2:01 PM | To: Boost mailing list | Subject: Re: [boost] int64_t with MSVC 7.1 & 'strict' /Za option | | | > Trying to use boost/date-time in MSVC 7.1 in 'strict' mode option /Za | 'disable | > language extensions' it seems that | > | > boost::int64_t isn't available. | > | > After a journey through the labryinthine config modules, I have got | compiling | > with | > | > #define BOOST_HAS_MS_INT64 // required if language extensions disabled | /Za. | > | > as the first statement. | > | > but I am unclear if this is a deficiency in either boost/cstdint and/or | > date-time/compiler_config.hpp | > | > or in my understanding of the MS option | > | > but it might be worth documenting somewhere, perhaps as a comment in | > cstdint.hpp? | | Apparently __int64 does work with /Za, so I've changed boost.config to | enable it in that case - it should fix your date/time problems as well. | | John. | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] int64_t with MSVC 7.1 & 'strict' /Za option
Do I understand correctly that with MSVC 7.1 option /Za #define BOOST_HAS_MS_INT64 merely makes int64_t available as the ONLY language extension? (I am only trying to uniformly compile MY modules (which all use date-time) without language extensions and warnings at level 4). Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jeff Garland | Sent: Friday, August 29, 2003 1:33 PM | To: Boost mailing list | Subject: Re: [boost] int64_t with MSVC 7.1 & 'strict' /Za option | | | On Thu, 28 Aug 2003 19:35:57 +0100, Paul A. Bristow wrote | > Trying to use boost/date-time in MSVC 7.1 in 'strict' mode option | > /Za 'disable language extensions' it seems that | > | > boost::int64_t isn't available. | > | > After a journey through the labryinthine config modules, I have got | compiling | > with | > | > #define BOOST_HAS_MS_INT64 // required if language extensions disabled /Za. | > | > as the first statement. | > | > but I am unclear if this is a deficiency in either boost/cstdint and/or | > date-time/compiler_config.hpp | > | > or in my understanding of the MS option | > | > but it might be worth documenting somewhere, perhaps as a comment in | > cstdint.hpp? | | I'm not an expert on the VC options, but it seems that if the user is flagging | us that we shouldn't use any language extensions then we should honor that. | So I would accept that it is a bug in date-time that it doesn't offer an | option to configure without int64_t. One other user has brought this issue | up, but it hasn't been high enough on my priority list as the library runs | well on a large set of platforms and removal of int64_t from the core will | surely slow things down (especially with 64 bit processors getting cheap :-) | So I recommend the following in steps: | | 1) Will define BOOST_HAS_MS_INT64 in date-time/compiler_config for now | 2) Will document that this extension is used in the date-time docs | 3) Will in the future provide options to use date-time without int64_t | | And I agree that a note in cstdint.hpp might be nice too. | | Jeff | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] int64_t with MSVC 7.1 & 'strict' /Za option
Trying to use boost/date-time in MSVC 7.1 in 'strict' mode option /Za 'disable language extensions' it seems that boost::int64_t isn't available. After a journey through the labryinthine config modules, I have got compiling with #define BOOST_HAS_MS_INT64 // required if language extensions disabled /Za. as the first statement. but I am unclear if this is a deficiency in either boost/cstdint and/or date-time/compiler_config.hpp or in my understanding of the MS option but it might be worth documenting somewhere, perhaps as a comment in cstdint.hpp? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
FW: [boost] Re: Insufficient significant digits using lexical_cast
There has been some discussion about a minor improvement to lexical_cast to ensure that a loopback test like: any_type any_value == lexical_cast(lexical_cast(any_value)) is always true The following replacement for the original code (using digits10+1) works for specialised radix 2 types: if(std::numeric_limits::is_specialized && std::numeric_limits::radix == 2) { stream.precision(2 + std::numeric_limits::digits * 301/1000); } else if(std::numeric_limits::is_specialized && std::numeric_limits::radix == 2) { stream.precision(2 + std::numeric_limits::digits * 301/1000); } As in the current version, for other types the default precision is used, and you may not get what you expect. I think this is OK, but one could throw an exception. I propose a comment instead // Warning: else the default stream precision (usually 6) will be used, // which may not be enough significant decimal digits to avoid losing precision, // for example in a loopback test like // some_type any_value == lexical_cast(lexical_cast(any_value)); If there are no objections, can someone with sufficient authority patch lexical_cast.hpp? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Insufficient significant digits using lexical_cast
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Spangenberg | Sent: Tuesday, August 19, 2003 9:25 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Insufficient significant digits using lexical_cast In the absence of a C99 or numeric_limits significant decimal digits value (and don't forget what is needed is effectively an 'unrounded' value with some 'noisy' guard digits at the end, not just digits10) some tests show that the following if(std::numeric_limits::is_specialized && std::numeric_limits::radix == 2) { stream.precision(2 + std::numeric_limits::digits * 301/1000); } else if(std::numeric_limits::is_specialized && std::numeric_limits::radix == 2) { stream.precision(2 + std::numeric_limits::digits * 301/1000); } uses the correct number of significant decimal digits for ALL builtin bool, char, int and floating point types: And a loopback test like: l == lexical_cast(lexical_cast(l)) is true (correct) for at least some selected values - and I wager a couple of beers for all non-NaN non-Inf values ;-). Possibly a comment warning of possible trouble here would be helpful? // if neither specialized, or unusual radix, then use default stream precision of 6? // Warning: a loopback like // l == lexical_cast(lexical_cast(l)) may be false I believe a test radix == 2 is appropriate because is_iec599 (IEEE754) would fail for integer types, which actually work correctly with the above formula. Paul Dr Paul A Bristow, hetp Chromatography Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] For the curious I used: template bool test(T l) { cout << l << ' '; string sl = lexical_cast(l); cout << sl << ' '; T ll = lexical_cast(sl); cout << ll << (l == lexical_cast(lexical_cast(l))) // Convert type T to string and back to T. << endl; // eg for long 2147483647 2147483647 2147483647true return (l == lexical_cast(lexical_cast(l))); } // test template bool tests() { if (numeric_limits< T >::is_specialized) { cout << numeric_limits< T >::digits << ' ' << numeric_limits< T >::digits10 << ' ' << 2 + std::numeric_limits::digits * 301/1000 << endl; } else { cout << "Not specialized!" << endl; } return // for a few sample values. test< T >(numeric_limits< T >::max()) // max && test< T >(T(1)) // unity && test< T >(T(0)) // zero && test< T >(T(-1)) // -1 && test< T > (numeric_limits< T >::min()); // min } // tests and tests (); tests (); tests (); tests (); tests (); tests (); tests (); tests (); tests (); tests (); tests (); ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Insufficient significant digits using lexical_cast
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Spangenberg | Sent: Tuesday, August 19, 2003 9:25 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Insufficient significant digits using lexical_cast | | I think, the correct solution would be the usage of a constant, similar to | DECIMAL_DIG, which is provided from C99 on. 5.2.4.2.2 says: | | " number of decimal digits, n, such that any floating-point number | in the widest | supported floating type with pmax radix b digits can be rounded to a | floating-point | number with n decimal digits and back again without change to the value, | | pmax log10 b if b is a power of 10 | Ceil(1 + pmax log10 b) otherwise | | DECIMAL_DIG 10" | | | My personal opinion is: Extend the DECIMAL_DIG definition for any | floating point type, | similar to digits10 I agree (and indeed have previously and now suggested) that adding to numeric_limits:: would be the best solution. But for the time being to 'fix' lexical cast, I think my suggestion, perhaps with Daryle's refinement to warn if not IEE754, is at least better than the existing formula. I will make a further suggestion when I get a moment to test it. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] number<64> proposal
You might also like to look at the highly refined NTL by Victor shoup at www.shoup.net/ntl This has been used to calculate very accurate math constants, for example. And provides a fairly simple way of providing both C++ quad (128-bit) and arbitrarily higher precision too. However I suspect that the requirement for 'infinite' precision FP is limited and that this and/or other packages will meet most peoples rather special needs. Boostification is not a trivial task I have discovered :-( Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Philippe A. Bouchard | Sent: Tuesday, August 19, 2003 12:14 PM | To: [EMAIL PROTECTED] | Subject: [boost] number<64> proposal | | | Hi there, | | Like I mentionned before, it would be great for Boost to have an | infinite precision floating point number. You can see an example here: | http://members.lycos.co.uk/keithmbriggs/doubledouble.html. Of course, the | doubles could be replaced by long doubles, a muldiv() could be easily added, | the exponents could be increased as well, etc. | | Maybe someone can ask how to calculate trigonometric functions with less | precise versions and so on. It would be really great for Boost to have this | user-defined precision because I am pretty sure research centers will be | interested. | | | | Philippe | | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Date iterators in Boost Date-Time
Thanks - it does now make sense, but since (mercifully!) time is only 1-dimensional, I find the span suggestion more intuitive. Paul PS This explanation could usefully be added to the interval library documentation. I was puzzled why the word 'hull' was used. | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Guillaume Melquiond | Sent: Monday, August 18, 2003 8:36 AM | To: Boost mailing list | Subject: RE: [boost] Re: Date iterators in Boost Date-Time | | | En réponse à "Paul A. Bristow" <[EMAIL PROTECTED]>: | | > But as Michael Caine said "Not a lot of people know that" - so I trust | > you will explain what it does too for the benefit of us mere | non-mathematical | > mortals! | > | > Paul | | I'm not sure to understand. Do you want me to explain what a convex hull is or | to explain what the function of the date-time library is supposed to do? I | suppose it's the first, since the second is what started this subthread. | | A connected set is a set for which each couple of points are | connected by a path | itself included in the set (all the points are reachable from all the | points). A | convex set is a connected set with linear paths (all the points can be reached | from all the other points by following a segment). The convex hull of a set is | the smallest convex superset of it. For example, given three points in the | plane, the convex hull is the filled triangle defined by these points. | | In the case of a 1-dimension space, connected and convex set are equals: they | are segments (or half-line or line or empty). Date manipulated by the | date-time | library are in a 1-dimension space (the real line) and periods are segments | (non-empty bounded convex sets). So when you have two periods, the smallest | period enclosing these two is also the convex hull of them. Hence the name I | suggested. | | I hope it makes sense. | | Regards, | | Guillaume | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Insufficient significant digits using lexical_cast
Agreed - but what do we do if NOT is_iec559? Give up? #error "Can only work with IEEE 754!" Or choose a massive amount of decimal digits? eg 40? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daryle Walker | Sent: Monday, August 18, 2003 7:05 AM | To: Boost | Subject: [boost] Re: Insufficient significant digits using lexical_cast | | | On Sunday, August 17, 2003, at 10:33 PM, Paul A. Bristow wrote: | | [SNIP] | > But you are right that it would be better to check that | > numeric_limits::digits exists and isn't something silly before using | > the formula. With all the built-in floating point types it should be | > fine, and for other (well) User defined floating point types too. (I | > will look at this). | [TRUNCATE] | | I think you need to check numeric_limits::radix since your algorithm | had a base-2-to-10 conversion (the type may not actually be binary!). | The algorithm was based off a paper about IEEE-754; if IEEE-754 is a | requirement, you may have to check for that too (via | numeric_limits::is_iec559). Remember that even the built-in | floating-point types aren't guaranteed to match IEEE-754! | | Daryle | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Date iterators in Boost Date-Time
But as Michael Caine said "Not a lot of people know that" - so I trust you will explain what it does too for the benefit of us mere non-mathematical mortals! Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] | Sent: Sunday, August 17, 2003 7:11 AM | To: Boost mailing list | Subject: Re: [boost] Re: Date iterators in Boost Date-Time | | | En réponse à Jeff Garland <[EMAIL PROTECTED]>: | | I just wanted to mention that the interval library names this | operation "hull". | It is a mathematically defined term since the operation is indeed a | convex hull. | | Just my two eurocents, | | Guillaume | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Insufficient significant digits using lexical_cast
Sorry about the long post, but that seemed the easiest way. numeric_limits::digits10 does what it says - the number that are _guaranteed_ to be correct on output, but that isn't what one usually wants for all _significant_ on input (and I suggest again another numeric_limits::significant_digits10 which is what you get from the formaula below). But you are right that it would be better to check that numeric_limits::digits exists and isn't something silly before using the formula. With all the built-in floating point types it should be fine, and for other (well) User defined floating point types too. (I will look at this). But using +3 instead would be 1 decimal digit too many for most of the FP types. Since it is done at compile time, getting it 'just right' with the formula below shouldn't cost anything at run-time. Incidentally a suitable sort of test is float const aFloat = any_value; if (aFloat != lexical_cast(lexical_cast(aFloat ))) ( // problem } I think from previous experience that this can be shown to be true for ALL possible float values (for 32 bit representations) but it would take too long to test all doubles (assuming 64 bit representation). HTH Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daryle Walker | Sent: Tuesday, August 12, 2003 8:56 AM | To: Boost | Subject: [boost] Re: Insufficient significant digits using lexical_cast | | | [Paul claims that lexical_cast prints (floating-point) numbers with too | few precision digits. Currently, limits::digits10 + 1 is used. Paul | wants to change it to "int significant_digits10 = int(ceil(1 + | limits::digits * log10Two));" where "limits" is the numeric-limits | traits class and "log10Two" is the base-10 logarithm of 2.] | | You used an article on IEEE 754 arithmetic. Shouldn't you check if the | number type is compliant with that format? Or can this work for any | suitable type? You also have to check if "limits::digits" is 2! | | Looking at the numbers you had, couldn't you just change | "limits::digits10 + 1" to "limits::digits10 + 3"? It could be argued | that there's just a bug in the definitions of "limits::digits10" (it's | too low). | | | On Saturday, August 9, 2003, at 5:48 PM, Paul A. Bristow wrote: | [CHOP OFF really long article, with long attachments] | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: lexical_cast
Curiously I have just posted a description of what may be the cause of this. Attached... My suggested remedy relies on the correct value for numeric_limits::digits (not digits10) Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Aleksandr Golovanov | Sent: Saturday, August 16, 2003 2:24 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: lexical_cast | | | | "Ross Smith" <[EMAIL PROTECTED]> wrote in message | news:[EMAIL PROTECTED] | > Aleksandr Golovanov wrote: | > > "Ross Smith" <[EMAIL PROTECTED]> wrote in message | > > news:[EMAIL PROTECTED] | > > | > >>Aleksandr Golovanov wrote: | > >> | > >>>Yesterday, I ran into a small problem, lexical_cast accepts copy | instead of | > >>>(const)? reference to a source. I have a class which I would prefer to | be | > >>>noncopyable and castable with laxical_cast at the same time. | > >> | > >>Wrap the object in boost::cref(). | > > | > > Unfortunately, cref won't work because lexical_cast propagates the | source | > > type as a template parameter to various helper/standard templates: | > | > You're wrong; it works perfectly well. I tried it before I posted the | > suggestion. | > | | Following working example shows one possible case when application of | boost::cref leads to a wrong result. | Compiler VC6 SP5; lexical_cast from 1.30.0 boost release. | | #include "boost/lexical_cast.hpp" | #include "boost/ref.hpp" | #include | #include | #include | | class big_decimal | { | public: | big_decimal() : m_val( 1.23456789 ) {} | public: | double m_val; | }; | | namespace std { | class numeric_limits | : public numeric_limits | { | }; | } | | std::ostream& operator<<( std::ostream& s, big_decimal const& arg ) | { | return s << arg.m_val; | } | | int main() | { | big_decimal dec; | std::cout << boost::lexical_cast( dec ) << "\n"; | std::cout << boost::lexical_cast( boost::cref( dec ) ) << | "\n"; | return 0; | } | | Result of execution: | | 1.23456789 | 1.23457 | | Conclusion: usage of boost::cref with lexical_cast may lead to wrong results | in the current implementation. | | -- | Thanks. | Aleksandr Golovanov, | MetaCommunications Engineering. | | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | --- Begin Message --- I note that the 'precision' number of digits in lexical cast is obtained from digits10 +1 if(std::numeric_limits::is_specialized) { stream.precision(std::numeric_limits::digits10 + 1); } If, as I believe correct, the objective is to get all digits that can be significant, and can be read back in without loss of precision, this isn't always quite right according to: "Lecture notes on the status of IEEE 754 standard for binary floating point arithmetic" William Kahan http://http.cs.berkley.edu/~wkahan/ieee754status/ieee754.ps gives formula for number of decimal digits which are guaranteed to be correct on output and required for input to achieve maximum possible precision as a function of the number of significand bits (given by std::number_limits::digits). In C++ the full formula is: int significant_digits10 = int(ceil(1 + float_significand_digits * log10Two)); and using this formula : std::numeric_limits::digits = 24 significand bits std::numeric_limits::digits10 = 6 floor(float_significand_digits -1) * log10(2) = 6 ceil(1 + float_significand_digits * log10(2) = 9 all significant bits (note that the existing code gives 7 here, which is 2 too few) std::numeric_limits::digits = 53 std::numeric_limits::digits10 = 15 floor(double_significand_digits -1) * log10(2) = 15 ceil(1 + double_significand_digits * log10(2)) = 17 (note that the existing lecial_cast.hpp code gives 16 here, which is 1 too few) 32 significand bits digits10 = 6 significant_digits10 = 9 53 significand bits digits10 = 15 significant_digits10 = 17 64 significand bits digits10 = 18 significant_digits10 = 21 106 significand bitsdigits10 = 31 significant_digits10 = 33 113 significand bitsdigits10 = 33 significant_digits10 = 36 128 significand bitsdigits10 = 38 significant_digits10 = 40 (note that the rest are a few too few) I have proposed before that numeric limits should have another item called, perhaps, significant_digits10 returning these useful values, but meanwhile I suggest that following the style of boost/limits.h BOOST_STL_DECLARE_LIMITS_MEMBER(int, digits10, (dig
RE: [boost] Re: Files of types *.ipp are unfriendly, especially toMSVC ?
Please can you say why we need yet another file type? what is wrong with .cpp or .hpp? Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams | Sent: Friday, August 08, 2003 10:32 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Files of types *.ipp are unfriendly, especially to | MSVC ? | | | "Paul A. Bristow" <[EMAIL PROTECTED]> writes: | | > Many thanks for this - works for me too. | > | > HKLM\SOFTWARE\Microsoft\VisualStudio\7.1\Languages\File Extensions.ipp" | > | > {B2F072B0-ABC1-11D0-9D62-00C04FD9DFD9} | > | > makes it edit like .cpp | > | > But I still doubt if files should be called .ipp. | | I support the use of ".ipp" for template implementation files. | What's the problem with it? | | -- | Dave Abrahams | Boost Consulting | www.boost-consulting.com | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Files of types *.ipp are unfriendly, especially toMSVC ?
OK, I'm persuaded. Yet another thing one needs to know and my brain is already full :-( Since I couldn't find how to make the editor work with .ipp files from the MS documentation, but it ws kindly provided by a diligent Booster, can you suggest where this info shold be stored? Thanks. Paul PS Do files of type .ipp get checked for nasties like tabs, dud newlines? | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams | Sent: Saturday, August 09, 2003 1:40 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Files of types *.ipp are unfriendly, especially to | MSVC ? | | | "Paul A. Bristow" <[EMAIL PROTECTED]> writes: | | > Please can you say why we need yet another file type? what is wrong | > with .cpp or .hpp? | | If you want to split up your template sources into interface and | implementation (there are lots of good reasons to do that, including | controlling instantiation), you can't very well use the same name | (foo.hpp) twice, and foo.cpp wouldn't be appropriate for either one. | foo.ipp clearly delineates the file as an implementation file intended to | be #included in foo.hpp. | | | -- | Dave Abrahams | Boost Consulting | www.boost-consulting.com Jeff Garland wrote: In date_time the intent is to conditionally inline code for tuning performance. I believe the first time I saw this used was in the ACE library where .ipp files are use extensively for conditional inlining. It is straightforward, clearly identifies the intent (if you know why it is there), and a bit less ugly than something like _impl.hpp. Bulka and Mayhew (Efficient C++, 2000) describe this technique in chapter 10. They use .inl as a file extension, which has the same issues as the .ipp file. So, I think there is good precedent for this and now that workarounds for MSVC have been provided I'd really rather not change. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: time_duration bug in Boost 1.30.0
I have built the date examples OK, but I am getting a compile error when trying to build the time_math.cpp example with MSVC 7.1 aka .net 2003 I:/boost_1_30_0\boost\lexical_cast.hpp(147) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'const boost::token_iterator_generator::value_type' (or there is no acceptable conversion) with [ TokenizerFunc=boost::char_delimiters_separator, Iterator=std::basic_string,std::allocator>::co nst_iterator, Type=std::string ] I:/boost_1_30_0\boost\lexical_cast.hpp(146) : while compiling class-template member function 'bool boost::detail::lexical_stream::operator <<(const Source &)' with [ Target=unsigned short, Source=boost::token_iterator_generator,st d::basic_string,std::allocator>::const_iterato r,std::string>::value_type ] this is in lexical_cast bool operator<<(const Source& input) { return stream << input; } I am not clear if this is a problem in lexical_cast or in date_time. Should I wait for the 1.30.1 release or try to load an update? Or is this a new problem? Thanks Paul PS There are also lots of confusing warnings, most, if not all, of which I suspect could be casted away. It would be really nice to get a clear compile, preferably in strict mode, because this code is likely to be included by most user stuff, which will repeatedly produce a host of junk warnings. (And other MS specific unhelpful warnings which could be dealt with by #ifdef _MSC_VER or BOOST_? #pragma warning (disable : 4800) // inefficient bool conversion? #endif As a general point, is there any reason why 'known to be unhelpful' warnings like this cannot be disabled in Boost code? Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jeff Garland | Sent: Thursday, August 07, 2003 2:02 PM | To: Boost mailing list | Subject: Re: [boost] Re: time_duration bug in Boost 1.30.0 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: time_duration test bug in Boost 1.30.0
The problem is in previous version of lexical_cast - new version works fine. bug-fix release 1.30.1 should be OK. Paul PS The date-time example 'days alive' test is interesting, but a version which tells one the number of 'days to still to live' would be much more interesting ;-) | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Paul A. Bristow | Sent: Thursday, August 07, 2003 9:54 PM | To: Boost mailing list | Subject: RE: [boost] Re: time_duration bug in Boost 1.30.0 | | | I have built the date examples OK, but I am getting a compile error | when trying | to build the time_math.cpp example with MSVC 7.1 aka .net 2003 | | I:/boost_1_30_0\boost\lexical_cast.hpp(147) : error C2679: binary '<<' : no | operator found which takes a right-hand operand of type 'const | boost::token_iterator_generator::value_type' (or | there is no acceptable conversion) | with | [ | TokenizerFunc=boost::char_delimiters_separator, | | Iterator=std::basic_string,std::allocator< | char>>::co | nst_iterator, | Type=std::string | ] | I:/boost_1_30_0\boost\lexical_cast.hpp(146) : while compiling | class-template member function 'bool | boost::detail::lexical_stream::operator <<(const Source &)' | with | [ | Target=unsigned short, | | Source=boost::token_iterator_generator,st | d::basic_string,std::allocator>::con | st_iterato | r,std::string>::value_type | ] | | this is in lexical_cast | | bool operator<<(const Source& input) | { | return stream << input; | } | | I am not clear if this is a problem in lexical_cast or in date_time. Should I | wait for the 1.30.1 release or try to load an update? Or is this a | new problem? | | Thanks | | Paul | | PS There are also lots of confusing warnings, most, if not all, of which I | suspect could be casted away. | It would be really nice to get a clear compile, preferably in strict mode, | because this code is likely to be included by most user stuff, which will | repeatedly produce a host of junk warnings. | | (And other MS specific unhelpful warnings which could be dealt with by | | #ifdef _MSC_VER or BOOST_? | #pragma warning (disable : 4800) // inefficient bool conversion? | #endif | | As a general point, is there any reason why 'known to be unhelpful' warnings | like this cannot be disabled in Boost code? | | Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK | +44 1539 561830 Mobile +44 7714 33 02 04 | Mobile mailto:[EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] | | | | -Original Message- | | From: [EMAIL PROTECTED] | | [mailto:[EMAIL PROTECTED] Behalf Of Jeff Garland | | Sent: Thursday, August 07, 2003 2:02 PM | | To: Boost mailing list | | Subject: Re: [boost] Re: time_duration bug in Boost 1.30.0 | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Eric Ford's Quantity library may be revised for MSVC 7.1
| I have found that there are some changes are needed for Eric Ford Units system in |ebf_units.zip to meet the requirements of MSVC 7.1 - I presume to comply with C++ |Standard better. |(I surmise that other recent Standard Compliant compiler versions will also require this). But there are unsolved problems with some more advanced sequence code, perhaps linked to changes in Boost facilities. Eric has promised to revisit his version of a Units system in a couple of months time. |IMO there is still a great need for a units system. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: time_duration bug in Boost 1.30.0
I suggest that I wait for the 30.1 release to be available, retest with strict mode and then mail you off-list with results from .net 2003 aka 7.1. Thanks Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jeff Garland | Sent: Saturday, August 09, 2003 3:06 PM | To: Boost mailing list | Subject: RE: [boost] Re: time_duration bug in Boost 1.30.0 | | | On Thu, 7 Aug 2003 21:53:30 +0100, Paul A. Bristow wrote | > I have built the date examples OK, but I am getting a compile error | > when trying to build the time_math.cpp example with MSVC 7.1 aka | > .net 2003 | > | > I:/boost_1_30_0\boost\lexical_cast.hpp(147) : error C2679: binary | > '<<' : no operator found which takes a right-hand operand of type 'const | > | > I am not clear if this is a problem in lexical_cast or in date_time. | > Should I wait for the 1.30.1 release or try to load an update? Or | > is this a new problem? | | Sorry to be slow on the response. Glad to see you got the fix for this, it | has bitten alot of people... | | > PS There are also lots of confusing warnings, most, if not all, of | > which I suspect could be casted away. It would be really nice to get | | I believe several of the warnings have been resolved in the current CVS... | | > a clear compile, preferably in strict mode, because this code is | > likely to be included by most user stuff, which will repeatedly | > produce a host of junk warnings. | | I'm happy to work on reducing the warnings in level 4, but unfortunately the | regression tests are not run with these settings. Since I don't have access | to the .net compiler here it is difficult to get the needed feedback to | resolve them. So if we want to make this a requirement we definitely need | regression tests to use this policy. | | > (And other MS specific unhelpful warnings which could be dealt with by | > | > #ifdef _MSC_VER or BOOST_? | > #pragma warning (disable : 4800) // inefficient bool conversion? | > #endif | > | > As a general point, is there any reason why 'known to be unhelpful' warnings | > like this cannot be disabled in Boost code? | | I'd be fine with putting this in the config, but I could see some controversy | about this. It isn't entirely clear to me which code is producing these, | so maybe you can send me the details offlist and I can look into it. | | Jeff | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Preliminary submission: FC++
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Brian McNamara | Sent: Tuesday, July 29, 2003 5:43 AM | To: Boost mailing list | Subject: Re: [boost] Re: Preliminary submission: FC++ | | | Based on David's suggestion, I'll try to briefly define all the terms | I've used in my earlier post. This is most helpful and shows impressive potential. But there is quite a lot to curry ones mind ;-) May I suggest that as well as promised documentation, the excellent set of examples would benefit from a couple of enhancements: 1 Paste the output at the end as a comment, /* Output is: 2 4 6 8 10 */ 2 paste output or notes for more significant lines as a comment, for example: f(3, 2); // yields 5 3 Don't put using namespace boost::fcpp; but instead using fcpp::plus; using fcpp::minus; ... so the less functional programmer can see immediately what fcpp is providing for this module. (Just as using std::cout; std::transform; is very helpful to the less STL literate). 4 And of course examples like BOOST_CHECK(plus(2, 2) == 4); will also be useful to readers as well as providing a test suite. I look forward to getting my mind further round this stuff. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] FW: Eric Ford Units - changes needed for MSVC 7.1
--- Begin Message --- I have found that there are some changes are needed for Eric Ford Units system in ebf_units.zip (in the files section) to meet the requirements of MSVC 7.1 - I presume to comply with C++ Standard better. (I surmise that other recent compiler versions will also require this). In dimension_list.hpp there are numerous requirements for typename to prefix add_frac, sub_frac ... so these already long lines become, for example: typedef dimlist< typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value, typename add_frac::value > diml_type; I suspect there are many other similar changes needed. There is also what looks like a mistake in base_dimen.hpp where 'type' should be 'inv_diml' // struct mul_return_type::type > struct mul_return_type::diml_type > With these changes, I can execute example1. It compiles without 'langauge extensions' but there are also very many warnings at level 4 about unused variables, and very many examples of: j:\Cpp\FordFunctions\units\base_dimen.hpp(82): warning C4180: qualifier applied to function type has no meaning; ignored Is anyone working on this units system? Eric? Is anyone working on NIST/ Walter Brown units system now that it might compile with MSVC 7.1? There is still a great need for a units system. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] --- End Message --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Files of types *.ipp are OK even for MSVC ?
RTFM again :-(( Except that even knowing that answer, I couldn't get the help system to help. But Thanks Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Victor A. Wagner, Jr. | Sent: Saturday, August 09, 2003 8:38 PM | To: Boost mailing list | Subject: Re: [boost] Files of types *.ipp are unfriendly, especially to | MSVC ? | | | in vs.net 2003 you can menu->tools->options->projects->VC++Build | add *.ipp to the list | things then hilight, etc, just fine ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: time_duration bug in Boost 1.30.0
In that case, you might prefer to mail me off-list a zip of your most recent version. This might help you get a MSVC 7.1 strictly tested version ready for 1.31.0 Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jeff Garland | Sent: Saturday, August 09, 2003 10:59 PM | To: Boost mailing list | Subject: RE: [boost] Re: time_duration bug in Boost 1.30.0 | | | On Sat, 9 Aug 2003 20:00:08 +0100, Paul A. Bristow wrote | > I suggest that I wait for the 30.1 release to be available, retest | > with strict mode and then mail you off-list with results from .net | > 2003 aka 7.1. | | Do you mean 1.31.0 or 1.30.2? The changes I'm speaking of are not | in 1.30.2. I expect it will be awhile before 1.31.0. | | Jeff | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Insufficient significant digits using lexical_cast
I note that the 'precision' number of digits in lexical cast is obtained from digits10 +1 if(std::numeric_limits::is_specialized) { stream.precision(std::numeric_limits::digits10 + 1); } If, as I believe correct, the objective is to get all digits that can be significant, and can be read back in without loss of precision, this isn't always quite right according to: "Lecture notes on the status of IEEE 754 standard for binary floating point arithmetic" William Kahan http://http.cs.berkley.edu/~wkahan/ieee754status/ieee754.ps gives formula for number of decimal digits which are guaranteed to be correct on output and required for input to achieve maximum possible precision as a function of the number of significand bits (given by std::number_limits::digits). In C++ the full formula is: int significant_digits10 = int(ceil(1 + float_significand_digits * log10Two)); and using this formula : std::numeric_limits::digits = 24 significand bits std::numeric_limits::digits10 = 6 floor(float_significand_digits -1) * log10(2) = 6 ceil(1 + float_significand_digits * log10(2) = 9 all significant bits (note that the existing code gives 7 here, which is 2 too few) std::numeric_limits::digits = 53 std::numeric_limits::digits10 = 15 floor(double_significand_digits -1) * log10(2) = 15 ceil(1 + double_significand_digits * log10(2)) = 17 (note that the existing lecial_cast.hpp code gives 16 here, which is 1 too few) 32 significand bits digits10 = 6 significant_digits10 = 9 53 significand bits digits10 = 15 significant_digits10 = 17 64 significand bits digits10 = 18 significant_digits10 = 21 106 significand bitsdigits10 = 31 significant_digits10 = 33 113 significand bitsdigits10 = 33 significant_digits10 = 36 128 significand bitsdigits10 = 38 significant_digits10 = 40 (note that the rest are a few too few) I have proposed before that numeric limits should have another item called, perhaps, significant_digits10 returning these useful values, but meanwhile I suggest that following the style of boost/limits.h BOOST_STL_DECLARE_LIMITS_MEMBER(int, digits10, (digits * 301) / 1000); // log 2 = 0.301029995664... The integer fraction 301/1000 is needed to avoid suggeating to the compiler that it should do a floating point calculation (which silently fails!) so the following formula is used instead: int const sig_digits10 = 2 + std::numeric_limits::digits * 301/1000; // log10(2.) This gives the same result without using the ceil function which might not be computed at compile time. So in lexical_cast, substitute for example the above fragment with: if(std::numeric_limits::is_specialized) { // Show all significant decimal digits, 2 or 3 more than digits10. stream.precision(2 + std::numeric_limits::digits * 301/1000); } // & similarly for Source A suggested revision and test attached, for example showing float & double now have extra decimal digits. Boost release 30 outputs: 1.414214 1.414213562373095 Revised version outputs: 1.41421354 1.4142135623730951 And it is thus now possible to convert float & double to a string and back again to give exactly the same as the original float & double (which the current version sometimes does not - a pit for the unwary). Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] test_lexical_cast.cpp Description: Binary data lexical_cast.hpp Description: Binary data testLexical_cast.vcproj Description: Binary data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Files of types *.ipp are unfriendly, especially to MSVC ?
Many thanks for this - works for me too. HKLM\SOFTWARE\Microsoft\VisualStudio\7.1\Languages\File Extensions.ipp" {B2F072B0-ABC1-11D0-9D62-00C04FD9DFD9} makes it edit like .cpp But I still doubt if files should be called .ipp. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Randy Bowen | Sent: Friday, August 08, 2003 6:05 PM | To: Boost mailing list | Subject: RE: [boost] Files of types *.ipp are unfriendly, especially to | MSVC ? | | | On the specific issue of MSVC integration: Assuming you're using MSVC | 7.[01], the mapping of file extensions to editors is declared in the | registry. Specifically, the entries under | "HKLM\SOFTWARE\Microsoft\VisualStudio\7.1\Languages\File Extensions" are | extension keys whose default value is the CSLID of the editor. So | simply creating a new entry for ".ipp" and copying the CLSID listed for | ".cpp" will give you your C++-specific editing features in MSVC. (We do | this as part of our standard installation here, since ".tpl" is an | standard extension for template implementation files internally.) | | Whether use of ".ipp" as a standard extension is a good idea is, of | course, a different discussion. | | Randy Bowen | Stamps.com | | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: time_duration bug in Boost 1.30.0
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Friday, August 08, 2003 1:31 PM | To: Boost mailing list; [EMAIL PROTECTED] | Subject: Re: [boost] Re: Re: time_duration bug in Boost 1.30.0 | | | At 05:27 PM 8/7/2003, Bo Persson wrote: | > | >"Paul A. Bristow" <[EMAIL PROTECTED]> wrote: | > | >> | >> (And other MS specific unhelpful warnings which could be dealt with | >by | >> | >> #ifdef _MSC_VER or BOOST_? | >> #pragma warning (disable : 4800) // inefficient bool conversion? | >> #endif | >> | >> As a general point, is there any reason why 'known to be unhelpful' | >> warnings like this cannot be disabled in Boost code? | >> | > | >A problem here is that the "inefficient bool conversion" often | >actually *is* an inefficient implicit conversion to bool. IME, most of | >these warnings can be removed by actually producing a bool value. | >Adding == 0 or != 0 is often all it takes. | | FWIW, I've done that for years in my own code, and have come to believe | that it results in better code. It makes the intent clear to someone | reading the code. With an implicit conversion, a reader is unsure whether | or not the conversion was intended. | | To answer Paul's question, some of the toolsets do disable "known to be | unhelpful" warnings. But I agree with Bo that this warning shouldn't be one | of them. | | --Beman Agree with everything the previous speakers have said. Can we document our preference for Boost code to compile warning free in strict mode (MSVC, correct for loop scope, no language extensions and warnings level 4)? I sense that accepting the MS defaults(incorrect for loop scope, language extensions and warnings level 3) is not setting the bar as high as we reasonably could. Of course, it won't always be possible, but from much Boost code, I believe that with a very small additional effort by authors, much code could meet this standard. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Files of types *.ipp are unfriendly, especially to MSVC ?
Spirit and date_time use some files of type *.ipp (they are included 'internally'). I had the misfortune to be reading one using MSVC which does not recognize this as a C++ type and so they are not shown in color, nor laid out etc. Although these are 'private' detail files, I wonder if *.ipp should be deprecated for Boost code? I also found that one date_time file gregorian_calender.ipp includes 0D 0D 0A sequences which double spaces it and, more confusingly, confuses the MSVC IDE editor so that warnings appear on the wrong line :-( (Perhaps Jeff Garland would like to fix this in gregorian_calender.ipp sometime?) I understood that a check program had been devised for this 'mis-feature'. Was this missed because it is not a C++ type 'known' to the checker program? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Slight revision to more-I/O
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daryle Walker | Sent: Saturday, July 19, 2003 8:38 AM | To: Boost | Subject: [boost] Slight revision to more-I/O | | In the latest post-review version, I fully disabled copying for the | array-based stream-buffer class. I also copied the revised version of | the library to | http://groups.yahoo.com/group/boost/files/more_io_revised.zip The iostate saving and iomanip seem fine, but I am left uncertain on how to use the stream buffer class in practice. More user-oriented documentation, tests and examples would be helpful. (And also there seem to be differing, perhaps competing, perhaps conflicting, offerings in filtering/decorating stream buffers). Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Revised streambuf library
Sadly the test program fails to compile MSVC 7.1 as indicated below: template > struct basic_string_source : private base_from_member< std::basic_string >, public iterator_source< typename std::basic_string::iterator, Ch, Tr > { typedef std::basic_string string_type; typedef typename string_type::iterator iterator; typedef iterator_source base_type; typedef Ch char_type; typedef Tr traits_type; typedef source_tag io_category; basic_string_source(const string_type& source) : base_type(member.begin(), member.end()) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< { } }; | | I have posted a new version of my library, which has been rewritten to | incorporate filtering as a basic construct. | (http://groups.yahoo.com/group/boost/files/streambuf_lib.zip) with member not found Looks as though it should be source.begin() but that doesn't compile either: J:\Cpp\streambuf_lib\boost\io\adapters.hpp(159) : error C2664: 'boost::io::iterator_source::iterator_source(InIt,InIt)' : cannot convert parameter 1 from 'std::basic_string<_Elem,_Traits,_Ax>::const_iterator' to 'std::basic_string<_Elem,_Traits,_Ax>::iterator' with [ InIt=std::basic_string,std::allocator>::iterat or, Ch=char, Tr=std::char_traits ] and [ _Elem=char, _Traits=std::char_traits, _Ax=std::allocator ] and [ _Elem=char, _Traits=std::char_traits, _Ax=std::allocator ] No constructor could take the source type, or constructor overload resolution was ambiguous J:\Cpp\streambuf_lib\boost\io\adapters.hpp(158) : while compiling class-template member function 'boost::io::basic_string_source::basic_string_source(const boost::io::basic_string_source::string_type &)' with [ Ch=char ] testStreambuf_lib.cpp(57) : see reference to class template instantiation 'boost::io::basic_string_source' being compiled with [ Ch=char ] There are also zillions of warnings j:\Cpp\streambuf_lib\boost\io\chains.hpp(267) : warning C4224: nonstandard extension used : formal parameter 'chain' was previously defined as a type j:\Cpp\streambuf_lib\boost\io\chains.hpp(271) : see reference to class template instantiation 'boost::io::chain_client' being compiled MS 'Help' says: nonstandard extension used : formal parameter 'identifier' was previously defined as a type The identifier was previously used as a typedef. This causes a warning under ANSI compatibility (/Za). Example // C4224.cpp // compile with: /Za /W1 /LD typedef int I; void func ( int I ); // C4224 Suggestions? It would be nice if a working example of a filter was provided too - perhaps one of the James Kanze examples like 'expand tabs to spaces'. Or is this an exercise for the student? Thanks Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Formal Review: fixed-point decimal library
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jens Maurer | Sent: Wednesday, July 09, 2003 5:07 PM | To: [EMAIL PROTECTED]; [EMAIL PROTECTED] | Subject: [boost] Formal Review: fixed-point decimal library Overall I vote to accept this in the Boost library. It appears to meet the needs of both COBOL programmers and Bean Counters :-) More detailed and more expert comments have been received, but from a brief perusal of the documentation and a build of the trydec test program using MSVC 7.1, I have a few minor observations and comments: 1 There are some warnings using 'strict' which are probably cast avoidable: fixed_decimal.hpp(442) : warning C4389: '==' : signed/unsigned mismatch fixed_decimal.hpp(446) : warning C4018: '<' : signed/unsigned mismatch fixed_decimal.hpp(450) : warning C4018: '>' : signed/unsigned mismatch 2 Using namespace std; is needed for more than cout. Also namespace fixdec would be more helpfully replaced by "using numeric::decimal;" This makes it obvious what is being demonstrated. 3 The sample program output could helpfully be added and made more obvious, for example by changing to output: numeric_limits::is_specialized is true numeric_limits::radix is 10 numeric_limits::digits 9 numeric_limits::digits10 9 numeric_limits::epsilon() 0.1 and cout << setprecision(2) << showbase << dp // 2052.00 << " " << showmoney << dp //$2,052.00 << " " << showintl << dp << "\n" // USD2,052.00 << noshowmoney << noshowintl << dn // -1,026.00 << " " << showmoney << dn << " " // -$1,026.00 << showintl << dn << "\n"; // USD-1,026.00 And adding the complete output as a comment is very helpful. /* Output: ... numeric_limits::is_specialized is true ... */ 4 I agree that decimal implies fixed so fixdec is a not very nice name - spare a thought for those whose native language is not english. I believe the best namespace is numeric. I don't think this will deter even COBOL programmers! 5 Overall a much better demo program would be valuable to sell this to average users. For example, all the examples in the html doc might be included in trydec.cpp. The default C locale doesn't produce interesting results, so adding cout.imbue(locale("English_United States.1252")); (macroized for other OS?) would be more 'interesting' if dollar-centric. 6 A test program is needed (promised but ...). Comments make tests a very valuable learning tool. 7 The documentation is mainly pitched at a too high a level for users and mixes detailed rationale with user info. The 'Boost Standard' format might be more suitable? 8 The synopsis might be commented better, for example: decimal(int, int); // scale, value 9 I really don't like the name scale at all. Nor deffrac, decscale and iosprec. Can't we do better than this, even if longer? These are going to be very visible in user code, but not at all obvious meaning. 10 You could usefully add an example of explicit limits for the common 32 bit system max amount is $21,474,836.47 - OK if you are invoicing from a hardware store, but for 64 bit ?92,233,720,368,547,758.07 may suit Enron-type accountants better. Can you give some clues to the probable performance cost of using 64 bits on X86 systems? Hope this will help you get wide use of this useful code. Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan - how to flag missing values?
Thanks but this still leaves me feeling that there is a need for a 'Standard and Portable' way of indicating 'missing value', but perhaps this will remain one of the many unmet needs. Choosing a bit pattern(s) for 'missing value'etc doesn't seem easily portable from your other posts on detecting NaNs in general. Does we have to have processor specific macros to implement an bool is_missing(double)? Can one be sure that the bit pattern chosen for the 'missing value' NaN won't be produced from a computational mishap? Is there a reason why it should it be a quiet or signalling NaN? Leaves me a bit :-( Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Wednesday, July 16, 2003 10:46 PM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan - how to flag missing values? | | | "Paul A. Bristow" <[EMAIL PROTECTED]> writes: | | | | Signalling NaNs are used to indicate missing initialization values. | | | | This is OK for catching missing initialization by mistake - but not | | for OK for deliberately missing because there really is no value | | (measurement missing). | | There is not just one qNaN (nor just one sNaN). There is a range for | NaNs. And most of the systems I worked with, the pattern bits in a | NaN is used to communicate the reason of being of the NaN. For | example, it may output sNaN("missing-value"). | | Note: C99 provides a pseudo-standard way to produce NaNs, through the | functions | | double nan(const char*); | float nanf(const char*); | long double nanl(const char*); | | | | | In this case, for example calculating the mean, you want to test if | the value is | | present/valid 'is_not_missing' before you add it to the sum and | increment the | | count. | | | | Testing !is_nan is possible solution but I'm not sure it is ideal. | | Indeed, it is no good. | | | Suggestions? | | I would first make a summary of the usage of the bit patterns for NaNs | and decide on one and document it. | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: test_fp_comparisons and rounding errors
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Rozental, Gennadiy | Sent: Friday, July 11, 2003 7:39 PM | To: 'Boost mailing list' | Subject: RE: [boost] Re: Re: test_fp_comparisons and rounding errors | | | > Do I understand correctly that | > | > BOOST_CHECK_CLOSE(v1, v2, 2. * std::numeric_limits::epsilon() ); | > | > would check that the absolute difference between v1 and v2 is | > not more than two eps? | > | > Paul | | No. BOOST_CHECK_CLOSE performs relative errors comparison. See | http://www.boost.org/libs/test/doc/floating_point_comparison.htm | | (Ignore part that tries to calculate the tolerance based on number of | rounding errors) | | Gennadiy. | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: test_fp_comparisons and rounding errors
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Rozental, Gennadiy | Sent: Friday, July 11, 2003 7:39 PM | To: 'Boost mailing list' | Subject: RE: [boost] Re: Re: test_fp_comparisons and rounding errors | | | > Do I understand correctly that | > | > BOOST_CHECK_CLOSE(v1, v2, 2. * std::numeric_limits::epsilon() ); | > | > would check that the absolute difference between v1 and v2 is | > not more than two eps? | > | > Paul | | No. BOOST_CHECK_CLOSE performs relative errors comparison. See | http://www.boost.org/libs/test/doc/floating_point_comparison.htm | | (Ignore part that tries to calculate the tolerance based on number of | rounding errors) | | Gennadiy. Yes of course - sorry. So how would I achieve the above test? Personally I would still like to have the option of picking the absolute number of epsilons difference allowed - the number of least significant bits that are different. You are right that relative difference is usually what one wants - but not always in my experience. But I think that presenting it as 'number of rounds' is what is confusing and contentious. Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Sunday, July 13, 2003 9:22 AM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | And can anyone help with allowing one to easily customise the | display of NaNs?(and infs, max, min...?) | | I believe that a new (derived) num_put facet is the way | | to do this. | Does anyone have an actual implementation of this to contribute too? | | I'm willing to volunteer but I'm not sure I really understand the | question. Can you elaborate a little bit? | | -- Gaby If you 'show' a qNaN (or indeed an sNaN) with MSVC, you get cout << "The quiet NaN for type float is: " << numeric_limits::quiet_NaN( ) << endl; Output: The quiet NaN for type float is: 1.#QNAN But suppose you want to display another message instead, perhaps to output data for input by some other system that recognizes all qNaNs as, say, "NaN", so the output would be The quiet NaN for type float is: NaN AND would be portable for all platforms, of course. Similarly for infs, max, min - if you get floating point inf, max or min as a result of a calculation, it should be shown as special to the reader? Paul PS IMHO This is more important than it may appear because it, with the lack of a Standard isnan test, is preventing real-life use of NaNs. Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan - how to flag missing values?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Sunday, July 13, 2003 9:22 AM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | "Paul A. Bristow" <[EMAIL PROTECTED]> writes: | | There is also a single IEEE FP pattern called 'indeterminate' or | what Intel call | | 'NotAVal" (0x1fffe000...) which might become useful as a Portable Standard | | "missing value" marker if portably supported? | I won't take that road. Well if not then can you suggest a potentially Portable and Standard way to indicate 'missing values' in arrays etc of floating point values. I'm not sure that a qNaN is the best way to do this - it seems better suited to the result of compuational mishaps. | Signalling NaNs are used to indicate missing initialization values. This is OK for catching missing initialization by mistake - but not for OK for deliberately missing because there really is no value (measurement missing). In this case, for example calculating the mean, you want to test if the value is present/valid 'is_not_missing' before you add it to the sum and increment the count. Testing !is_nan is possible solution but I'm not sure it is ideal. Suggestions? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost Bibliography?
Since most academic journals are moving to abolish printed versions (by pricing out of reach), I think we would be a bit silly to exclude on-line only stuff. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Thursday, July 10, 2003 8:57 PM | To: Boost mailing list; Boost mailing list | Subject: Re: [boost] Re: Boost Bibliography? | | | At 12:12 PM 7/10/2003, Rene Rivera wrote: | >[2003-07-10] James Curran wrote: | > | >>How directly must the article relate to Boost? I spend about 4 | >>paragraphs discussing Boost & shared_ptr<> in: | >>"Access Raw Data with Performance Counters in Visual C++" | >>DevX.com: http://www.devx.com/cplus/article/7951 | > | >I have a similar question; is online only material to be included? For | >example this one: | > | >http://www.codeproject.com/vcpp/stl/BoostIntro.asp | >The Code Project - An Introduction to Boost - STL | | Another dimension? "Print" vs "Online"? | | --Beman | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: test_fp_comparisons and rounding errors
I suggest you show how to get an absolute comparison in the documentation. I have found absolute comparisons most useful (but also relative sometimes). Do I understand correctly that BOOST_CHECK_CLOSE(v1, v2, 2. * std::numeric_limits::epsilon() ); would check that the absolute difference between v1 and v2 is not more than two eps? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gennadiy Rozental | Sent: Wednesday, July 09, 2003 10:55 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Re: test_fp_comparisons and rounding errors | | | | > Could you please be more specific about which Boost.Test features you | think | > should remain and which should be removed or modified? I'm having trouble | > relating the discussion to the actual Boost.Test public interface. | > | > Thanks, | > | > --Beman | | The only thing I propose to change is to prohibit defining tolerance by the | number of rounding errors. User still will be able to use BOOST_CHECK_CLOSE | tool with the FP tolerance as a third parameter. | | Gennadiy. | | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost Bibliography?
Fine. Encourage/remind reference submitters to include book ISBN & journal ISSN. EG Dr Dobbs Journal is ISSN 1044-789X. And DOI if available (Digital Object Identifier) see doi.org - these are permanent liks which do not change if the underlying host server changes name or address. A program 'resolves' the DOI to get you the document. Trendy now but becoming standard for academic journals. and to provide web links AS WELL AS paper ones? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Wednesday, July 09, 2003 3:35 PM | To: Boost mailing list | Subject: [boost] Boost Bibliography? | | | I've had a request that we set up a web page listing publications about | Boost or Boost Libraries. The point being that it will be generally | interesting, and possibly useful as a historical record. If Boost or any | participants ever apply for a grant, such a bibliography is often required. | | Presumably such a page would go in the "more" directory, and be linked to | from the home page. | | Attached is a quick draft of a "Boost Bibliography" page. Each entry is | bookmarked so it can be referenced directly from other web pages. | | Comments? | | --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Draft of new Boost Software License
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams | Sent: Tuesday, July 08, 2003 7:57 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Draft of new Boost Software License | ... www.boost.org was pretty stable, thus far. | | The problem is that we don't want to force companies to assume the | risk that www.boost.org will stick around. My original point was only that we should reduce the risk of a 'dangling pointer' by considering additions or alternative to a master copy on www.boost.org. After all, Boosters seem obsessed with 'smart pointers' :-)) So it would be really bad form to create one! Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan
I think this would be excellent (and overdue). It needs to support double and long double (and facilitate UDTs too if possible). There is also the matter of signalling and quiet NaN. Although signalling NaN may cause an hardware exception if enabled, I suspect it is more useful if isnan returns ture for both types of NaN. At least we should make this clear. I think this is what MSVC 7.1 does but the documentation is thin. There is also a single IEEE FP pattern called 'indeterminate' or what Intel call 'NotAVal" (ox1fffe000...) which might become useful as a Portable Standard "missing value" marker if portably supported? And can anyone help with allowing one to easily customise the display of NaNs? (and infs, max, min...?) I believe that a new (derived) num_put facet is the way to do this. Does anyone have an actual implementation of this to contribute too? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Joel de Guzman | Sent: Monday, July 07, 2003 5:15 PM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | Fernando Cacciola <[EMAIL PROTECTED]> wrote: | > Fernando Cacciola <[EMAIL PROTECTED]> wrote in message | > news:[EMAIL PROTECTED] | >> | >> Thanks to Gabriel we may have an is_nan() right now. | >> | > Oops! | > It was Joel de Guzman who offered his is_nan() implementation. | > | > Sorry Joel :-) | | No problem. I thought Gaby also offered an implementation ahead of me. | So you guys are interested then? It would really be nice to have a | common boost implementation. I'll put it in the sandbox tomorrow. | | -- | Joel de Guzman | joel at boost-consulting.com | http://www.boost-consulting.com | http://spirit.sf.net | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] is_nan
I have just seen a similar warning with the interval library. However (v != v) does now work as expected on MSVC 7.1 (all comparisons with NaN fail) so I think it does work OK for this compiler. But it would be much better if isNaN was properly defined somewhere. Perhaps we have to wait for the Standards committee to see if C99 is to be added to the C++ Library. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of jvd | Sent: Friday, July 04, 2003 12:34 PM | To: Boost mailing list | Subject: [boost] is_nan | | | Dear boosters, | | seems like this code | | template< typename T > | bool is_nan( const T& v ) | { | return std::numeric_limits::has_quiet_NaN && (v != v); | } | | does not work correctly on some machines. | | As far, as I can remember, intervals library also use similar implementation | of is_nan. So there should be just the same problem. | | Respect, | Justinas V.D. | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Draft of new Boost Software License
Another possible place - but Digital Object Identifiers are the Right Way to Do It, I believe. All the scientific journals are using it - but it may cost too much. Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Alexander Terekhov | Sent: Wednesday, July 02, 2003 11:43 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Draft of new Boost Software License | | | | "Paul A. Bristow" wrote: | [...] | > May I suggest consideration of what happens in a decade or two when | boost.org | > might not longer exist to provide a reference, but we still need to | ensure that | > the license terms are still available. | | http://web.archive.org/web/2229041743/http://www.sco.com/offers/an | cient_unix.html | | regards, | alexander. | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] filtered/decorated streambufs
Posted to files area as "http://groups.yahoo.com/group/boost/files/filter streams.zip" HTH Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Larry Evans | Sent: Friday, June 27, 2003 2:34 PM | To: Boost mailing list | Subject: Re: [boost] filtered/decorated streambufs | | | Paul A. Bristow wrote: | > I also have an updated ('C++ 1998 STL standardized') version of | James Kanze's | > of filtering streambuf and filtering streams derived from his files at | > www.gabi-soft.fr re-built for MSVC 7.1, (Could be posted on request). | | Please do. | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: filtered/decorated streambufs
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Larry Evans | Sent: Saturday, June 28, 2003 3:07 PM | To: Boost mailing list | Subject: Re: [boost] Re: filtered/decorated streambufs | > What advantages does your style have? [big snip] | I can see much logic in your layout (much more perhaps than in the C language!) but sadly, I think the balance of pros and cons is in favour of sticking to a consistent style for a library like Boost code guidelines. (Layout really does matter - I even find when using a colour display - I use MSVC IDE editor or Textpad - changing the keyword colours causes my small brain to take longer to understand the code. IMHO, the diabolical choices for variables names is a significant factor in general users reluctance to get 'into' streambufs). Paul PS I am studying Daryle's most recent work on filtering streambufs, though I find 12 thingys complex - it exceeds the number of digits on both hands :-)) Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Friday, June 27, 2003 7:23 PM | To: Boost mailing list; [EMAIL PROTECTED] | Subject: RE: [boost] Draft of new Boost Software License | | | In non-Boost code, I've seen wording something like "See the attached | license; if it is missing see www.foo.org/license." Maybe something like | that is what will be recommended. | | They've already signed off on the concept of a single copy of the license. | It is just the exact way to refer to it that hasn't been finalized. | | --Beman May I suggest consideration of what happens in a decade or two when boost.org might not longer exist to provide a reference, but we still need to ensure that the license terms are still available. Would it be best to refer (additionally perhaps) to a Digital Object Identifier (see doi.org) which provides a permanent reference to the actual license file. So if boost.org is renamed, say, the reference is still correct because it will be 'resolved' (in the DOI jargon) to a new location as boostTwo.org. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] filtered/decorated streambufs
I also have an updated ('C++ 1998 STL standardized') version of James Kanze's of filtering streambuf and filtering streams derived from his files at www.gabi-soft.fr re-built for MSVC 7.1, (Could be posted on request). and his illuminating articles in C++ Report 1998 (attached). There are also several examples of Inserting (decorating - not sure this term is an improvement) and Extracting on input, and some tests (though not Boost style test suite, a possible TODO item). His examples include: Output: prefixing each non-blank line by a timestamp. translating each char with a mapping table. expanding tabs. Input: translating each char with a mapping table. removing 'comments' after # (say) upto the end of line. rebuilding continuation lines. Sadly I didn't spot much documentation or examples of Daryle's quite complex code, which looks to have quite a lot in common with this code that Larry Evans is threatening to use. (More sadly, I was much impeded in trying to understand much of Larry's work in progress on account of the bizarre layout - this would be an serious impediment to acceptance by Boosters - see the Boost coding guidelines?) However, both the filtering stream process, and the application to several layout desiderata that various people have been chipping away at, seem important items for Boost library. I'd like to encourage both of these. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daryle Walker | Sent: Friday, June 27, 2003 6:40 AM | To: Boost | Subject: [boost] Someone wanted filtered/decorated streambufs? | | | For the past few weeks, some posters were talking about streambufs that | can decorate another stream buffer. I wrote up a general class at | <http://groups.yahoo.com/group/boost/files/filter_stream.hpp>. | | The non-virtual filter functions act as a pass-through (i.e. no change) | filter/monitor at the moment. We would need to figure out the points | of customizing before adding the virtual filter functions. For | instance, "doing_imbue" could have a virtual "do_postonly_imbue" that | only lets the filter do its own adjusting for locale changes after the | main stream buffer has already done its adjustments. The "doing_sync" | method could have a virtual "do_preonly_sync" that is called before the | main stream buffer's syncing, and the virtual method could return a | Boolean determining if the main buffer should continue. The other | "doings" could have pre- and post-actions (no "only," of course). | | One difficulty would be if the reading and/or writing overrides need | to store extra characters. Maybe I could add reserve space in the | filtering stream buffer | | Daryle | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | Title: Filtering Streambufs Filtering Streambufs Variations on a Theme by Schwarz by James Kanze Introduction There has been much discussion in the last couple of years concerning the STL, and the abstraction of a sequence (materialized by its concept of iterator) that it so elegantly uses. Strangely enough, however, another major abstraction in the proposed standard library doesn't seem to get much attention, that of an abstract data sink and/or source, as materialized in Jerry Schwarz's streambuf. This may be partially due to the fact that most people only use the formatting interface, and somehow only associate the streambuf with IO. In fact, IO is only a special case of the more general abstraction of a data sink or source. In this article, I will concentrate on one particular variation of this abstraction, which I call a filtering streambuf. In a filtering streambuf, the streambuf in question is not the ultimate sink or source, but simply processes the data and passes it on. In this way, it acts somewhat like a pipe in UNIX, but within the process. Anyone who has worked with UNIX is familiar with just how powerful this piping idiom can be. Many different filtering streambuf's are possible: on input, we can filter out comments, or merge continuation lines; on output, we can expand tabs, or insert timestamps. Ideally, we would like to write as little code as possible, which suggests some sort of generic class to handle the boiler plating, with only the actual filtering to be written for each use. One small note: the iostream library has evolved some in the standards committee, and different compilers will have different versions. For convenience, I've based the fo
RE: [boost] Interest in FC++?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Brian McNamara | Sent: Wednesday, June 25, 2003 7:46 PM | To: [EMAIL PROTECTED] | Subject: [boost] Interest in FC++? | | | I would like to see if there is interest in incorporating the FC++ | library into Boost. This has got to be interesting. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Rene Rivera | Sent: Wednesday, June 25, 2003 8:26 PM | To: Boost mailing list | Subject: Re: [boost] Draft of new Boost Software License | | Spanish is my first, but English is a very close second. | The impression I got is that it's somewhat hard to parse as it is. | | The second paragraph is long; and without any separators other than the commas it's | hard to read. | | Here's an edited version which might be better for non-english readers to | understand: | | | Permission is hereby granted ... | all derivative works of the Software. Unless such copies or derivative works | are solely in the form of machine-executable object code generated by a | source language processor. As someone whose first language really is english - unlike the majority of ex-colonial Boosters :-)) I really must protest that the last 'sentence' isn't one! Seriously, overall I think this is excellent. It isn't meant to be read by human beings, only lawyers - and they are used to this stuff. And: // (C) Jane Programmer, 2003 // See www.boost.org/license for license terms and conditions // See www.boost.org/libs/janes-lib for documentation Looks fine to me, though I prefer "Copyright" to (C) Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math constants - nearest values - are they valued?
I am now confident that I understand what you are proposing. It certainly seems "The Right Thing To Do" (tm) but is more complicated for me to calculate, though not too bad. I would welcome confirmation from other potential users that they agree. Paul PS Of course the problem of macro, function, template function is still to be resolved and is still being worked on elsewhere. PPS I couldn't see in the ISO C++ spec if float and double is required to be 32 and 64 bits. Any Language Lawyers care to say? | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Guillaume Melquiond | Sent: Wednesday, June 25, 2003 8:59 AM | To: Boost mailing list | Subject: RE: [boost] Re: Math constants - nearest values | | | On Sun, 22 Jun 2003, Paul A Bristow wrote: | | > | Consequently, more than one constant out of 1 may suffer | > | from this problem. So it is rare, but it is not impossible. | > | It's why I was suggesting that a library should provide a | > | mean to know if a number representing a constant is the | > | nearest or not. | > | > One constant out of 1 seems a rather small risk. | | > Can't we just check that all the constants we offer are in fact the | > nearest? | | Yes. | | > Since very few contain many zeros, I think I am prepared to wager a few | > beers on this one! | | > So does this mean that the presentation function will use the 'exactly | > representable' decimal digits appropriate for the floating point format | > (choice of 5) and for the FP type float, double, long double to give to | > the compiler to use? | | Sorry, I'm not sure I clearly understand what you mean. What I would do is | something like | | float the_constant_f = ... /* a 24 binary digits representation */; | double the_constant_d = ... /* a 53 binary digits representation */; | long double the_constant_ld = | #ifdef LONG_DOUBLE_IS_80_BITS | ... /* a 64 binary digits representation */; | #elif defined(LONG_DOUBLE_IS_128_BITS) | ... /* a 102 binary digits representation */; | #else /* we don't know this floating-point format */ | ... /* a 40 decimal digits approximation */; | #define the_constant_LONG_DOUBLE_MAY_NOT_BE_ACCURATE | #endif | /* And then there would be all the wrappers... */ | | The binary representations will be exact values in order to avoid compiler | rounding. So all possible floating-point formats should be thought of. | However, if one of them is missing, we fall back on a common 40 decimal | digits constant. Since we can't be sure there won't be any rounding | problem, we flag the result as being "maybe inaccurate". Does it make | sense? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Math Constants Formal Review - MSVC 7.1 with Slettebosuggestion
The good news is that I can get this suggestion to compile using MSVC 7.1 by adding a cast to resolve ambiguity template inline T area(T radius) { return (T)math::pi * radius * radius; // (T)math::pi required to avoid ambiguity // std::cout << "Area (float) = " << area(1.0f) << std::endl; //Sletteboe_constants1.cpp(35) : error C2593: 'operator *' is ambiguous //could be 'built-in C++ operator*(float, float)' //or 'built-in C++ operator*(int, float)' //or 'built-in C++ operator*(double, float)' //or 'built-in C++ operator*(long double, float)' //while trying to match the argument list '(const boost::math::pi_type, float)' //Sletteboe_constants1.cpp(40) : see reference to function template instantiation 'T area(T)' being compiled //with //[ //T=float //] // so added explicit(T) } This seems to say that, like me, MSVC compiler writers don't know what Gennaro Prota does, and told/reminded us recently: "Now, if you use the binary operators, like in: pi * f; with f being a float then the selected specialization is float; i.e. the constant "takes the type" of its adjacent operand (left operand if it exists, right operand otherwise)." (Though sometimes one might prefer to do the calculation using double and only finally truncate to float - but this does what one would expect. Does return static_cast((double)math::pi * radius * radius); do what might avoid overflow in other circumstances?) I also find that the explicit constructor is NOT required (even if 'strict') in: const struct pi_type { //pi_type() {} // Explicit Constructor not needed for MSVC 7.1 template operator T() const; } pi; // name What does Intel 7.1 want? BUT I REALLY don't like having to type (float)math::pi each time. How can this be avoided? Users will expect to be able to just type pi or equations will be most confusing to read, and tiresome to write. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] PS The Bad News is that in wrongly manually expanding a macro in order to try to understand what and how this is working I caused the IDE to hang during editing - to my total astonishment :-(( So this may be too advanced a solution for MSVC 7.1 ? | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Terje Slettebø | Sent: Sunday, June 22, 2003 2:33 AM | To: Boost mailing list | Subject: Re: [boost] Math Constants Formal Review | | --- Start --- | | #include | | #define BOOST_DEFINE_MATH_CONSTANT(name)\ | const struct name##_type\ | {\ | name##_type() {}\ | template\ | operator T() const;\ | } name; | | #define BOOST_MATH_CONSTANT_VALUE(name, type, value)\ | template<>\ | name##_type::operator type() const { return value; } | ... | | --- End --- | | Output: | | Area (float)=3.1 | Area (double)=3.14 | Area (long double)=3.141 | PI=3.1, 3.14, 3.141 | Terje | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Math Constants Formal Review
I have now been able to try your suggestions using MSVC 7.1 (rather than the undoubtedly better Intel 7.1 version (was KAI?)) cout << (float) math::pi etc are OK (though does this imply that every use of pi need to include the cast? This would NOT be at all popular because it would obscure the meaning of equations :-( With Kenniston's namespace one can simply declare "I'm only using doubles" with using namespace boost::math::double_constants; Alas, the area example doesn't work because MSVC 7.1 does not resolve the ambiguity in std::cout << "Area (float) = " << area(1.0F) << std::endl; // <<<< Note float argument Sletteboe_constants1.cpp(35) : error C2593: 'operator *' is ambiguous could be 'built-in C++ operator*(float, float)' or 'built-in C++ operator*(int, float)' or 'built-in C++ operator*(double, float)' or 'built-in C++ operator*(long double, float)' while trying to match the argument list '(const boost::math::pi_type, float)' Sletteboe_constants1.cpp(40) : see reference to function template instantiation 'T area(T)' being compiled with [ T=float ] Should it? Suggestions? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Terje Slettebø | Sent: Sunday, June 22, 2003 2:33 AM | To: Boost mailing list | Subject: Re: [boost] Math Constants Formal Review | This is tested on Intel C++ 7.1, but it should work on most compilers, | especially if workarounds are applied, if needed. | | As shown, this works well with generic code, like the "area()" function. | | My question is: Is there any reason why it can't be done this simple? | | Note that there are no extra classes or functions needed. There's only the | class representing the constant, and the templated conversion operator, and | any specialisations of it. This should be trivial for a compiler to inline, | and should also be easy to examine with a debugger (an issue that also has | come up). | | This is very easy to extend with new constants and types. It's an open-ended | system. | | It uses macros for easy definition of constants and their values for | different types, for easy definition (just like Kenniston's and Daniel's | approach). | | The above addresses the presentation of the constants (their interface), as | identified by Paul as one of the primary objectives. What values that are | used in the definitions is orthogonal to this. | | | Regards, | | Terje | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Math constants - efficiency
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Monday, June 23, 2003 7:44 PM | To: [EMAIL PROTECTED] | Subject: [boost] RE: Math constants - efficiency | | | On Mon, 23 Jun 2003 19:54:36 +0200, Paul A. Bristow wrote: | | > These are interesting results, but my enthusiasm is severely reduced by | > the fact that MSVC 7.1 (Standard) chokes terminally on both versions | > :-(( | > | > Compiling... | > Frey_bench_mark_gcc.cpp | > Frey_bench_mark_gcc.cpp(82) : warning C4305: 'return' : truncation from | > 'double' to 'float' | > Frey_bench_mark_gcc.cpp(108) : fatal error C1001: INTERNAL COMPILER | > ERROR | > (compiler file 'msc1.cpp', line 2701) | > Please choose the Technical Support command on the Visual C++ | > Help menu, or open the Technical Support help file for more | > information | | ??? Line 108 is the static_cast< double >( pi ) for me. How can it compile | the three lines before but choke on 108? I think I will still have to wait | for the day MS has no surprise for us a bit longer... :) Same line of code for me :-( And how can the compiler actually crash like this? | But the GCC 2.95.x ICEd on the F()() so the workaround for the MSVC may | be trivial and acceptable, too. And why do other very similar codes from Michael Kenniston and Terje work? Suggestions? | I know and in this toy code I don't really care :)) No problem. | > I hope this will produce a bit more sympathy for my attempts to provide | > a variety of solutions for a variety of compilers. If the result is such | > a big performance hit on widely used compilers, it is just too early for | > such an advanced solution. | | Hm, I'm not sure I agree. Whatever will be standardizes shouldn't prevent | good code, but it's not responsible for bad compilers. But there should - | as I already said - be only one interface. Don't disagree with that but I see a 'chicken and egg' problem : until there is a Boost library file, nobody will use it, and there will be no pressure on compiler people to get a 'final solution' to work, and to work well. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Math constants - efficiency
These are interesting results, but my enthusiasm is severely reduced by the fact that MSVC 7.1 (Standard) chokes terminally on both versions :-(( Compiling... Frey_bench_mark_gcc.cpp Frey_bench_mark_gcc.cpp(82) : warning C4305: 'return' : truncation from 'double' to 'float' Frey_bench_mark_gcc.cpp(108) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information I am not saying that your code is wrong, but this is clearly too 'advanced' a solution to be considered immediately even for Boost. (I note the warnings C4305: 'return' : truncation from 'double' to 'float', but these can be removed by making the value explicitly 3.14F and L - which I believe is 'strictly' necessary. Otherwise the compiler might conclude it should do a truncation, which would clearly defeat what we are trying to do. However this is a trivial nit). Looking at your results, and the timing, and going back to the Kenniston code produced by the previous tests - which Ed Bray can no doubt update for us from his recent MSVC 7.1 test, I suspect that the differences are probably due to failure to load the constant directly into a floating point register, rather than pushing the constant onto the stack, taking two instructions, and using a reference to it, needing yet more instructions, and failure to optimise away (inlining) the template function call. (At bottom is the lousy instruction set and shortage of registers of course - but the processors go like stink! When you look at this sort of code, you see why FORTRAN is still popular. gcc should probably look into how seriously the benchmark is lying?) I hope this will produce a bit more sympathy for my attempts to provide a variety of solutions for a variety of compilers. If the result is such a big performance hit on widely used compilers, it is just too early for such an advanced solution. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Sunday, June 22, 2003 12:57 PM | To: [EMAIL PROTECTED] | Subject: [boost] Math constants | | | I had a small time-out and will now try to catch up with the | discussion. Before commenting on other postings, I'll show the result | of a small benchmark. The code is attached, maybe you want to verify | and post the results for your compiler(s), too :) | | MACRO: | | Intel C++ 7.1: 0.37 | GCC 2.95.3: 2.12 | GCC 3.3: 2.15 | | VARIABLE: | | Intel C++ 7.1: 0.37 | GCC 2.95.3: 0.62 | GCC 3.3: 0.61 | | FUNCTION: | | Intel C++ 7.1: 0.37 | GCC 2.95.3: 0.62 | GCC 3.3: 0.61 | | TEMPLATE: | | Intel C++ 7.1: 0.37 | GCC 2.95.3: 1.36 | GCC 3.3: 1.35 | | As you can see, good compilers like the Intel are not suffering from | any presentation scheme, the GCC (althought not a bad compiler) has | some problems. Even the best versions are still much slower than the | Intel's compiler code. The template does have some performance | penalties, but remember it is just a benchmark. In real code, I expect | the difference to be smaller, but this will depend on the use | scenario. The most direct approach (MACRO) is even worse than the | template-approach. Conclusion: The code I suggest (TEMPLATE) is not | bad in itself, nothing prevents a compiler from generating a good | result from it. This doesn't mean that all compilers do so. | | Before commenting on the benchmarks, please also look at the code | attached and note that I am well aware of the fact that all benchmarks | are lying :o) | | As a result, we might want to evaluate if users that really need | speed use fast compilers and if those compilers suffer from the | code. If someone uses the GCC and complains about speed, one might | suggest to change the compiler anyway. | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Math constants - efficiency
Thanks for these interesting results which I am digesting. Paul PS I look forward your comments on other posts in due course. | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 22 June 2003 12:57 | To: [EMAIL PROTECTED] | Subject: [boost] Math constants ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Math Constants Formal Review
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Terje Slettebø | Sent: 22 June 2003 02:33 | To: Boost mailing list | Subject: Re: [boost] Math Constants Formal Review | | I've finally managed to catch up with mailing list postings, | and have now read through the review postings of this library. | | First, I'd like to thank Paul for the work he's done with | the library, having gone through no less two formal reviews Thanks - it seems that in computing the simple is always difficult, and vice versa. | I've read through the docs, and also tested the library. And thanks for the very detailed thought you have given this. I am away from my machine for another day but hope to try out your helpful suggestions and explore the implications - always more difficult than one hopes. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math constants - nearest values
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of | Guillaume Melquiond | Sent: 21 June 2003 23:51 | To: Boost mailing list | Subject: Re: [boost] Re: Advanced match constants scheme | Consequently, more than one constant out of 1 may suffer | from this problem. So it is rare, but it is not impossible. | It's why I was suggesting that a library should provide a | mean to know if a number representing a constant is the | nearest or not. One constant out of 1 seems a rather small risk. Can't we just check that all the constants we offer are in fact the nearest? Since very few contain many zeros, I think I am prepared to wager a few beers on this one! So does this mean that the presentation function will use the 'exactly representable' decimal digits appropriate for the floating point format (choice of 5) and for the FP type float, double, long double to give to the compiler to use? Paul PS How do we check? Does it depend on the FP format? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Advanced match constants scheme - interval lower andupper values
It may helpful to those unfamiliar to the Boost Interval library to see some exactly representable values of pi (from test_pi_interval.cpp) // Float 24 bit significand, 32 bit float // static const float pi_f_l = 13176794.0f/(1 << 22); // static const float pi_f_u = 13176795.0f/ (1 << 22); // Exactly representable values calculated using NTL. static const float pi_f_l = 3.141592502593994140625F; static const float pi_f_u = 3.1415927410125732421875F; cout << "pi_f_l = " << pi_f_l << endl; // pi_f_l = 3.1415925 cout << "pi_f_u = " << pi_f_u << endl; // pi_f_u = 3.14159274 // double 53-bit significand, 64 bit double // cout.precision(17); // significant digits10 // static const double pi_d_u = 3537118876014221.0f/(1 << 51); // compiler chokes :-( - divide by zero! so need a cunning trick: | static const double pi_d_l = (3373259426.0 + 273688.0 / (1<<21)) / (1<<30); // Or the NTL calculated exact representation: static const double pi_d_l = 3.141592653589793115997963468544185161590576171875; static const double pi_d_u = 3.141592653589793560087173318606801331043243408203125; cout << "pi_d_l = " << pi_d_l << endl; // pi_d_l = 3.1415926535897931 cout << "pi_d_u = " << pi_d_u << endl; // pi_d_u = 3.141592653589794 // Long double 64 bit significand values, 80 bit /// cout.precision(21); // significant digits10 //static const long double pi_l_l = 7244019458077122842.0f/(1 << 62) //static const long double pi_l_u = 7244019458077122843.0f/(1 << 62); // Compiler will choke! or an even more cunning trick will be needed. static const long double pi_l_l = 3.14159265358979323829596852490908531763125210004425048828125L; static const long double pi_l_u = 3.141592653589793238729649393903287091234233203524017333984375L; cout << "pi_l_l = " << pi_l_l << endl; // 3.1415926535897931 cout << "pi_l_u = " << pi_l_u << endl; // 3.1415926535897931 and there are also 128 bit too, but I won't bore you further :-) | [*] It is not even true. Due to "double rounding" troubles, | using a higher precision can lead to a value that is not the | nearest number. Is this true even when you have a few more digits than necessary? Kahan's article suggested to me that adding two guard decimal digits avoids this problem. This why 40 was chosen. Consistency is also of practical importance - in practice, don't all compilers read decimal digit strings the same way and will end up with the same internal representation (for the same floating point format), and thus calculations will be as portable as is possible? This is what causes most trouble in practice - one gets a slightly different result and wastes much time puzzling why. | So maybe the interface should provide four | values for each constant at a given | precision: an approximation, the nearest value, a lower | bound, and an upper bound. Possible, but yet more complexity? Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of | Guillaume Melquiond | Sent: 20 June 2003 13:28 | To: Boost mailing list | Subject: Re: [boost] Advanced match constants scheme | | | On Thu, 19 Jun 2003, Augustus Saunders wrote: | | > >PS I'd like to hear more views on this - | > >previous review comments were quite different, | > >being very cautious about an 'advanced' scheme like this. | | I didn't react to this review at first because I was a bit | disappointed by the content of the library. It was more like | some questions about the best way to represent constants in | a C++ library. And since I already had given my thoughts | about that, I didn't feel the need to speak about it again. | | > Disclaimer: I am neither a mathemetician nor a scientist | (I don't even | > play one one TV). I do find the prospect of writing natural, | > effecient, and precise code for solving various equations | a worthwhile | > goal. So, since you asked for comments, here's my non-expert | > thoughts. | > | > As I understand it, the original proposal's goal was to provide | > conveniently accessible mathematical constants with | precision greater | > than current hardware floating point units without any unwanted | > overhead and no conversion surprises. Additionally, it | needed to work | > with the interval library easily. To work around some compilers' | > failure to remove unused constants or poor optimization, | we wound up | > discussing function call and macro interfaces. Nobody, | however, is | > thrilled with polluting the global namespace, so unless Paul | > Mensonides convinces the world that macro namespaces are a | good thing, | > some of us need convincing that macros are really the way to go. | | I am not really interes
RE: [boost] Advanced match constants scheme
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Augustus Saunders | Sent: 20 June 2003 01:32 | To: [EMAIL PROTECTED] | Subject: [boost] Advanced match constants scheme | >PS I'd like to hear more views on this - | I do find the prospect of writing natural, effecient, | and precise code for solving various equations a worthwhile goal. | So, since you asked for comments, here's my non-expert thoughts. Your participation is most welcome - I had started to fear that nobody was interested. | Nobody, however, is thrilled with polluting the global namespace, | so unless Paul Mensonides convinces the world that macro | namespaces are a good thing, some of us need convincing that | macros are really the way to go. I only suggested that they should be an option, and not preferred. (The marginal cost of generating macro values is almost zero). | In the course of discussion, a more ambitions plan was proposed. | Instead of just providing a big list of constants, IIUC it | was suggested that an expression template library be used to | allow common constant combinations like 2*pi or pi/2 to be | expressed with normal operators. This seems good, it | provides a natural syntax and reduces namespace clutter and | is easier to remember. However, since the idea was to use a | special math program to generate high precision constants, | I'm not sure whether an ETL can eliminate the need to | compute things like 2*pi with the third party program. So | I'd like to know does: | 1) 2*pi ==> BOOST_2_PI Well, in this case yes for all binary floating point machines, because you just add one to the exponent (assuming it doesn't overflow). For the upper and lower values of the interval containing pi, the I believe that answer is a definite no because the interval value must be 'exactly representable' and thus depends on the floating point layout (number of significand bits). So there isn't a single pair of macro upper and lower values. For this the interval library authors preferred the template approach. template_intervals_constants.hpp (and test..) provides an example of how this could be implemented with the Kenniston template-function scheme. These exactly representable values can only be calculated with a 400-bit floating point system - I have used NTL, but there are a few others. This doesn work at the speed of light, so I believe pre-calculating is essential. But a better question would be about pi and 3 (or 5 or 10...) when I believe that the answer to 3*pi ==> BOOST_3_PI ? is a definite maybe. And of course if exp and log, sin, cos etc the answer is almost certainly not. There are quite a lot of these. | where BOOST_2_PI is a constant already defined, or does | 2) 2*pi ==> BOOST_PP_MULT( 2, BOOST_PI ) | using high precision preprocessor math (or something) to | sidestep the need for defining BOOST_2_PI in the first place? This would be fine - but a high precision preprocessor doesn't exist yet, to my knowledge and would be seriously slow. | If this was implemented the first way, then I would see any | "advanced" scheme as being a layer on top of the actual | constant library, to give it a more convenient interface. | The second way might actually impact what constants get | defined in the first place, in which case we should talk it | out enough to know what constants should be defined. But | I'm not sure the possibility of an advanced scheme should | prevent us from defining the basic constants--an expression | framework could be another library, right? | | Augustus Right. And Daniel's scheme already looks to permit this (but not for intervals - or complex? another 'requirement'). So for these two reasons, I am resigned to a larger set of constants than might seem necessary at first sight. If you look at the constants actually used, there really are not that many (few dozen?). We previously discussed a reasonable rational naming scheme which would allow one to guess but resort to calculation if not found in the library list. Paul PS I'd still be grateful for more views on this issue. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Math Constants Formal Review - usingnamespacestoselectfloat size is simpler?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Ken Hagan | Sent: 20 June 2003 11:27 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Re: Math Constants Formal Review - | using namespacestoselectfloat size is simpler? | | Paul A Bristow wrote: | > This scheme may offer more surprises to the many naive | users (like me) | > than an explicit (and convenient 'global') choice, for example: | > | > using boost::math::double_constants; | > | > to ensure that the expected size is used. | > | > One can make the compiler warn you about size conversions, | whereas I | > have the impression that these rules will mean that you | won't get any | > warnings. | | AFAICT, you will either get exactly the type that the | context requires, or a diagnostic from the compiler saying | that it is ambiguous. (This assumes that a selection of | possible types are available for each | constant.) I don't think it is possible to get a quiet conversion. | | In contrast, "using boost::math::double_constants" does | allow you to get an implicit size conversion, where the | context requires one. Compilers will warn, but only if users | haven't disabled the warning. | | So, with the "clever" approach, all users will find | themselves writing a few explicit conversions to avoid | ambiguities. With the "simple" approach, only users who have | their warning level right up will need to write explicit | conversions, and then only to silence the compiler. | | Listening to compiler warnings is something the community | might want to encourage (so the simple approach would then | have no advantages), but it isn't the job of a language | standard to mandate "good" programming practices. (In the | absence of such constraints, the definition of "good" tends | to change with time.) I am grateful for this reassurance that conversions not expected, though I hope the compiler writers know the rules - as Michael Caine would have said "Not a lot of people know that" :-) Thanks too for your accurate summing up of pros and cons. My slight preference for the 'simple' approach perhaps came from always setting the compiler to warn about conversions and carefully 'casting them all away'. Alas Microsoft have not chosen this as their default and it is not obvious how to ensure that all files are compiled with the right warning option. (After getting some helpful hints, I previously posted guidance on how to modify common.js to achieve this). But I am persuaded that the 'casting' method is OK. Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - using namespacestoselectfloat size is simpler?
| Well, you wanted to know what is likely to be accepted. In a | formal review (this isn't anymore, AFAIU, is it?) I would | vote no to your approach. But would you vote yes if the only presentation was Daniel's method? I am only really concerned that the accurate constants become more standardised, in name and value. Paul PS I'd like to hear more views on this - previous review comments were quite different, being very cautious about an 'advanced' scheme like this. Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - using namespaces toselect float size is simpler?
I stand better informed than I really wanted to be, and only quacking quietly from getting my mind round the implications of these rather complex rules. (They remind me of PL/1 automatic conversions which were designed by IBM sales managers to sell computers but ended up being a maze of snares for the unwary.) This scheme may offer more surprises to the many naive users (like me) than an explicit (and convenient 'global') choice, for example: using boost::math::double_constants; to ensure that the expected size is used. One can make the compiler warn you about size conversions, whereas I have the impression that these rules will mean that you won't get any warnings. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota | Sent: 19 June 2003 11:10 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - does | static_cast merely select? | | | On Wed, 18 Jun 2003 22:27:27 +0100, "Paul A Bristow" | <[EMAIL PROTECTED]> wrote: | | >| -Original Message- | >| From: [EMAIL PROTECTED] | >| [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota | >| [...] | >| | >| In Daniel's solution static_cast(x) simply "selects" | >| the corresponding specialization of x_value. So | >| | >|static_cast(pi) | >| | >| is fundamentally different from, say, | >| | >|double pi = ...; | >|static_cast(pi) | > | >Perhaps naively, I find this surprising - but I am not a | language guru. | > | >Can you/anyone confirm that this is required by the Standard | > - and is in fact what happens when compilers process this? | | Yes :-) Note that all "conversions" from a constant | pass through | |template< typename U > operator U() const { return F< U >()(); } | | Now, F()() means (ignoring some technical differences irrelevant | here): | |F object; // construct an x_value object |return object(); // invoke operator() on it and return | | Now, if you use the binary operators, like in: | | pi * f; | | with f being a float then the selected specialization is | float; i.e. the constant "takes the type" of its adjacent | operand (left operand if it exists, right operand | otherwise). This is, of course, different from what normally | happens when you do | |double pi = ...; |pi * f; // floating point promotion on f | | and is IMHO a caveat. But, still, there are no truncations. | Only selection of the target specialization. If no target | specialization exists, e.g. | |static_cast(pi) | | you have a compile-time error. | | > | >If it walks like a duck and quacks like a duck ... | | This walks quite differently. And doesn't quack :-) | | | Genny. | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - accuracy is vital too
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Reece Dunn | Sent: 18 June 2003 20:23 | To: [EMAIL PROTECTED] | Subject: Re: [boost] Re: Math Constants Formal Review - | Also, using constructs like this is easier for the | programmer. You don't have to search to see if there is a pi/2 constant and find | out what it is called, you simply use: | boost::pi / boost::two or whatever. Previous opinions were in favour of a larger set of constants, and there was considerable discussion about a set of names which were finally agreed to be reasonably consistent. Are you forgetting the very important need that the constants mesh with the Boost interval library? For these I think you need pi_div_3, for example, to provide the upper and lower interval values. (These in turn depend on the floating-point format). What about the complex case, for which an example is provided by Michael Kennistons scheme? Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - does static_castmerely select?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota | Sent: 18 June 2003 15:45 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - accuracy | is vital too | | > the proposed code uses namespaces | >to allow selection of the FP size either individually: | | In Daniel's solution static_cast(x) simply "selects" | the corresponding specialization of x_value. So | |static_cast(pi) | | is fundamentally different from, say, | |double pi = ...; |static_cast(pi) Perhaps naively, I find this surprising - but I am not a language guru. Can you/anyone confirm that this is required by the Standard - and is in fact what happens when compilers process this? If it walks like a duck and quacks like a duck ... Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - optimal code?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 18 June 2003 11:15 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review | >>Paul A Bristow wrote: | >>>I am confident that your system also generates efficient | code using | >>>an efficient compiler. But have you considered or tried debugging? | > What should be verified? Previous work using this templating technique produced some code in debug mode which was rather confusing to debug. Every time a constant like pi was used, you had to step through procedure call code. This was a minor but most irritating and distracting feature compared to code from plain const double pi. | How efficient different compilers work with the template-approach I | showed. I'll try to do that for the GCC 2.95 / 3.x and for the Intel | compiler (v7) at the weekend, but my experience with reading | x86-assembler is limited, so maybe I'll just run some | benchmarks. As I don't have/use Windows, I can't verify compilers for this platform. Ed Brey has recently verified that with MSVC 7.1 the Kenniston code looks optimal, and that no code is generated for unused constants. (You can see the previous MSVC 6.SP5 assembly output as comments at the end of testFunctionConstants.cpp 6.SP5 did create unwanted code in 'strict' mode). I strongly recommend looking at the code as well - you might find benchmarks by themselves misleading. You should see a Fstp or fld qword ops - I think. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - accuracy is vital too
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 17 June 2003 11:19 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review I have now studied your code - only on paper - rather more carefully, which I apologise for not doing carefully enough before. It seems to have some similarities to the code written by Michael Kenniston which is now being reviewed. I am not sure that I fully understand how and why it works, and I do not yet see what advantages it may have. I would much welcome more independent expert input, but I do note: The float and long double constant values do not include F and L. Previous agreement was that this was needed to to avoid any chance of computation by the compiler. This could of course be easily added. A vital feature is that the compiler should only use the 40 decimal digit literal values provided and should NOT do any calculation. This is because the compiler will only use the floating-point accuracy of the hardware whereas the important feature of the values provided is that they are calculated by a much higher precision software system, in this case NTL. It is difficult to foresee compiler writers opting to use higher accuracy floating-point because it would be much slower, and only rarely add any value. Maximum possible accuracy is a central feature, promising the best possible portability, especially for intervals where every really bit really counts. It was also agree that any casting to obtain other types did not garanteed accuracy and this was why the proposed code uses namespaces to allow selection of the FP size either individually: boost::math::double_constants::pi or boost::math::float_constants::pi or 'globally' - suiting most applications using namespace boost::math::double_constants; and then accessing using just plain pi. I feel that static_casting definitely needs to be avoided. Perhaps your code can achieve this by some modification? Although your operators are neat, speeding -sin(pi/two), my suspicion is that it is better to pre-calculate as many constants as possible, and as accurately as possible. I don't think this counts as "premature optimisation" :-) Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - ()s are a key issue.
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 17 June 2003 11:19 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - ()s are | > 1 Control of precision is essential, | > and some users wanted to be able to use | > float, double and long double at the same time. | "at the same time" is exactly what the "separate headers approach" | doesn't provide if you can only include one at a time IIUC. Absolutely, but on the previous review, many users wanted to "Keep It Simple Sir" and deliberately only have (for example) double const pi - avoiding the complexity of other schemes, get warnings of conversions, difficulty during debugging, and inefficient code from older compilers. They would chose just the plain double const files. You would just ignore them - at no cost to you! | > 2 Avoiding paying for what you don't use, which leads to | Hm, there is some small overhead, but not much IMHO. In fact | far less than a lot of other boost libraries. :) Agreed, though don't forget there are dozens of constants, not just pi. | > 2a MACROS provide a simple way of avoiding some cost for | > constants you don't use, (Although some Boosters were opposed | > to MACROs because they pollute the global namespace). | | I'd like to backup the latter. | With MACROs, you cannot add a 'using | namespace boost::math;' and use a plain 'pi' instead of 'BOOST_PI'. | Using MACROs is a pain and should be avoided if possible. Agreed but ... Some users wanted to "Keep It Really Simple Sirs" and for them the MACROS files are available. For systems where every byte counts, they may be best. (For me, while generating the other files, the extra cost of generating the MACROS file is negligible). If you hate MACROs them don't use these files - at no cost to you! | But this is exactly what my code tries to do. You write | 'pi', and when | using it, all calcalations are forwarded to use the value | returned from | a function (actually pi_value::operator()). Some magic is | provided | for convenience like in the example above and you can select | the type | explicitly be using a static_cast. AFAICS you get all what you are | asking for... I will try to compare your proposal more carefully with Michael Kenniston's version - which seems to work efficiently and conveniently and extensibly with small enough risk of surprises about precision for novice users. As Ed Brey reported during this review, Kenniston's method files DO generate efficent code with Optimising MSVC 7.1 and gcc, not creating any code for unused constants - an important requirement. So the only cost is in compile time - which should be tolerable. However I am away from my machine at present so it may be a day or two. If you have more examples of use similar to those in the folder "testFunctionConstants", containing a test.cpp with lots of comments and header functionconstants.hpp these will be helpful. the Folder pi also gives his examples of extending to handle complex. quadfloat folder gives an example of a UDT (a 128bit floating point software type). I am confident that your system also generates efficient code using an efficient compiler. But have you considered or tried debugging? Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Re: Math Constants Formal Review - ()s are a keyissue.
In previous discussions, the main issues debated were: 1 Control of precision is essential, and some users wanted to be able to use float, double and long double at the same time. 2 Avoiding paying for what you don't use, which leads to 2a MACROS provide a simple way of avoiding some cost for constants you don't use, (Although some Boosters were opposed to MACROs because they pollute the global namespace). So, even if other presentations are provided, I strongly believe macros should be published. If you don't like them, don't use them! 2b Splitting the constants into several groups of files: essential, common, esoteric... 3 Efficiency Some compilers can generate better code from functions like "double pi() { return 3.1459;}" but that this implies writing "pi()" instead of plain "pi". 4 Appearance BUT Users extremely strongly prefer to write "float area = pi * r * r;" So the ()s remain a MAJOR issue. Michael Kenniston produced a 'presentation' which allows 'novice' users to write "pi" but get the effect of "pi()" without too many precision surprises. Yet it still allows the 'expert' to write "pi()" and control precision explicitly. I see nothing wrong with your suggestions and examples, but I don't yet understand how your proposal helps to meet this last 'requirement'. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 14 June 2003 20:48 | To: [EMAIL PROTECTED] | Subject: [boost] RE: Re: Math Constants Formal Review - is | extensible. | | | On Wed, 11 Jun 2003 15:49:05 +0200, Paul A. Bristow wrote: | | > The proposal is for several header files each containing the same | > constants, only one of which would be used for any | compilation. (Users | > have been warned against using more than one! Nobody has | suggested a | > way to guard against this mistake, but I think that it would be | > apparent pretty soon, probably at compile time, and at | link time if | > not.) The macros constants header is the simplest and | could be used | > to provide the appropiate value(s) above. | | The difference IMHO is, that this is not a generic approach. | It's a bit like replacing templates with macros. I haven't | seen any convincing arguments against the code I showed, | which *is* generic IMHO, but as I don't have the background | of the "long saga" you mentioned, I think I'm not the right | one to say what's the best way to go. | | Regards, Daniel | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Re: Math Constants Formal Review - is extensible.
I understand that this is not normal, but in this case there is a lot of work to do to create the files and I am reluctant to do this if the result is not ultimately going to be accepted. So I'd prefer agreement in principle first to the way of presenting the constants, and to the actual constants, their names and their values in the C macro files. There has already been much dicussion of all these items, but until the MSVC 7.1 compiler was out, the Kenniston presentation format was only sensible on other compilers. Now this has proved to be workable and efficient, it seemed timely to re-review the issue. Paul | I'm a bit surprised, that we currently are reviewing some | ideas instead of a library as far as I understood. | | Regards, | Joerg Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK +44 1539 561830 [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Review Request: cyclic_buffer
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Nigel Stewart | Sent: Wednesday, June 11, 2003 2:03 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Review Request: cyclic_buffer | | The "generally accepted" concept of a circular buffer | is a fixed size contiguous memory buffer. Following | the principle of "least surprise" a circular_buffer | should not decide to resize itself. On the "Keep It Simple Sir" principle, I agree with this. Indeed, I think that most uses specifically require a fixed at construction size, and I suspect the code will be smaller, faster and correcter if this is the specification. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - is extensible.
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Wednesday, June 11, 2003 8:41 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - is extensible. | | I think that most people are able to look up pi (and any other constant) | on the internet if they need more precision. Of course, but I believe there is great merit in avoiding this by having a collection of the widely used constants all of which have the same precision and are used by everywhere (unless there is some exceedingly special reason for higher precision - can you suggest who needs more than 40 decimal digits - apart from number theoretic work. Should be enough even for accountants!). | But as shown in the example | for the Roguewave-type, it's possible to allow the user to extend the | system. If the pi_value-stuff is placed in a header called | constant_values.hpp and the definition of the variable pi itself is in | another header, the user could add a specialization for 1000 digits if | he likes. See the example I gave for 'g'. The main point in doing this | is, that you only need to change the header of your project to add a new | type, not the code where pi is used. Here in the company, we use doubles | to develop the code, the RWDecimal<>-class for the production system and | we might replace the latter by another type as we don't want to use | Roguewave in the future. Of course it might be a nice idea to provide a | string representation of a constant, probably as a specialization: | | template<> struct pi_value< std::string > { |std::string operator()() const { | return "3.1415926535897932384626422832794"; |} | }; | | Now we could even provide the default case for classes that have a ctor | taking a string like this: | | template< typename T > struct pi_value { |T operator()() const { | return T( pi_value< std::string >()() ); |} | }; | | And the user is still able to specify his own version like shown: | | template<> struct pi_value< RWDecimal< RWMP3Int > > { |const RWDecimal< RWMP3Int >& operator()() const { | static const RWDecimal< RWMP3Int > value( "...1000digits..." ); | return value; |} | }; I don't believe that anything I propose conflicts with these sensible ideas. The proposal is for several header files each containing the same constants, only one of which would be used for any compilation. (Users have been warned against using more than one! Nobody has suggested a way to guard against this mistake, but I think that it would be apparent pretty soon, probably at compile time, and at link time if not.) The macros constants header is the simplest and could be used to provide the appropiate value(s) above. | | Now I'm getting closer to it. And if it is in a separate header, it | would not mix up the above design, would it? No, you would only use the intervals constants header if you were using the interval library. (And if you were not, it would not compile). Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | | Regards, Daniel | | -- | Daniel Frey | | aixigo AG - financial training, research and technology | Schloß-Rahe-Straße 15, 52072 Aachen, Germany | fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 | eMail: [EMAIL PROTECTED], web: http://www.aixigo.de | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review - is extensible.
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Tuesday, June 10, 2003 10:18 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - is extensible. | | | Paul A. Bristow wrote: | > Your example is interesting. I think that providing a Macro value | allows this | > sort of UDT extensions code (very like Michael Kenniston's examples). | | I fail to see how this should work. Could you elaborate a bit, please? | | > My thesis that 40 decimal digits are enough is because it is enough for all | > existing floating point hardware, up to 128 significands. I | believe that anyone | > wanting more is likely to be using a separate 'unlimited' precision package | > anyway. | | That exactly is my point: People will choose such a package, but how can | it be glued by the user to boost's constants? And to the code the user | already wrote? Taking into account that boost is intended to be some | kind of pre-standard-library, I think we should allow the extension of | constants to be used with new float-types. Using the constants in a | generic way is only possible when we have a standardized way of | accessing them. This is why I concentrated on allowing explicit casting | and the direct use as in pi*(float)(...). I don't see how the user could | use Roguewave's decimal type with Macros (or any other user defined | float-like type. And I don't think that using such a library should | result in a choice for the user to either use constants from boost with | the according interface or hope for the vendor to specify the constants | and use their interface. I imagine that any package will have some decimal digits C string to UDT conversion, for example for quad_float it is to_quad_float(const char*) so ones writes NTL::quad_float my_quad_float = to_quad_float(BOOST_PI); where BOOST_PI is defined as 3.1415926535897932384626433832794 say. I see the 40 decimal digit representations as the 'lowest common denominator'. How else do you propose? | | > There is also an example of a UDT _interval_ - a 128-bit quad_float | type, used | > by Victor Shoup's NTL package. But it does require using the NTL generator | > program to create the exactly representable values. (See | test_quad_float.cpp | > example). | > I believe that interval constants are an important feature - and | quite novel. | | I don't understand that example, sorry. Thus I also miss the importance | of this feature. What exactly are interval constants? What problem are | they addressing? If you are using the interval library to calculate the intervals of areas of a circle, you need the smallest interval containing pi (as well as interval containing the radius of course). |Isn't it an orthogonal concept to constants like 'pi', | 'e', ...? Should / could it be placed into a separate library (maybe on | top of the basic constants library)? I proposed a separate file containing the interval constants (or should I say constants intervals?) | I also looked at other examples | like test_pi_interval, but I still don't understand the idea that's | behind it. All that I see is a lot of pi_f_l, pi_l_l, pi_l_u4, etc. and | this is IMHO unacceptable for generic programming. The file template_intervals_constants.hpp contains some examples of how the interval library authors and others discussions concluded that the interval values would appear to users - analogous to other intervals. Users would not see pi_f_l, pi_l_l. These are to show that the exactly representable values work OK. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | | Regards, Daniel | | PS: The toy-example I posted only worked for the GCC 3.x, but I extended | it a bit to make it work with the Intel compiler and with older GCCs | (2.95.x). If there is any interest, I can post it... | | -- | Daniel Frey | | aixigo AG - financial training, research and technology | Schloß-Rahe-Straße 15, 52072 Aachen, Germany | fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 | eMail: [EMAIL PROTECTED], web: http://www.aixigo.de | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Tuesday, June 10, 2003 4:51 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review | | | > [3] Physics-based constants should be definable within the constants | > framework and should be set to their current accuracy (possibly making | > use of intervals). | | Maybe we could provide some defaults that can be overwritten by the | user? Something like: | | --- header physics_constant_values.hpp | | template< typename T > struct g_default_value; | template<> struct g_default_value< double > | { double operator()() const { return 9.81; }; | | template< typename T > g_value : g_default_value< T > {}; | | --- header physics_constants.hpp | | #include | struct g_t : constant< g_t, g_value > {} g; | | --- user adds to his project-header physics_constants.h: | | #include | template<> struct g_value< double > | { double operator()() const { 9.81424242424; } }; // Ha, I know better! | #include No objections to this but I really would like to follow the conclusion of the previous review that we should concentrate on math constants FIRST - getting agreement on them seems to be plenty difficult enough! Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: RE: Math Constants Formal Review - optimisationof unused constants.
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Ed Brey | Sent: Tuesday, June 10, 2003 2:30 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Re: RE: Math Constants Formal Review - recap & | summary | | | Paul A. Bristow wrote: | >> | >> For example, VC 7.1 discards d1 if it is not referenced, so there is | >> no issue with paying for what you don't use when using that method on | >> that compiler. | > | > This is good news. What optimisation did you chose? | | /O2 | | >> It would be useful to know what compilers do retain | >> unused constants. | > | > But is tiresome to find out, and will keep changing. (and if the | > scheme becomes widely used, compiler writers will have a strong | > incentive to make sure it is optimized away. | | Agreed, an active search would be a lot of effort. I passive | approach may be practical however. My thinking is to start from a | position that all compilers optimize well. Then when someone says, | "Sorry, that interface triggers this pessimization on compiler x," | just make a note of x and its limitation. This way to don't need to | look for compiler limitations; news of such will come to you. | | There probably aren't a ton of limitations; so the list may well be | short, and it can be a big timer saver to know exactly which | compilers to care about when they get reved, especially if a removal | of a key limitation eliminates the need for a complex workaround. Sounds sensible. (I fear the answer to pessimization may be "tough!") Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: RE: Math Constants Formal Review - is extensible.
Sorry I have misunderstood your wish - for existing constants in different types rather than new constants in existing types. Your example is interesting. I think that providing a Macro value allows this sort of UDT extensions code (very like Michael Kenniston's examples). My thesis that 40 decimal digits are enough is because it is enough for all existing floating point hardware, up to 128 significands. I believe that anyone wanting more is likely to be using a separate 'unlimited' precision package anyway. There is also an example of a UDT _interval_ - a 128-bit quad_float type, used by Victor Shoup's NTL package. But it does require using the NTL generator program to create the exactly representable values. (See test_quad_float.cpp example). I believe that interval constants are an important feature - and quite novel. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Sunday, June 08, 2003 9:54 PM | To: [EMAIL PROTECTED] | Subject: [boost] RE: RE: Math Constants Formal Review - is extensible. | | | On Sun, 08 Jun 2003 16:56:53 +0200, Paul A Bristow wrote: | | > You can seen an example of extending to a 'new' constant 'gamma' in the | > examples testFunctionConstants/gamma_function_constants.hpp. | | Either I don't understand the example or we are talking past each other. I | don't meant to extend the framework with new constants, but with | definitions of existing constants for new types. Maybe the attached | example of a small experiment of mine clarifies what I was thinking about. | Look at the "Roguewave"-extension for pi. If I imagine to use | "boost/math_constants.hpp" in the company I work, it would be encapsulated | into another header "base/math_constants.h" and it would provide all | constants for Roguewawve's decimal type, too. I already used the | lambda-library and tought it about the decimal type, which worked very | smooth and I was really happy to see that the library designers didn't | limited it to build-in types. A key-feature for me! | | > defining the constant as a 40 decimal digit string. | | Roguewave's types can be used with precisions up to 1024 bits - probably | more. I don't think that a one-size-fits-all approach can work in the area | of numeric computations. | | > If Boosters agree that this scheme is an acceptable way to go, the the | > example and guidance could be made more helpful to provide the | > encouragement you rightly say is needed. | > | > But first the overall strategy needs agreement. | | Indeed. So if I still missed that the constants can be provided by the | user for their types, please let me know. Otherwise, we should find a | consensus whether such a feature is needed. I personally think it is, but | if the majority thinks it's not that important... :) | | Note that the attached file is not meant to offend you in any way. It way | just a toy example and maybe you can take some ideas out of it. It's not | meant to replace your code as I think you have put a lot of ideas in it | and provide features I don't even know of :) | | Regards, Daniel | | --- | | #include | using namespace std; | | namespace math | { | // Generic base class for all constants | template< typename T, template< class > class F > struct constant | { | // A cast-to-anything-operator :) | template< typename U > operator U() const { return F< U >()(); } | | #define ADD_OPERATOR( OP ) \ | template< typename U > friend U operator OP( const T& lhs, | const U& rhs ) \ | { U nrv( static_cast< U >( lhs ) ); nrv OP##= rhs; return nrv; } \ | template< typename U > friend U operator OP( const U& lhs, | const T& rhs ) \ | { U nrv( lhs ); nrv OP##= static_cast< U >( rhs ); return nrv; } | | ADD_OPERATOR( + ); | ADD_OPERATOR( - ); | ADD_OPERATOR( * ); | ADD_OPERATOR( / ); | #undef ADD_OPERATOR | }; | | // Here's the definition for pi for all types (can be extended by UDTs): | template< typename T > struct pi_value; | template<> struct pi_value< float > { float operator()() const { | return 3.14; } }; | template<> struct pi_value< double > { double operator()() const | { return 3.1416; } }; | template<> struct pi_value< long double > { long double | operator()() const { return 3.1415927; } }; | | /* | // For expensive constructions, maybe this is an option: | template<> struct pi_value< RWDecimal< RWMP3Int > > { | const RWDecimal< RWMP3Int >& operator()
RE: [boost] Re: RE: Math Constants Formal Review - recap & summary
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Ed Brey | Sent: Monday, June 09, 2003 2:57 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: RE: Math Constants Formal Review - recap & summary | | | Paul A Bristow wrote: | > A Mini-recapitulation of the _long_ saga so far: | > | > 7 There are dozens of constants that some users rate 'essential'. | > Splitting into several #include files still risks violating the | > "don't pay for what you don't use" principle. | | > 10 There is evidence that some compilers can generate better code | > from functions like "double pi() { return 3.1459;}" | > but that this implies writing pi() instead of plain "long double pi". | > So the ()s remain a major issue. | | These two points are based on observations that compilers don't | optimally handle constants defined like this: | | double const d1 = 1.2; | | It would be useful to record exactly which compilers have which | troubles, so that as compilers improve, constraints can be dropped. | | For example, VC 7.1 discards d1 if it is not referenced, so there is | no issue with paying for what you don't use when using that method on | that compiler. This is good news. What optimisation did you chose? | It would be useful to know what compilers do retain | unused constants. But is tiresome to find out, and will keep changing. (and if the scheme becomes widely used, compiler writers will have a strong incentive to make sure it is optimised away. | The FAQ entry "Why are functions like double pi() which return | constants provided?" has a start to the idea of documenting specific | compiler limitations. I'd recommend adding this elaboration on VC 7 | (others can help with other compilers): | | - Static constants are referenced via a pointer, which leads to | smaller code if the constant is used more than once, but often to slower code. | | (I would take out the blurb about MSVC 7 Standard edition. Does | anyone who needs to professional-grade execution speed really buy the | standard, rather than professional edition? The professional edition | inlines properly according to the standard-specified "inline" keyword hint.) Agreed. I think this problem looks likely to go away, as I hoped - which is why I waited until 7.1 before this review. Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Math Constants Formal Review - recap & summary
A Mini-recapitulation of the _long_ saga so far: Briefly I propose many different representations for constants, because after much discussion and experimentation, no universally-acceptable format and no disadvantage-free format has been found. 1 We agree on the need for accurate mathematical constants - pi, e, sqrt(2) for a start, but many others are 'essential' to some people. 2 Physical constants are a separate matter for their accuracy is not constant. 3 Some constants cannot be calculated accurately by current compilers because they use 'built-in' hardware floating-point, and this is unlikely to change. Only constants calculated with a higher precision software system, like NTL, will ensure that the constant is stored as accurately as the floating-point hardware will allow. 4 40 decimal digits are sufficient for all practical purposes (except intervals see below), and compilers are (or really should be) capable of reading decimal digits into their various internal formats (float, double, long double). 5 A C++ naming scheme for math constants has been devised which is at least acceptable (if inevitably a compromise). 6 Control of precision is essential, but there is opposition to a C-style solution using three names for each constant, for example: float pi_F, double pi_D, long double pi_L. Nor, in Boost discussions, did use of namespaces to separate different precisions seem acceptable. 7 There are dozens of constants that some users rate 'essential'. Splitting into several #include files still risks violating the "don't pay for what you don't use" principle. 8 Only MACROS provide a simple way of avoiding some cost for constants you don't use. (but Boosters expressed strong opposition to MACROs because they pollute the global namespace, even if #undefs are provided). 9 Users extremely strongly prefer to write "float area = pi * r * r;" 10 There is evidence that some compilers can generate better code from functions like "double pi() { return 3.1459;}" but that this implies writing pi() instead of plain "long double pi". So the ()s remain a major issue. Michael Kenniston had a previous interesting suggestion but which did not seem entirely satisfactory. He has now produced another which is attached. Briefly, this allows 'novice' users to write "pi" but get the effect of "pi()" without too many precision surprises. Yet it still allows the 'expert' to write "pi()" and control precision explicitly. But there remain some disadvantages - see FAQ. 11 Finally the acceptance of the Interval Library into Boost means there is a real need for intervals containing constants - upper and lower limits. Examples have been calculated as 'exact representations' and discussed before. This increases the number of constants potentially required to achieve the required accuracy (for example, 2_pi interval IS needed). | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 07 June 2003 00:20 | To: [EMAIL PROTECTED] | Subject: [boost] RE: Math Constants Formal Review | | | I currently vote neither yes nor no. I just need to get a | better understanding of what is intended to be included into | boost from the files provided. | | On Fri, 06 Jun 2003 19:21:08 +0200, Paul A Bristow wrote: | | > but I hope the review can concentrate on what emerged | previously as | > the _really_ tricky issue of how to _present_ the values in C++, | | I looked at the files and I think that they need some clean | ups. Also, I don't really see the concept behind it. How are | the values presented and how does your way compare to other | options? (Well, I basically can fiure out the first part, | but without the second, I can't really understand it). Maybe | you can provide some links to the key messages of the | discussion that lead to it or give us a short summary. | | Another point I am missing is a way to extend the constants | for user-defined types. Something like numeric_limits<> | comes to mind. I think that this is a must-have feature as | people that write applications that need lots of these | constants are likely also using types with higher precision | that the standard types provided by the language. Without a | way to teach the constants-framework the new types, they | will create wrappers and thus they won't use the intended | boost-/standard-way to access the variables. | | Regards, Daniel | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
If someone would like to do this, I'd be grateful. (Memories of how to use commandlines and CVS have decayed). Paul Paul A Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daryle Walker | Sent: 06 June 2003 23:47 | To: Boost | Subject: [boost] Re: Math Constants Formal Review | | | On Friday, June 6, 2003, at 6:45 AM, Jaap Suter wrote: | | > Today is the start of the formal review of the Math | Constants library | > by Paul Bristow. The review will run until Sunday June | 15th. I will | > be serving as review manager. | > | [SNIP] | > You can find the latest documentation, including a bigger | FAQ section, | > at: | > | > http://groups.yahoo.com/group/boost/files/MathConstants/ | > Math_Constants_doc_3.zip | > | > Some examples are available at: | > | > http://groups.yahoo.com/group/boost/files/MathConstants/ | > Math_Constants3.zip | [TRUNCATE] | | In the previous review, copies of the code and documentation of the | Command & Config Option library were copied to the web space | SourceForge reserved for the Boost-Sandbox. Maybe we could | do the same | for this review (and all later ones). | | Daryle | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
| Genny wrote | Paul> What I would like to get is agreement on the presentation | of constants. | | You mean macros vs. constant variables vs. inline functions? | This is another thing I didn't understand by looking at the | documentation: the FAQ section seems sometimes to imply you | have already done a choice in this regard; In the previous review, Boosters suggested strongly different views on different ways of presenting constants. As I have tried to explain, there are pros and cons and valid reasons for wanting all of these. for instance: | | Q. Why not use floating-point hardware constants? | A. Because only a few are available, they are often not the right | size, are not available on all processors, and most important | are sometimes not accurate enough. | | but then, in another point: | | Q. Why are functions like double pi() which return constants | provided? | A. It provides a framework whereby users can plug in special | implementation and hardware-specific versions. Indeed - so the _user_ needs to be able to make the choice, and this implies that a single representation of constants won't do. | "Because some compilers may be able to produce smaller | and/or faster code.(For example, note that MSVC 7 Standard | edition only inlines "__inline", so this will produce slower | and longer code)." | | Maybe you meant: "because some compilers generate better | code with a manifest constant and others better code with a | function"? You could also say that - I'm open to suggestions. Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Math Constants Formal Review - is extensible.
You can seen an example of extending to a 'new' constant 'gamma' in the examples testFunctionConstants/gamma_function_constants.hpp. The example by Michael Kenniston also show how complex items could also be added (but not normally to avoid every program dragging in ). Macros could also facilitate the process of course, and it could start with a macro defining the constant as a 40 decimal digit string. If Boosters agree that this scheme is an acceptable way to go, the the example and guidance could be made more helpful to provide the encouragement you rightly say is needed. But first the overall strategy needs agreement. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 07 June 2003 00:20 | To: [EMAIL PROTECTED] | Subject: [boost] RE: Math Constants Formal Review | | Another point I am missing is a way to extend the constants | for user-defined types. Something like numeric_limits<> | comes to mind. I think that this is a must-have feature as | people that write applications that need lots of these | constants are likely also using types with higher precision | that the standard types provided by the language. Without a | way to teach the constants-framework the new types, they | will create wrappers and thus they won't use the intended | boost-/standard-way to access the variables. | | Regards, Daniel | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
None of the material is yet ready for inclusion in Boost, (with the possible exception of the C Macro values). What I would like to get is agreement on the presentation of constants. (Because there is much work in preparing the constants and I am reluctant to do this without assurance that it will finally be accepted.) I suggest unzipping the documentation in the docs file - in effect everything I am proposing from the previous dicussions is there. Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota | Sent: 06 June 2003 18:20 | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review | | | On Fri, 6 Jun 2003 06:45:45 -0700, "Jaap Suter" | <[EMAIL PROTECTED]> wrote: | | >To all, | > | >Today is the start of the formal review of the Math | Constants library | >by Paul Bristow. The review will run until Sunday June 15th. | | I tried to have a look but was assailed by a fairly large | amount of material :-) Can we a have a .zip with just what | is candidate for inclusion into boost? | | | Genny. | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Math Constants Formal Review
OK - Sorry I have chosen a poor example - I should have stuck to pi throughout! but I hope the review can concentrate on what emerged previously as the _really_ tricky issue of how to _present_ the values in C++, before we tackle the much easier, (if still contentious) issue of individual names of constants. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Reece Dunn | Sent: 06 June 2003 15:47 | To: [EMAIL PROTECTED] | Subject: Re: [boost] Math Constants Formal Review | This is the Euler-Mascheroni Constant | (http://mathworld.wolfram.com/Euler-MascheroniConstant.html), and is denoted by a gamma or as C: const float C = 0.5772156649015328606065120900824024310422F; // Euler-Mascheroni constant >I would have expected e to be 2.71828... So would I. The Euler constant has the value e = 2.718281828459045235360287471352662497757... (source: http://mathworld.wolfram.com/e.html) Regards, Reece ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Review Request: cyclic_buffer
Sorry, I forgot - as with all Boost test-suite examples, language extensions MUST be enabled (and also /EHa option for WINNT). Now OK MSVC 7.1 with Boost 1.30 at warning 3 and a few warnings at level 4 (from your test.cpp - lots from the test suite, but this is probably inevitable). Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jan Gaspar | Sent: Thursday, June 05, 2003 9:55 AM | To: Boost mailing list | Subject: Re: [boost] Review Request: cyclic_buffer | | | Even with boost 1.30 I got just some warnings, but no errors. I don't | know what's | wrong. | | Jan | | "Paul A. Bristow" wrote: | | > This now looks very extensively tested. But when I tried to build | the test.cpp | > using MSVC 7.0 and Boost 1.30, there are zillions of errors from the test | > modules. Do I need to use a more recent version of the test code? | > | > Thanks | > | > Paul | > | > Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK | > +44 1539 561830 Mobile +44 7714 33 02 04 | > Mobile mailto:[EMAIL PROTECTED] | > mailto:[EMAIL PROTECTED] | > | > | -Original Message- | > | From: [EMAIL PROTECTED] | > | [mailto:[EMAIL PROTECTED] Behalf Of Jan Gaspar | > | Sent: Wednesday, June 04, 2003 10:49 AM | > | To: [EMAIL PROTECTED] | > | Subject: [boost] Review Request: cyclic_buffer | > | | > | | > | Hi all! | > | | > | The cyclic buffer implementation and documentation | (cyclic_buffer.zip) can be | > | found at: | > | http://groups.yahoo.com/group/boost/files/ | > | | > | Regards, | > | | > | Jan | > | | > | | > | -- | > | Jan Gaspar | [EMAIL PROTECTED] | > | Whitestein Technologies | www.whitestein.com | > | Panenska 28 | SK-81103 Bratislava | Slovak Republic | > | Tel +421(2)5930-0721 | Fax +421(2)5443-5512 | > | | > | | > | ___ | > | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost | > | | > | | > | > ___ | > Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost | | -- | Jan Gaspar | [EMAIL PROTECTED] | Whitestein Technologies | www.whitestein.com | Panenska 28 | SK-81103 Bratislava | Slovak Republic | Tel +421(2)5930-0721 | Fax +421(2)5443-5512 | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Review Request: cyclic_buffer
This now looks very extensively tested. But when I tried to build the test.cpp using MSVC 7.0 and Boost 1.30, there are zillions of errors from the test modules. Do I need to use a more recent version of the test code? Thanks Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jan Gaspar | Sent: Wednesday, June 04, 2003 10:49 AM | To: [EMAIL PROTECTED] | Subject: [boost] Review Request: cyclic_buffer | | | Hi all! | | The cyclic buffer implementation and documentation (cyclic_buffer.zip) can be | found at: | http://groups.yahoo.com/group/boost/files/ | | Regards, | | Jan | | | -- | Jan Gaspar | [EMAIL PROTECTED] | Whitestein Technologies | www.whitestein.com | Panenska 28 | SK-81103 Bratislava | Slovak Republic | Tel +421(2)5930-0721 | Fax +421(2)5443-5512 | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] IO Formatting Manipulators
I can confirm that those examples I have tried work OK with MSVC 7.1 type_deduction compiles and runs and looks as is it works. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Reece Dunn | Sent: Tuesday, June 03, 2003 7:32 PM | To: [EMAIL PROTECTED] | Subject: RE: [boost] IO Formatting Manipulators | Paul A. Bristow wrote: | | >My impressions of this are highly favourable from the examples and tests, | >but I | >haven't tried to use it in anger yet as I am uncertain if it compiles with | >MS.net 2003 (aka 7.1?). Is this known yet? Suck it and see? | | I do not have access yet to MS VC7.1, so I have not been able to test it on | this compiler. I have only had the oppotunity to test on: | * MS VC7.0 | * GCC 3.2.2 | * GCC 3.3 | * Borland C++Compiler 5.5 | | It should work on VC7.1 since it works on VC7.0 and GCC 3.x. If anyone can | test my library on this compiler, or any others, I'd be greatful for | feedback (test/example output, error messages, etc). | | Type/outputter deduction is working for GCC 3.x. The type deduction works on | Borland, but it chokes on outputter deduction (can't figure this one out | yet). MS VC7.0 does not have this facility since there is no template | partial specialization; not checked for VC7.1 (may or may not need | modification to work on it). ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: I/O library status
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Ed Brey | Sent: Tuesday, June 03, 2003 2:49 PM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Re: I/O library status | | Beyond these are the performance concerns of course; | | rather than the more efficient and arguably more readable: | | cout << | "My first line" "\n" | "My second line"; Are you sure that this is more efficient? cout << "My first line" << endl << "My second line"; has proven LESS efficient and I suspect the flush caused by encountering \n will have the same effect. Of course, the differences are tiny in practice. I view the newl as much clearer. And the concept that endl actually writes the buffered output doesn't seem too complicated. As a non-C programmer, "\n" looks plain nasty to me :-( Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] IO Formatting Manipulators
My impressions of this are highly favourable from the examples and tests, but I haven't tried to use it in anger yet as I am uncertain if it compiles with MS.net 2003 (aka 7.1?). Is this known yet? Suck it and see? (A feature I do not see is control of the number of items before a newline. I am not sure if this is a sensible feature in these days of scroll bars and I can see it is fraught with difficulties). I didn't spot any examples with floating point values. Do these introduce any hidden snags? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Reece Dunn | Sent: Monday, June 02, 2003 12:42 PM | To: [EMAIL PROTECTED] | Subject: [boost] IO Formatting Manipulators | | | Does anyone have any ideas/suggestions: | * on where I should extend the code | * what features they would like to see that are not currently available | * bugs/inconsistencies with existing features | | I would also like to have comments on what people want out of the | documentations. Whether they want: | * a technical description of the facilities |* an 'under the hood' look at the implementation | * standardese description of the classes | * detailed examples of how to output a given type | * organisational ideas (e.g. separate the tutorial from the main section) | * rationale for the various design choices | * other features | | NOTE: Because I have revised the main code, I am looking at overhauling what | documentation I had. The documentation is high on my to do list, but I have | not started it yet as I have been busy. I should start it on Wednesday. | | All feedback would be very welcome. | | PS: Here is a link to the latest version in case you missed it. |http://lists.boost.org/MailArchives/boost/msg47757.php | | Regards, | Reece | | _ | Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: I/O library status
I agree with these conclusions and strongly support the addition of newl. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Thomas Witt | Sent: Tuesday, June 03, 2003 8:19 AM | To: Boost mailing list | Subject: Re: [boost] Re: I/O library status | | | | Hi, | | On Monday 02 June 2003 19:21, Ed Brey wrote: | > * newl differs from '\n' only in that newl doesn't perform background | > formatting. Presumably one would choose to use newl to avoid the | > formatting. What is undesirable about '\n' being formatted? | | To me there are basically two reasons that make newl desirable beside the | formatting issue. | | 1. std::endl was and is still abused heavily. I think there is a reason for | this. Most c++ programmers are taught to stay clear of ugly low-level c | things and to use the new shiny c++ facilities instead. And that's what they | do, replace '\n' with std::endl. Personally I believe this reason alone | justifies a std library extension std::newl. | | 2. IIUC the difference between a character and a manipulator is that the | manipulator is not tied to the streams character type. So for some | applications '\n' does not suffice. To me stream.widen('\n') is sufficiently | ugly to justify a newl modifier. | | Thomas | | -- | Dipl.-Ing. Thomas Witt | Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover | voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 | http://www.ive.uni-hannover.de | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: I/O operators for Interval library
Sorry I have been away on holiday and couldn't comment sooner. This whole problem is rather complicated and I accept Guillaume's view that the interval library IO may best be left minimal or non-existent (though some examples may save users, especially novice users, some time in devising something to suit themselves. Terje's is a useful example, like Guillaume's - which should be documented as an example, not removed). I have devised an uncertain scheme based on code by Evan Manning ([EMAIL PROTECTED]) Evan Marshal Manning C/C++ Users Journal, March 1996 page 29 to 38. original downloaded from ftp://beowulf.jpl.nasa.gov/pub/manning A fuller collection of even fancier classes also given in UReal.h. Standard deviation & its uncertainty added Paul A Bristow 31 Mar 98 to Jun 03. but found it rather messy to implement (especially input). It might be cleaner inheriting from the interval library (though I am not sure). Quite how to bring this, and the quantity library together, is a major task, but I remain convinced it is an important objective. Now that the major compiler incompatibility and in completeness problems appear to be solved, I will look at my code again. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Terje Slettebø | Sent: Monday, May 05, 2003 11:17 PM | To: Boost mailing list | Subject: Re: [boost] Re: I/O operators for Interval library | | | >From: "Guillaume Melquiond" <[EMAIL PROTECTED]> | | > On Mon, 5 May 2003, [iso-8859-1] Terje Slettebø wrote: | > | > > >From: "Guillaume Melquiond" <[EMAIL PROTECTED]> | > > | > > The proposed output operator may be more general-approach, though, for | the | > > cases where intervals are used to specify precision, so it might be | useful | > > to provide it in some way, rather than each user having to make it. | > | > Unfortunately, is there really a version of the operators that could be | > useful to more than a few users? | | I guess it depends. As mentions, Paul A. Bristow brought up the issue of | using the Interval library with a quantity library. Unless the values are | represented in a way that's easy to understand, such as this, it may be hard | to use it with it. If he's reading this, maybe he could comment? | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] needed?
Yes to all of these. Paul | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Friday, May 30, 2003 4:05 PM | To: Boost mailing list | Subject: [boost] needed? | | | C99 has a header which provides types, macros, and functions "to | provide access to the floating-point environment." | | Some Boost code in the Interval Library uses this header, or has to do | workarounds if not present. Metrowerks, GCC, and Dinkumware currently ship | the header, but many others don't. | | * Should we have a header? (Greg Chicares asked the same | question a couple of years ago but got to reply.) Is there any general | workaround for when a vendor supplied isn't present? | | * Should there be a macro indicating | availability? | | * Should we start suggesting to vendors that they supply ? | | Any opinions from floating point users? | | --Beman | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost Library Guidelines
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of William E. Kempf | Sent: Tuesday, April 29, 2003 8:40 PM | To: [EMAIL PROTECTED] | Subject: RE: [boost] Boost Library Guidelines | > This sounds 'best practice'. If others agree, can it be added to the | > guidelines? | | It sounds good in theory, but I've never been comfortable living with it. | I know others do, but in my experience, especially with the MS compiler, | the highest warning level produces a LOT of meaningless diagnostics which | can be very difficult to eliminate... even with pragmas. As a "best | practice suggestion", it's a great idea... as a requirement, I'd have to | voice an opinion against. I absolutely agree, but I feel it would be useful encourage authors to try. Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] lexicographic
This looks neat and will sometimes be very useful in reducing mistakes. Tests OK with MSVC 7.0. Some more fully worked examples like using std::pair and case insensitive strings are likely to be the most common applications, so these would help sell its use. (The tests are not ideal for this purpose, though illuminating examples). For a submission, the tests could usefully use BOOST's own test suite and perhaps for completeness add a few more like checking the free == and != operators. Tests like "assert(!l1)" and "if(l1)" implicitly use the bool conversion which might be noted in a comment. The enum result_type which might be documented as: enum result_type { minus = -1, equivalent = 0, plus = +1}; "lexicographic" is a serious fingerfull to type :-( Paul PS Spelling nits: comparision also a fingerfull compared to comparison ;-) and cpomplex too. Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jan Langer | Sent: Thursday, April 17, 2003 8:27 AM | To: [EMAIL PROTECTED] | Subject: [boost] lexicographic | | | hi, | three weeks ago i asked for interest in a utility class for comparing | data lexicographically. i got several suggestions, and i tried to | incorporate them. now i put the header, a documentation file and a test | into the sandbox. the name is now boost/utility/lexicographic.hpp. | jan | | -- | jan langer ... [EMAIL PROTECTED] | "pi ist genau drei" | | | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] C++ Standard Library proposal - MathfunctionsforStatistics
I absolutely agree that they are to serve *practical* purposes, and I would encourage any guide to accuracy that authors (and others) can provide. Some functions are easy - within a few eps over the whole domain. You say "LIA has already set framework for those things", but is it really suitable for 'more difficult' functions? But I would caution that, for some functions, there are even more PhDs of study of accuracy than in algorithms themselves. It would cost vendors more to provide comprehensive accuracy information than writing the functions. For a start, I have not found many really accurate reference values for some functions (A&S sometimes struggle to achieve float 32-bit). Many published algorithms provide almost no accuracy data. How do you specify accuracy (never mind speed and size)? Stephen Moshier in his collection provides a mean and max from thousands of random arguments, which is certainly useful, but may mislead - like sincos near to multiples of pi. So there is some danger of starting the equivalent of processor chip 'benchmark wars'. For many practical statistical purposes, 32-bit float accuracy will suffice. Do you need to know that the probability of two means being different is 0.95475869798765823? Often one just decides if it is > 0.95. And the probability probably has a 95% confidence interval of 0.9 to 0.97 anyway! So, for me, the most important thing is to have some implementation for people to put to practical use, while others work on improvements and descriptions of accuracy. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Example of accuracy data from Cephes incomplete beta - good - but shows how complicated it is! * ACCURACY: * Tested at uniformly distributed random points (a,b,x) with a and b * in "domain" and x between 0 and 1. *Relative error * arithmetic domain # trials peak rms *IEEE 0,5 1 6.9e-15 4.5e-16 *IEEE 0,85 25 2.2e-13 1.7e-14 *IEEE 0,1000 3 5.3e-12 6.3e-13 *IEEE 0,125 9.3e-11 7.1e-12 *IEEE 0,101 8.7e-10 4.8e-11 * Outputs smaller than the IEEE gradual underflow threshold * were excluded from these statistics. | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Wednesday, April 23, 2003 9:15 PM | To: Boost mailing list | Subject: Re: [boost] C++ Standard Library proposal - Math | functionsforStatistics | | | "Paul A. Bristow" <[EMAIL PROTECTED]> writes: | | | Indeed, I doubt if long double is practically useful for many applications - | | even 16 decimal place 64-bit double will be impracticable on MSVC | where there | | isn't really a long double (you may need to use 80-bit calculations to get a | | 64-bit accuracy result). | | | | But I don't believe that this is a problem - exp, sin etc don't | really work for | | long double on MSVC either! And many implementations are not fully | accurate - | | nor would one necessarily want to wait while they calculate to full | accuracy. | | | | The Standard does not, and should not, make any requirements about accuracy, | | memory size or speed. | | | | So I feel they are panicing a bit. | | Being one of the persons who raised the accuracy issue, I think I have | to say why. | | The proposed mathematical functions are not there just for selling | compilers. They are there to serve *practical* purposes. If there is | no accuracy guarantee, they don't worth to have -- they are already so | specialized. LIA has already set framework for those things. Any | serious proposal to include such specialized functions need to pay | attention to those things. | | -- Gaby | ___ | Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Statistics code example -usingcycliciterator/buffer/array
Thanks for this, which I have just got round to trying out.Sadly, MSVC 7.0 now gags on it as below. Is there something I need to #define? (I assume that the previous config.h is replaced by the boost config). Is the warning C4253 a worry? Is remains at warning level 3 (and I like things to be warning free at level 4 if possible). Thanks Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : test_cyclic_buffer.cpp j:\Cpp\cyclic_buffer\cyclic_buffer.hpp(324) : warning C4253: 'boost::AssignableConcept::constraints' : forming a pointer-to-member requires explicit use of the address-of operator ('&') and a qualified name j:\Cpp\cyclic_buffer\cyclic_buffer.hpp(831) : see reference to class template instantiation 'boost::cyclic_buffer' being compiled j:\Cpp\cyclic_buffer\cyclic_buffer.hpp(388) : error C2977: 'std::reverse_iterator' : too many template arguments C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xutility(723) : see declaration of 'std::reverse_iterator' j:\Cpp\cyclic_buffer\cyclic_buffer.hpp(391) : error C2977: 'std::reverse_iterator' : too many template arguments C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xutility(723) : see declaration of 'std::reverse_iterator' j:\Cpp\cyclic_buffer\cyclic_buffer.hpp(324) : warning C4253: 'boost::AssignableConcept::constraints' : forming a pointer-to-member requires explicit use of the address-of operator ('&') and a qualified name with [ TT=int ] test_cyclic_buffer.cpp(45) : see reference to class template instantiation 'boost::cyclic_buffer' being compiled with [ T=int, Alloc=std::vector>::allocator_type ] j:\Cpp\cyclic_buffer\cyclic_buffer.hpp(388) : error C2977: 'std::reverse_iterator' : too many template arguments C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xutility(723) : see declaration of 'std::reverse_iterator' j:\Cpp\cyclic_buffer\cyclic_buffer.hpp(391) : error C2977: 'std::reverse_iterator' : too many template arguments C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xutility(723) : see declaration of 'std::reverse_iterator' | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jan Gaspar | Sent: Thursday, April 10, 2003 4:07 PM | To: Boost mailing list | Subject: Re: [boost] Statistics code example - | usingcycliciterator/buffer/array | | | Hi all! | | I have refactored my implelentation of the cyclic buffer. Its | underlaying container is now vector | (previosly it was deque). There is still one problem - iterator | invalidation. If you add or remove an | element from the end of the buffer, the iterators becomes invalidated. | | Jan | | -- | Jan Gaspar | [EMAIL PROTECTED] | Whitestein Technologies | www.whitestein.com | Panenska 28 | SK-81103 Bratislava | Slovak Republic | Tel +421(2)5930-0721 | Fax +421(2)5443-5512 | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost