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: [EMAIL PROTECTED], web: http://www.aixigo.de
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
