[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [math] pow redux and observations
From:       John Maddock <jz.maddock () googlemail ! com>
Date:       2008-05-30 18:50:43
Message-ID: 00e501c8c286$14b9b460$0201a8c0 () fuji
[Download RAW message or body]

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]