Re: [boost] Compile-time power of a run-time base

From: John Maddock (john_at_[hidden])
Date: 2008-02-22 04:43:28

Bruno Lalande wrote:
>> Hello,
>>
>> Here is the documentation updated regarding the requests made above.
>> Error handling customization is now explained with an example. I
>> describe a call with a user_error policy, and also the use of the
>> BOOST_MATH_OVERFLOW_ERROR_POLICY macro. However, I don't show any
>> example of use of a try/catch block with the default call, because
>> using try/catch is a widely known C++ practice so I assume that the
>> user knows what he has to do when I say "by default a
>> std::overflow_error is thrown". Do you think such a trivial example
>> should be present anyway?
>>
>> By the way, there is a slight error in this page:
>> http://svn.boost.org/svn/boost/trunk/libs/math/doc/sf_and_dist/html/math_toolkit/policy/pol_tutorial/user_def_err_pol.html
>> The first line of the first code section opens the namespace "policy"
>> instead of "policies".

Oops, fixed in SVN, thanks for spotting that.

>> Let me know if there's anything to modify again.

In:

* `errno_on_error`: Sets `::errno`  to `EDOM and` returns 
`std::numeric_limits<T>::quiet_NaN()`.
* `ignore_error`: Returns `std::numeric_limits<T>::quiet_NaN()`.

Actually an overflow error returns *infinity* not NaN.

And in:

    namespace boost { namespace math { namespace policies {
    template <class T>
    T user_overflow_error(const char*, const char*, const T&)
    { return 123.456; }
    }}}

You later check for -1 as a result, so should this be returning -1?

And in:

    // Redefine the default error_overflow policy

    #define BOOST_MATH_OVERFLOW_ERROR_POLICY errno_on_error

    // From this point, passing a policy in argument is no longer needed, a 
call like this one
    // will return -1 in case of error:

    double result = pow<-5>(base);

No not -1, but infinity (again) :-)

I'd be inclined to place the synopsis at the top of the file: that way those 
already comfortable with the library can just get stuck right in without 
having to re-read the tutorial :-)

"Joaquín López Muñoz" appears mangled in my version: this might be safer 
encoded using XML escape sequences rather than UTF8?

>> What about the possibility of allowing a return type compatible with
>> Boost.Units and/or possibly integral ? I see 3 solutions:
>> - a return type policy in second template argument (with the current
>> one as default)
>> - a completely different function name
>> - nothing at all (stick to the standard and nothing else)

Well.... for Boost.Math I'd be happy with it as it is.... I'm assuming that 
the units folks can provide an overload looking something like:

template <int p, class Unit, class Y>
inline computed-result-type pow(const quantity<Unit,Y>& u)
{
   typedef computed-result-type result_type;
   return result_type(boost::math::pow<p>(u.value()));
}

????

John.