|
Boost : |
From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-06-11 02:40:47
(Sorry for the first post, hit the wrong button)
Paul A. Bristow wrote:
>
> 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?
I think that most people are able to look up pi (and any other constant)
on the internet if they need more precision. 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;
}
};
> |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.
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?
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: 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