Re: [Boost-users] WinDbgCached_exe recognize has threat by Bitdefender
From: Boost-users On Behalf Of Mauro Ziliani via Boost-users Sent: 31 May 2021 17:45 To: boost-users@lists.boost.org Cc: Mauro Ziliani Subject: [Boost-users] WinDbgCached_exe recognize has threat by Bitdefender Hi all. I build boost 1.76.0 woth Visual Studio 2019. I try to scan my pc with bitdefender (free version). Bitdefender discover a threat in boost_1_76_0\bin.v2\stacktrace\build\msvc-142\release\address-model-32\link-static\threading-multi\WinDbgCached_exe.exe. The threat is recognized as Gen:Variant.Fugrafa.139255 Any idea about? I have placed my Boost stuff in a separate partition and excluded it from Bitdefender after persistent false positives like this. You could also consider deleting some or all of /bin.v2. These files are in effect a sort-of caching zone used by b2/bjam. It will be rebuilt by running b2 – taking a bit longer to re-build. (If you run out of disk space, you may also need to do this). Paul ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Re: [Boost-users] limited accuracy for tanh-sinh integrator
> -Original Message- > From: Boost-users On Behalf Of John > Maddock via Boost-users > Sent: 16 August 2020 21:24 > To: Anirban Pal via Boost-users > Cc: John Maddock > Subject: Re: [Boost-users] limited accuracy for tanh-sinh integrator > > > On 16/08/2020 21:15, Anirban Pal via Boost-users wrote: > > > > Hello, > > > > I’m using the tanh-sinh integrator to integrate a simple function f(x) > > = 0.26*x from 3.0 to 4.0. > > The exact result is 0.91. With the integrator I’m getting a result > > accurate to only 10^-18 with cpp_bin_float_100 multiprecision. > > > You have the double precision constant 0.26 in your code, and since this is > an inexact binary value, > everything that depends on that constant is inherently limited to double > precision. Try constructing it > as Real(26) / 100. Everyone falls into this pit, and in my case, repeatedly ☹ You need to be ever vigilant not to use double precision items by mistake. Using numeric_limits<>::max_digits10 is useful because it shows the digits beyond double at about 17 decimal digits. Being random should raise suspicions. If you are only using multiprecision types, then always using decimal digit strings like "1.23456" is simple. If you can use a fraction like Real(1)/1000 that also works fine. You may also find the macro BOOST_MATH_TEST_VALUE in I:\boost\libs\math\test\test_value.hpp helpful if you want to make code portable over different floating-point types from fundamental to multiprecision? Paul ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Re: [Boost-users] Integrate function with arguments using quadrature
From: Boost-users On Behalf Of Anirban Pal via Boost-users Sent: 14 August 2020 22:57 To: boost-users@lists.boost.org Cc: Anirban Pal Subject: [Boost-users] Integrate function with arguments using quadrature Hello, I'm trying to integrate functions with BOOST quadrature routines. So far they have been extremely impressive accuracy-wise, particularly with multiprecision features. I wish to integrate a function and pass some arguments to it. These arguments can be scalars, matrices, structs or objects. I was wondering if there is an example that explores this. Would I need to use a boost.function? Or would a function pointer work? I currently have an implementation using GSL_functions which explicitly allow the function and parameters to be passed as pointers. I am curious if I can do something similar with boost. I suspect so. Are these example any help to you? https://www.boost.org/doc/libs/1_74_0/libs/math/example/ooura_fourier_integrals_cosine_example.cpp https://www.boost.org/doc/libs/1_74_0/libs/math/example/ooura_fourier_integrals_example.cpp https://www.boost.org/doc/libs/1_74_0/libs/math/example/ooura_fourier_integrals_multiprecision_example.cpp HTH Paul ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Re: [Boost-users] Difficulty using boost quadrature library
You need to decide on which Real type you want, perhaps
#include
and then chose perhaps a quad precision type like cpp_bin_float_quad for
128-bit precision
You can then either use a typedef to define Real
typedef cpp_bin_float_quad Real;
or pass cpp_bin_float_quad as a template parameter into your own function.
HTH
Paul
PS It would be nice if we had a fully worked example?
From: Boost-users On Behalf Of Anirban
Pal via Boost-users
Sent: 14 August 2020 01:08
To: boost-users@lists.boost.org
Cc: Anirban Pal
Subject: [Boost-users] Difficulty using boost quadrature library
Hello everyone,
I'm new to using boost and I'm trying to use its quadrature routines,
specifically
the tanh_sinh integrator. I'm trying to run the examples here:
https://www.boost.org/doc/libs/1_66_0/libs/math/doc/html/math_toolkit/double_exponential/de_tanh_sinh.html
I've been successful using it with the double datatype. However, I can't seem
to work with the Real datatype. When I run the following, I'm successful.
tanh_sinh integrator;
auto f = [](double x) { return 5*x + 7; };
double Q = integrator.integrate(f);
Q = integrator.integrate(f, 0.0, 1.1);
But when I run the following:
auto f = [](Real x) { return log(x)*log(1-x); };
Real Q = integrator.integrate(f, (Real) 0, (Real) 1);
I get the error:
boost_test.cxx: In function ‘int main(int, char**)’:
boost_test.cxx:47:15: error: ‘Real’ has not been declared
auto f2 = [](Real x) { return log(x)*log(1-x); };
^~~~
boost_test.cxx:48:2: error: ‘Real’ was not declared in this scope
Real Q2 = integrator.integrate(f2, (Real) 0, (Real) 1);
I think I need to include the right headers for this to go away. However, I'm
not sure what the correct header file is.
Thank you for your attention.
--
Anirban Pal
___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Re: [Boost-users] bjam resources
https://boostorg.github.io/build/tutorial.html is the most helpful in my experience. But the failure of B2/bjam to become popular is because of the lack of really helpful tutorials and examples, despite some nice new documentation that is nicely displayed, though not indexed enough to make easy finding what you want to know. Paul > -Original Message- > From: Boost-users On Behalf Of Antonis > Polykratis via Boost- > users > Sent: 18 July 2020 08:54 > To: Boost-users@lists.boost.org > Cc: Antonis Polykratis > Subject: [Boost-users] bjam resources > > Hello, > are there any bjam tutorials documentation about how I could create a project > using bjam? > > Thanks > ___ > Boost-users mailing list > Boost-users@lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Re: [Boost-users] Boost ABI/Linkage of clang vs g++
> -Original Message- > From: Boost-users On Behalf Of DV > Henkel-Wallace via Boost- > users > Sent: 9 July 2020 15:41 > To: Mathias Gaunard > Cc: DV Henkel-Wallace ; boost-users@lists.boost.org > Subject: Re: [Boost-users] Boost ABI/Linkage of clang vs g++ > > > > On Jul 9, 2020, at 04:25, Mathias Gaunard > > wrote: > > > > On Thu, 9 Jul 2020 at 08:07, DV Henkel-Wallace via Boost-users > > wrote: > > > >> We build with clang++-10 w/libc++.a and g++-10 w/libstdc++.a, so > >> build a copy of boost in each configuration as well. This works > >> great on the Mac development machines but the clang case doesn't > >> generate the correct linkage on the Linux deployment machines. The > >> correct clang linkage is std::__1::basic_string... but boost builds > >> with std::__cxx11::basic_string > > > > libc++ is not binary compatible with libstdc++. > > You need to use either libstdc++ or libc++ with both compilers if you > > want binary compatibility. > > > > This doesn't have anything to do with Boost. > > Thanks Mathias. I did not express my problem clearly. This is a b2 issue; I > doubt any _library source > code_ has any direct interaction with this and I'm sorry if I accidentally > gave that impression. Is there a > way to get b2 to disgorge the environment and tool invocation of each step > (basically what is passed to > system() or exec())? > > The background, perhaps clarified: > > We have our own code, some third party code (like Boost) and of course > different runtime platforms > (Mac, iOS, Linux...). Since different platforms use different > compilers/runtimes as their "native" stack, > our development system builds everything end-to-end with both gcc and clang > to catch problems as > early as possible. All compilation is with c++14 or later, post the C++11 > ABI break, hence the naming > issues. This process isolates us from any system libraries that don't have C > linkage. > > Therefore g++ is used to compile libstdc++, boost, other third party code, > and our code. Symbols are > generated that use __c++11:: in their name. > And clang++ is used to compile libc++, boost, other third party code, and our > code. Symbols are > generated that use use __1:: in their name. > > But boost itself is compiled via b2 and what is passed to the compiler (and > which compiler b2 chooses) is > quite opaque. Despite my attempts to force the use of clang it appears that > b2 is either calling g++ or > otherwise asking clang to use g++-style symbol linkage on Linux. On the Mac > the same invocation > behaves as expected. > > I'm compiling boost this way: > > export CC=clang CXX="clang++ -stdlib=libc++" CXXSTD=c++20 ; ./b2 > stdlib=libc++ toolset=clang > boost.locale.icu=off boost.locale.std=off --with-atomic --with-chrono > --with-date_time --with-headers -- > with-locale --with-log --with-program_options --with-random --with-regex > --with-system --with-thread > threading=multi -sNO_COMPRESSION=1 link=static install > > Any thoughts on how to debug this? Does b2 -debug-configuration help? https://boostorg.github.io/build/manual/master/index.html section 3.3 configuration ☀ You can use the --debug-configuration option to find which configuration files are actually loaded. Paul ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Re: [Boost-users] [review][LEAF] Review of LEAF starts today : May 22 - May 31
> -Original Message- > From: Boost-users On Behalf Of Michael > Caisse via Boost-users > Sent: 22 May 2020 10:32 > To: Boost users list > Cc: Michael Caisse > Subject: [Boost-users] [review][LEAF] Review of LEAF starts today : May 22 - > May 31 > > The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error > Augmentation Framework) library > will take place from May 22 through May 31st. > > LEAF isn't just another error reporting library in the family of > expected-like types. It provides a unique > take on error handling which plays into usability, flexibility, and > performance. > > Some other questions you might want to consider answering: > > - What is your evaluation of the design? Above my pay-grade, but looks reasonable. > - What is your evaluation of the implementation? Above my pay-grade, but looks as though it works OK from examples and user experience. Feels refined and the product of much work. > - What is your evaluation of the documentation? Outstanding. Excellent. > - What is your evaluation of the potential usefulness of the library? I'm sure some people will find it useful. > - Did you try to use the library? I didn't try to use it - because I am not too unhappy with 'simple' try'n'catch exception programming. > - How much effort did you put into your evaluation? I've read, and re-read the documentation and examples, and all the reviews. > - Are you knowledgeable about the problem domain? No - but the Big Thing I know is that the Less-expected Doesn't Work Well. * The hardware seems little help - bounds like containers are only available slowly and painfully. * The software seems to have to be either fast and unhelpful, or slightly helpful at major computational cost (C++ exceptions). * The programmers are idle and unhelpful. How my blood pressure has been raised by shouting "Which file?" to "File not found."! * Too much give-up quickly "Something went wrong." Call C++ std::terminate ☹ * OK - enough - everyone agrees that things are not good. LEAF isn't The Silver Bullet, but clearly is reasonable way of doing things, and well done. So the problem for Boost is whether to reject it on grounds that better ways exists, or accept it as a useful tool, helpfully documented. It raises the number of ways for doing these things from perhaps three to four, but that's not much worse - it just is confusing. (I am not over concerned at Boost Bloat - it is only programmers disk space that is idle/wasted. We MUST sell that better!) So in the end I conclude that it turns on deciding if Boost should offer a choice tools, or should it make a single recommendation? I see no case for any one Best Exceptions Tool, so I believe that we should ACCEPT LEAF. Paul A. Bristow ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Re: [Boost-maint] Community Maintenance Team and neglected libraries
-Original Message- From: Boost-maint [mailto:boost-maint-boun...@lists.boost.org] On Behalf Of Andrey Semashev Sent: 22 April 2014 19:10 To: boost-maint@lists.boost.org Subject: Re: [Boost-maint] Community Maintenance Team and neglected libraries On Wednesday 23 April 2014 00:29:17 Ben Pope wrote: In case you haven't heard of the CMT: https://svn.boost.org/trac/boost/wiki/CommunityMaintenance I'm also interested in getting the test results less yellow and more green, I don't have a lot of time, I'm sure I'm not alone. There are quite a few places where the library code is probably fine, but the failure is in the test itself, the fix is often simple and uncontroversial. These easy fixes should just happen; make a pull request, ticket with patch, whatever; commit goes in; reminder when tests have cycled; merged to master; profit. This is a recurring topic and unfortunately the problem still stands. CMT was a step forward, but to my mind this is not enough. With SVN we had commit rights everywhere, and such simple fixes went in much easier. After modularization some libraries were left effectively unmaintained and inaccessible. CMT does have rights to push to some libraries but not all and therefore does not fix the problem completely. To my mind CMT should have access to all libraries, maintained or not. If a given library is actively maintained then CMT doesn't need to intervene. However, if the maintainer goes silent for considerable time, CMT has the ability to apply such fixes. +1 I'd go so far as to suggest that we go back to the previous SVN arrangements where all library authors had write access to everything. I don't remember it causing trouble - rather that it was felt so ill-mannered to change someone else's library that changes were not made when it would have much better if they had! Where I feel a finer grained control is useful is to allow write access just to experimental branches from develop. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-maint
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
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_castT(lexical_caststring(any_value))
is always true
The following replacement for the original code (using digits10+1) works for
specialised radix 2 types:
if(std::numeric_limitsTarget::is_specialized
std::numeric_limitsTarget::radix == 2)
{
stream.precision(2 + std::numeric_limitsTarget::digits * 301/1000);
}
else if(std::numeric_limitsSource::is_specialized
std::numeric_limitsSource::radix == 2)
{
stream.precision(2 + std::numeric_limitsSource::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_castT(lexical_caststring(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
[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
RE: [boost] number64 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] number64 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: 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] 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_limitsTarget::is_specialized
std::numeric_limitsTarget::radix == 2)
{
stream.precision(2 + std::numeric_limitsTarget::digits * 301/1000);
}
else if(std::numeric_limitsSource::is_specialized
std::numeric_limitsSource::radix == 2)
{
stream.precision(2 + std::numeric_limitsSource::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_castT(lexical_caststring(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_castT(lexical_caststring(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 typename T bool test(T l)
{
cout l ' ';
string sl = lexical_caststring(l);
cout sl ' ';
T ll = lexical_castT (sl);
cout ll
(l == lexical_castT(lexical_caststring(l)))
// Convert type T to string and back to T.
endl; // eg for long 2147483647 2147483647 2147483647true
return (l == lexical_castT(lexical_caststring(l)));
} // test
template typename T bool tests()
{
if (numeric_limits T ::is_specialized)
{
cout numeric_limits T ::digits ' ' numeric_limits T ::digits10
' ' 2 + std::numeric_limitsT::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
testsbool ();
testschar ();
testsunsigned char ();
testsshort ();
testsunsigned short ();
testsint ();
testslong ();
testsunsigned long ();
testsfloat ();
testsdouble ();
testslong double ();
___
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
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: 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 iostream
| #include string
| #include limits
|
| class big_decimal
| {
| public:
| big_decimal() : m_val( 1.23456789 ) {}
| public:
| double m_val;
| };
|
| namespace std {
| class numeric_limitsbig_decimal
| : public numeric_limitsdouble
| {
| };
| }
|
| std::ostream operator( std::ostream s, big_decimal const arg )
| {
| return s arg.m_val;
| }
|
| int main()
| {
| big_decimal dec;
| std::cout boost::lexical_caststd::string( dec ) \n;
| std::cout boost::lexical_caststd::string( 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
|
|
---BeginMessage---
I note that the 'precision' number of digits in lexical cast is obtained from
digits10 +1
if(std::numeric_limitsTarget::is_specialized)
{
stream.precision(std::numeric_limitsTarget::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_limitsFPType::digits).
In C++ the full formula is:
int significant_digits10 = int(ceil(1 + float_significand_digits * log10Two));
and using this formula :
std::numeric_limitsfloat::digits = 24 significand bits
std::numeric_limitsfloat::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_limitsdouble::digits = 53
std::numeric_limitsdouble::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
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_castfloat(lexical_caststring(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: 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: 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: 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_generatorTokenizerFunc,Iterator,Type::value_type' (or
| there is no acceptable conversion)
| with
| [
| TokenizerFunc=boost::char_delimiters_separatorchar,
|
| Iterator=std::basic_stringchar,std::char_traitschar,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_streamTarget,Source::operator (const Source )'
| with
| [
| Target=unsigned short,
|
| Source=boost::token_iterator_generatorboost::char_delimiters_separato
| rchar,st
| d::basic_stringchar,std::char_traitschar,std::allocatorchar::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
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_generatorTokenizerFunc,Iterator,Type::value_type' (or
there is no acceptable conversion)
with
[
TokenizerFunc=boost::char_delimiters_separatorchar,
Iterator=std::basic_stringchar,std::char_traitschar,std::allocatorchar::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_streamTarget,Source::operator (const Source )'
with
[
Target=unsigned short,
Source=boost::token_iterator_generatorboost::char_delimiters_separatorchar,st
d::basic_stringchar,std::char_traitschar,std::allocatorchar::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: 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: 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
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
[boost] FW: Eric Ford Units - changes needed for MSVC 7.1
---BeginMessage--- 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_fractypename A::base1,typename B::base1::value, typename add_fractypename A::base2,typename B::base2::value, typename add_fractypename A::base3,typename B::base3::value, typename add_fractypename A::base4,typename B::base4::value, typename add_fractypename A::base5,typename B::base5::value, typename add_fractypename A::base6,typename B::base6::value, typename add_fractypename A::base7,typename B::base7::value, typename add_fractypename A::base8,typename B::base8::value, typename add_fractypename A::base9,typename B::base9::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_typeArgNumericType, typename inv_dimldiml_type::type struct mul_return_typeArgNumericType, typename inv_dimldiml_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] 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] 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_limitsTarget::is_specialized)
{
stream.precision(std::numeric_limitsTarget::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_limitsFPType::digits).
In C++ the full formula is:
int significant_digits10 = int(ceil(1 + float_significand_digits * log10Two));
and using this formula :
std::numeric_limitsfloat::digits = 24 significand bits
std::numeric_limitsfloat::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_limitsdouble::digits = 53
std::numeric_limitsdouble::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_limitsFPType::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_limitsTarget::is_specialized)
{ // Show all significant decimal digits, 2 or 3 more than digits10.
stream.precision(2 + std::numeric_limitsTarget::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
[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] 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
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] 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] 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_limitsdecimal::is_specialized is true numeric_limitsdecimal::radix is 10 numeric_limitsdecimal::digits 9 numeric_limitsdecimal::digits10 9 numeric_limitsdecimal::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_limitsdecimal::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] Revised streambuf library
Sadly the test program fails to compile MSVC 7.1 as indicated below:
templatetypename Ch, typename Tr = std::char_traitsCh
struct basic_string_source
: private base_from_member std::basic_stringCh, Tr ,
public iterator_source
typename std::basic_stringCh, Tr::iterator,
Ch, Tr
{
typedef std::basic_stringCh, Tr string_type;
typedef typename string_type::iterator iterator;
typedef iterator_sourceiterator, Ch, Tr 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_sourceInIt,Ch,Tr::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_stringchar,std::char_traitschar,std::allocatorchar::iterat
or,
Ch=char,
Tr=std::char_traitschar
]
and
[
_Elem=char,
_Traits=std::char_traitschar,
_Ax=std::allocatorchar
]
and
[
_Elem=char,
_Traits=std::char_traitschar,
_Ax=std::allocatorchar
]
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_sourceCh::basic_string_source(const
boost::io::basic_string_sourceCh::string_type )'
with
[
Ch=char
]
testStreambuf_lib.cpp(57) : see reference to class template
instantiation 'boost::io::basic_string_sourceCh' 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_clientCh,Tr' 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] 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: 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: 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_limitsfloat::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: 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: 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] 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: 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] 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_limitsT::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] 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] 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] 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: 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
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 following code on the
original release which accompanied CFront. This is partially
because this corresponds to the version I use most often
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 ... snip | 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] 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] 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
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 areafloat(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] 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
templateclass T
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 areafloat(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_castT((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
templateclass T
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 iostream
|
| #define BOOST_DEFINE_MATH_CONSTANT(name)\
| const struct name##_type\
| {\
| name##_type() {}\
| templateclass T\
| operator T() const;\
| } name;
|
| #define BOOST_MATH_CONSTANT_VALUE(name, type, value)\
| template\
| name##_type::operator type() const { return value; }
|
...
|snip
| --- 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 - 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] 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 FU()() 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] 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] 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] 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] 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] 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 / (121)) / (130); // 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 interested in macros. I would prefer for the | library to only provide one kind of
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_casttype(x) simply selects
| | the corresponding specialization of x_value. So
| |
| |static_castfloat(pi)
| |
| | is fundamentally different from, say,
| |
| |double pi = ...;
| |static_castfloat(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 constantT, F
| pass through
|
|template typename U operator U() const { return F U ()(); }
|
| Now, FU()() means (ignoring some technical differences irrelevant
| here):
|
|FU object; // construct an x_valueU 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_castint(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 - 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 - 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 - 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 - 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_casttype(x) simply selects | the corresponding specialization of x_value. So | |static_castfloat(pi) | | is fundamentally different from, say, | |double pi = ...; |static_castfloat(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 - 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 - ()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_valueT::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: 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: 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: 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: 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 iostream
| 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()() const {
| static const RWDecimal RWMP3Int value(
| 3.1415926535897932384626433832 );
| return value;
| }
| };
| */
|
| // Here's the single line to create a useful interface
| struct pi_t : constant pi_t, pi_value {} pi;
|
| // Another one:
| template typename T struct
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: 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 boost/physics_constant_values.hpp
| struct g_t : constant g_t, g_value {} g;
|
| --- user adds to his project-header physics_constants.h:
|
| #include boost/physics_constant_values.hpp
| template struct g_value double
| { double operator()() const { 9.81424242424; } }; // Ha, I know better!
| #include boost/physics_constants.hpp
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: 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 - 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 complex). 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
| 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
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
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] 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] 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
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: 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] 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: 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] 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] 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 (AS 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] C++ Standard Library proposal - Math functionsforStatistics
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. 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, April 23, 2003 12:17 PM | To: Boost mailing list | Subject: RE: [boost] C++ Standard Library proposal - Math functions | forStatistics | | | At 04:21 AM 4/23/2003, Paul A. Bristow wrote: | | I feel Boost can also help by providing just one working implementation, | even if just at 32-bit float accuracy, so any vendor who doesn't feel | willing or able to provide a better one can still offer the Boost one | and claim compliance. | | What worried the vendors wasn't the float accuracy, but the long double | accuracy. | | One particular worry was that the amount of machine time required would be | on the order of months. | | --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] 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::AssignableConceptTT::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_bufferT,Alloc' 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::AssignableConceptTT::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_bufferT,Alloc' being compiled
with
[
T=int,
Alloc=std::vectorint,std::allocatorint::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
RE: [boost] Statistics code example
I believe this conjecture is correct, but I am still eagerly awaiting 7.1 :-)
This is quite interesting (though it needs Industrial Strengthening of course),
and could usefully generate the higher moments and other statistical thingys
too.
And it makes me wonder if one could use a container like a circular buffer. I
can think of applications where one would like new data to pour in continuously
and to look back for mean (weighted Kalmanesque?), perhaps only a limited
distance. Using a vector or valarray would imply it would grow for ever and run
out of space eventually. (I think someone else suggested something of this
sort?)
Is the STL queue suitable?
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: Thursday, April 03, 2003 3:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [boost] Statistics code example
MSVC 7 does not handle partial template specialization, so it will not
compile (you'll need to remove the above specialization). It should work for
MSVC 7.1 final beta, but I do not have a copy of it to verify.
The solution would be to wrap the above in a guard statement similar to:
#if !defined(BOOST_NO_PARTIAL_SPECIALIZATION)
templatetypename T
struct Stat_t std::complexT {
typedef typename std::complexT::value_type value_t;
};
#endif
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Statistics code example
Sadly (but perhaps not too surpringly) this does not seem to work for MSVC 7.0 with complex. (OK without) A full working example with at least a few comments might sell this better? 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 Neal D. Becker Sent: Tuesday, April 01, 2003 2:26 PM To: [EMAIL PROTECTED] Subject: [boost] Statistics code example Here is an example of a class that can compute 2nd order stats that will work for either scalar or complex types. It could be made slightly more efficient. It uses abs(), relying on the trick that abs() is defined for both scalar float and complex. It could be improved by defining our own norm function for both scalar float and complex. (Unfortunately for efficiency, complex norm is defined in terms of abs, which uses sqrt, on at least some systems (libstdc++)). ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] (no subject)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Reece Dunn Sent: Sunday, March 30, 2003 12:18 PM To: [EMAIL PROTECTED] Subject: [boost] (no subject) Thanks for repackaging the code inside zip, and for mor examples, and making it work 'strictly' MXVC 7.0 Level 4 NO language extensions with template typename CharT, class TraitsT, typename ForwardIterator inline std::basic_ostream CharT, TraitsT operator ( std::basic_ostream CharT, TraitsTos, formatlist_t ForwardIterator const fi ); I shall look at adding support for 2D or nD output, however, this was not in the initial design plans. As the name formatlist suggests, this was intended for list outputting (1D) only. For array and matrix, you might of course like to see the Boost contributions in array and UBLAS. But handling at least 2D and 3D C arrays is still acommon requirement. I was gauging interest before I worked on more complicated examples. As for documentation, I was looking at getting the design stabilized first, otherwise there may be problems synchronizing the documentation with the code. I have produced a more complicated set of examples that demonstrate the applicability of my formatlist manipulator. I have a few ideas on where I would like to take this: [1] I would like to parametize the seperator and open/close list types to a template type. This will allow the character type used by my current implementation, as well as a character array, std::string and possibly other types like wide characters. Some people are turned on by wide characters. [2] I have recently had a look at the I/O operationd for STL containers thread. Is there a way we can merge these two threads, or should they be kept seperate? There are similarities and differences to both approaches. Both are an attempt to solve a similar problem from different angles. The io_format approach is very nice - I like the way it hooks into the I/O stream state mechanism to make the usage for a type intuative; it does, however have a complex setup for each type on each output stream that uses that type. Also, what are the run-time overheads for the use of the xalloc mechanism, especially if a lot of different containers need to be outputted? My approach does not handle std::pair or nD object output, nor does it support seperators or list brackets that are wide characters or strings (although I am looking at generalizing this). The point of my version was to allow the output of a list specified between two iterators with a specialization for containers to save writing: std::formatlist( c.begin(), c.end()) every time you needed to output the entire container. I also wanted an implementation that has a small run-time overhead. I also note the complexity of the xalloc with some concern. The simplicity of formatlist is appealing. [3] Would it be possible to combine both approaches into a single library, where the user can choose which version to use: state objects (io_format); or manipulators (formatlist)? Sounds interesting. [4] I am intending on changing the stl namespace to something more appropriate. Any suggestions are welcome. Doubt that you should worry at present - boost\io\ may be suitable? Your new examples show how easy it is to use. 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: VC7/Threads Warnings /Wp64 flag(detect64-bitportability)
Thanks for all these nuggets of info on 64-bit. I find it hard enough to keep 32 bits in order ;-) (Old computers/programmers never die, they just lose control of their bits?) Paul PS Editing C:\Program Files\Microsoft Visual Studio .NET\Vc7\VCWizards\1033\common.js CLTool.WarningLevel = warningLevel_4; // was _3 CLTool.Detect64BitPortabilityProblems = false; // was true does the trick. Many thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Holger Grund Sent: Thursday, March 27, 2003 12:26 PM To: [EMAIL PROTECTED] Subject: [boost] Re: VC7/Threads Warnings /Wp64 flag (detect64-bitportability) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings /Wp64 flag (detect 64-bitportability)
You are probably right - but the tool tip display shows an __int64 which alerted me to this. For most purposes, I suspect this warning /Wp64 is not what most people want.(Or is it Boost policy that code should provide 64-bit portability? Premature?) If one writes: std::size_t s = 42; cout s endl; with MSVC7.0 default project settings for an empty console project on my 32-bit system /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /GS /Gy /FoRelease/ /FdRelease/vc70.pdb /W3 /nologo /c /Wp64 /Zi /TP it is confusing to get a warning: test_size_t.cpp(19) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data (I am unclear why there is a warning unless unsigned int is 32-bit and size_t is 64-bit. How is there a problem if both are 32 or 64?) If one changes to warning level 4/W4 and no test for 64 portability /Wp64 /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /GS /Gy /FoRelease/ /FdRelease/vc70.pdb /W4 /nologo /c /Zi /TP No warnings. And ideally request 'strict' - no extensions and for scope: /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /Za /Zc:forScope /FoRelease/ /FdRelease/vc70.pdb /W4 /nologo /c /Zi /TP Still no warnings. In my experience, carefully written code (which Boost code should be - and generally is) compiled with MSVC 7.0 and warnings at level 4 produces only a few warnings, and those can be individually supressed - and should be as a matter of good documentation. Paul PS Despite RTFM, I cannot see how to change the IDE _default_ solution/project settings. Suggestions? 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 Peter Dimov Sent: Wednesday, March 26, 2003 1:58 PM To: Boost mailing list Subject: Re: [boost] VC7/Threads Warnings Paul A. Bristow wrote: I was surprised to find that /Wp64 flag (detect 64-bit portability) means that std::size_t is 64 bit. This leds to a number of oddities that confused me. Is this perhaps causing your problem? std::size_t is still 32 bit, /Wp64 generates warnings if the meaning of the code could have changed had size_t been 64 bit. ___ 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: compare
This really neat, and useful, but I really don't like either name. Two suggestions: comparisons - because the whole point is more than one compare. or compair - because one is comparing pairs. (Do I hear you groan? Not punny?) But perhaps the dreadfulness will make is more memorable? 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] 2) I'm not sure that the choice of the name is ideal. OTOH, I can't think of a better one... lexicographic? This implies something to do with lexicons, which is too restrictive, and even misleading. 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] VC7/Threads Warnings
I was surprised to find that /Wp64 flag (detect 64-bit portability) means that std::size_t is 64 bit. This leds to a number of oddities that confused me. Is this perhaps causing your problem? 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 vc Sent: Tuesday, March 25, 2003 5:20 PM To: Boost mailing list Subject: Re: [boost] VC7/Threads Warnings - Original Message - From: William E. Kempf [EMAIL PROTECTED] Yes it seems that in command line by default is W1. If you set the /Wp64 flag (detect 64-bit portability) you will get warnings level 1 and they can be seen using bjam without setting the Wx flag. So, seems that W1 is by default ... Viv ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Determining interest in combining_iterator
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas Becker Sent: Monday, March 24, 2003 7:50 AM To: [EMAIL PROTECTED] Subject: [boost] Determining interest in combining_iterator This email is to determine possible interest in a submission to boost: the combining iterator. I can see this VERY useful to some, but probably not widely useful. 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
