
Boost : 
From: Daniel Frey (daniel.frey_at_[hidden])
Date: 20031211 08:33:06
Guillaume Melquiond wrote:
Thanks for your feedback!
> Le lun 08/12/2003 à 23:10, Daniel Frey a écrit :
>
> My question may seem a bit dumb, but I don't see the relation between
> this constant library and the interval library. Does the constant
> library provide anything at all to help with interval arithmetic?
No, it's just that constant intervals don't need a different syntax. Of
course intervals are different beasts than normal constants and the
std::complexexample can't be transfered.
> If I understand correctly your example with pi and std::complex, you get
> a complex<T> pi by using the T version of pi and then implicitly
> converting it to std::complex<T>. Is this the correct use of the
> mappers?
Yes.
> If it is, it can't be used to automatically create interval versions of
> the constants. The reason is: if you want an enclosing interval for a
> given type, you can't use an implicit conversion (because you don't have
> any information on the precision of the constant).
Correct, but mappers are not the universal onesizefitsall solution to
every problem. You will need to define constants for the base types you
want explicitly because there is no other way to be efficient and
precise AFAICS.
> For example the definition of an interval<float> pi constant would still
> need to be explicit, something like:
>
> static const float pi_f_l = 13176794.0f/(1<<22);
> static const float pi_f_u = 13176795.0f/(1<<22);
> template< typename T >
> struct pi_value : constant_value< pi_value, T > {};
> template< typename Policies >
> struct pi_value< boost::numeric::interval< float, Policies > > {
> typedef boost::numeric::interval< float, Policies > I;
> I operator()() const { return I(pi_f_l, pi_f_u); }
> };
>
> So, is there anything I'm missing?
No, your example above is correct. The point is, that the user can still
use the same 'pi' and generic algorithms can now work with intervals,
too. This facility of allowing to combine the same constants with as
much types as possible is IMHO an essential featured required for
generic programming. And it's important that the framework doesn't
require those specializations inside the framework itself, you can add
them to your my_constants.hpp (as in the .tgz) to adapt the constants to
your needs. Of course we can provide convenienceincludes for
std::complex or boost::numeric::interval if there is enough interest, so
users only put together the ingredients they need:
#include <boost/constant.hpp> // Basic stuff
#include <boost/math/constant/buildin.hpp> // 'pi', 'e' for buildin's
#include <boost/math/constant/complex.hpp> // Support for std::complex
#include <boost/math/constant/interval.hpp> // Support for interval lib
// You get the idea...
It's important that the code never include <complex> or
<boost/numeric/interval.hpp> if you don't need/want it!
> PS: There is one feature of your library that I find very interesting,
> it's what you call "combined constants". I didn't try it, but it seems
> that if the program was "interval<float> a = pi * pi;", the
> corresponding constant (and the subterms) would automatically be of the
> good type. And consequently the obtained interval would really enclose
> pi^2.
Indeed. The main problem I was trying to solve is, that pi2 or pi_sqared
or whatever is a nonintuitive name, at least to me. In the code, I
referred to this as the "naming dilemma", with the above proposed
solution. This also opens the framework for domain specific
optimizations. If you often need pi*pi*pi*pi*pi, you can make this an
efficient and precise constant, too, without the need to change your
code. All you need is a small addition to your project's
my_constants.hpp. I think that most these things are nonobvious and
need some documentation, but I also noticed that you found out a lot of
the code's potential on your own. This makes me happy as I feared that
the code is probably a bit too confusing without the docs... :)
Regards, Daniel
 Daniel Frey aixigo AG  financial solutions & technology SchloßRaheStraße 15, 52072 Aachen, Germany fon: +49 (0)241 93673742, fax: +49 (0)241 93673799 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk