[boost] Re: [constant] Milestone 2 of the constant library added to filessection

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-12-11 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::complex-example 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 one-size-fits-all 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 convenience-includes 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 build-in'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 non-intuitive 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 non-obvious 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ß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de