Bruno Lalande wrote:
Hi John,
First of all: I'd like to ensure you had my response of may 27, since the mail system sent me today a notification saying it couldn't be delivered...?? When I search on Gmane I can see it so I think it's OK though...
Yep.
So finally, I think the best way is to create a new error. There are 2 options: either we call it zero_power_error and it's bound to be only used in pow, or we call it undetermined_result_error so that it can be eventually reused later for something else. The default policy for this error will be ignore_error. If we choose "zero_power_error", the result in case of ignore_error will be 1. If we choose "undetermined_result_error", the best way is to make the result depend on the function where it's used. In this case, the raise_undetermined_result_error will have to take that value in parameter. For example, in pow:
return policies::raise_undetermined_result_error<T>( "boost::math::pow(%1%)", "The result of pow<0>(%1%) is undetermined", base, T(1), // value to return in case of ignore_error policy );
Which of the 2 options do you prefer?
Generally I prefer generic rather than specific solutions, so I guess I'd go for the latter - but would it be better called "indeterminate_result_error" ?
For the throw_on_error policy, do you see any existing exception (std or boost) that could fit or is it better to create a new one?
Not sure, the only obvious one is domain_error. Otherwise we're left to deriving a new exception type: would this gain us anything - storing the return value maybe?
For the errno_on_error policy, how about setting errno to EDOM and returning a NaN?
Yep, that's sensible, although should we return the value passed to the function: that would be consistent with C99: return 1 but optionally set errno as well. Cheers, John.