Subject: Re: [boost] [complex] Feedback and Potential Review Manager
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-05-06 09:37:15
>> I implemented this but it seems to add limitations on the
>> types usable. They now require to have an overloaded
>> istream extraction operator and a specialization of
>> std::numeric_limits. Those two limitations are reasonable
>> but I am not certain that we want to impose such conditions
>> on the template types.
> The requirements are more subtle than that, the logic goes
> something like this:
> * If there's a numeric_limits specialization:
> * If the precision is less than a float/double/long double,
> and T is constructible from those types, then construct
> from float/double/long double.
> * If the precision is < 100 decimal places:
> * If T is constructible from a const char* then construct
> the constant that way.
> * Use the iostream operator to stream the constant in
> (we could arguably use a trait to check whether this
> is supported before using it as well).
> * Precision > 100 digits - calculate the constant and
> cache the result.
> * No numeric_limits - use boost::math::tools::digits<T>() to
> check runtime precision and pick either construct-from
> string or calculate the constant.
> There's also a trait class that can be specialized for some type T
> to override the above logic.
> So you don't have to have either numeric_limits or an
> iostream operator, but you have to have *something*
> that allows us to get the constant in there.
> HTH, John.
Thank you, John.
But I believe that this refinement of boost::math::constants
is only available in the trunk. So if you would like to
take advantage of this policy on mathematical constants,
you have to test your <boost/math/complex/complex.hpp>
with-respect-to the trunk. Otherwise, you need to make a
workaround via providing your own template specializations
of pi(), ln2(), ln_10() for now. This is what I did in my code
from yesterday for my fixed-point class.
Best regards, Chris.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk