Boost logo

Boost :

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-06-10 10:50:51

Reece Dunn wrote:
> Daniel Frey wrote:
>> // And their relationship:
>> // The user can now write 'pi / two' and needn't remember
>> // whether it was 'half_pi' or 'pi_by_2' or whatever...
>> half_pi_t operator/( const pi_t&, const two_t& ) { return
>> half_pi_t(); }
>> minus_one_t operator-( const one_t& ) { return minus_one_t(); }
>> one_t operator-( const minus_one_t& ) { return one_t(); }
>> one_t sin( const half_pi_t& ) { return one_t(); }
> This is a very powerful concept, allowing the compiler to simplify
> certain expressions.

Well, I also thought about this, but it would be an enourmous effort to
provide the needed specializations. I had a bunch of more than 40 and no
end at sight. I think that this should not be part of a constant
framework. The idea was just to provide an easy way to let users
remember the name of certain constants. The example was pretty useless
as I would expect the programmer to find out that sin(pi/two) is 1. It's
more useful when you would like to provide predefined (precalculated)
special values like sqrt(two) or sin(e) or something.

> [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>

(This is basically the same idea as used for new types, but this times
with another intermediate layer to allow the user to overwrite
"existing" specializations).

> [4] Other types beyond real numbers should be supportable within the
> constant framework (intervals, matrices, complex numbers, etc), e.g.
> matrix2x2 identity( 1, 0, 0, 1 );

I agree. One question comes to mind: Should we provide additive_identity
and multiplicative_identity as constants? Or is this always equivalent
to zero and one? Or are other names more appropriate? I don't know a
good answer as I have no use-case for it, but maybe someone else has... :)

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: daniel.frey_at_[hidden], web:

Boost list run by bdawes at, gregod at, cpdaniel at, john at