Boost logo

Boost :

From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-05-27 07:19:15


> I don't like the idea of returning a NaN: returning 1 seems to be the right
> thing to do, and should probably be the default behaviour? The other
> problem with reusing a domain_error is that the default behaviour is to
> throw an exception, which may not be what users expect for this corner case?

Originally I wanted to bypass that default behavior by having the
second overload of pow calling the first one with a precise policy
rather than just policy<>(). But this may not be a good approach
(users could be surprised to not have the same result by calling
pow<N>(x) than by calling pow<N>(x, policy<>()) ).

> So I guess I'm leaning towards yet-another error-action, "zero_power_error"
> maybe?

Are you talking about an action or a policy? If it's an action, having
an action dedicated to this case is weird since it won't apply to
anything else than a domain_error (if we finally use that). If it's a
policy, having a policy dedicated to one single function of the
library sounds bad to me too. Why not be more general and call it
"undetermined_result_error" or something else that doesn't interfere
with any other policy and could eventually apply to more situations?

> <snip>
>
> Personally I can't help wondering if they just overlooked the 0^0 case :-(

Indeed they seem to contradict themselves a bit...

> Grrr, still not sure what to do here, how about:
>
> * If the domain_error action is "ignore_error" then return 1, otherwise,
> * Raise a domain_error as normal.

I had thought about this solution but didn't know 1) if the framework
allows this kind of test easily and safely, and 2) if it doesn't break
the general philosophy of policies in Boost.Math (a bit like doing
type testing in OO). But if you think it's possible, why not...

I'm like you, really not sure of what to do... I'll continue to think
about all that.

Bruno


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk