Re: [math] pow redux and observations

Bruno Lalande wrote:
> As I said, what I'd like is to have a default behavior that returns 1.
> I thought I could use the already existing ignore_error policy but I
> realize its behavior is imposed by the framework. For domain_error,
> which is the policy that best fits the 0^0 case IMO, ignore_error
> returns quiet_NaN which is not what I want. I can't use a user_error
> either since it would force me to predefine the user_domain_error
> function, thus stealing this point of customization to the user. So
> I'm realizing I'll have to adapt the framework (that's probably what
> you meant the other day by "adding new policies", I didn't notice at
> that moment).
>
> I don't know Boost.Math policies very much but my understanding is
> that we don't need a new policy but just a new action type, that I
> could use to return 1. I see 2 possibilities: creating a brand new
> action type, or allowing the existing "ignore_error" action to take in
> its constructor the value that we want it to return in place of
> quiet_NaN.
>
> Or maybe you prefer to simply return quiet_NaN instead of 1? Note that
> it's not the behavior of the C pow function so it could be misleading
> for users.
>
> What do you think about that?

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?

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

On the other hand.... Googling around, it's clear that 0^0 has an 
indeterminant value, and C99 says of the pow function:

"A domain error occurs if x is finite and negative and y is finite and not 
an integer value. A domain error may occur if x is zero and y is less than 
or equal to zero."

However in the appendix under recomended practice it lists lots of special 
cases:

F.9.4.4 The pow functions
-pow(±0, y) returns ±¥ and raises the ''divide-by-zero'' floating-point 
exception
for y an odd integer < 0.
- pow(±0, y) returns +¥ and raises the ''divide-by-zero'' floating-point 
exception for y < 0 and not an odd integer.
- pow(±0, y) returns ±0 for y an odd integer > 0.
- pow(±0, y) returns +0 for y > 0 and not an odd integer.
- pow(-1, ±¥) returns 1.
- pow(+1, y) returns 1 for any y, even a NaN.
- pow(x, ±0) returns 1 for any x, even a NaN.
- pow(x, y) returns a NaN and raises the ''invalid'' floating-point 
exception for
finite x < 0 and finite non-integer y.
- pow(x, -¥) returns +¥ for | x | < 1.
- pow(x, -¥) returns +0 for | x | > 1.
- pow(x, +¥) returns +0 for | x | < 1.
- pow(x, +¥) returns +¥ for | x | > 1.
- pow(-¥, y) returns -0 for y an odd integer < 0.
- pow(-¥, y) returns +0 for y < 0 and not an odd integer.
- pow(-¥, y) returns -¥ for y an odd integer > 0.
- pow(-¥, y) returns +¥ for y > 0 and not an odd integer.
- pow(+¥, y) returns +0 for y < 0.
- pow(+¥, y) returns +¥ for y > 0.

Sorry about the mangled text: those funny symbols are infinities!

The key bit here is:

"- pow(x, ±0) returns 1 for any x, even a NaN."

So the result should be 1!

Personally I can't help wondering if they just overlooked the 0^0 case 

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.

?

Not sure if this helps, John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost