pgsql: Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^

Log Message:
-----------
Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^ 0.0
return 1, rather than error.

This was already the float8 behavior.

Modified Files:
--------------
pgsql/src/backend/utils/adt:
numeric.c (r1.110 -> r1.111)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/numeric.c?r1=1.110&r2=1.111)

On Thu, 2008-05-08 at 19:25 +0000, Bruce Momjian wrote:
> Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^ 0.0
> return 1, rather than error.

A regression test for this behavior would be useful, I think.

-Neil

Neil Conway wrote:
> On Thu, 2008-05-08 at 19:25 +0000, Bruce Momjian wrote:
> > Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^ 0.0
> > return 1, rather than error.
>
> A regression test for this behavior would be useful, I think.

Done, plus I wasn't happy with the original patch so I redid it to be
more modular, also attached.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

momjian(at)postgresql(dot)org (Bruce Momjian) writes:
> Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^ 0.0
> return 1, rather than error.

This is wrongly described, and the implementation is still not correct
either, because it should throw an error for negative exponents.
Would you please *read* that wikipedia page you keep citing?
http://en.wikipedia.org/wiki/Exponentiation#Powers_of_zero

regards, tom lane

Tom Lane wrote:
> momjian(at)postgresql(dot)org (Bruce Momjian) writes:
> > Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^ 0.0
> > return 1, rather than error.
>
> This is wrongly described, and the implementation is still not correct
> either, because it should throw an error for negative exponents.
> Would you please *read* that wikipedia page you keep citing?
> http://en.wikipedia.org/wiki/Exponentiation#Powers_of_zero

I think this is fixed in the version I just committed:

test=> select 0 ^ (-1);
ERROR: invalid argument for power function
test=> select 0 ^ (-1.0);
ERROR: invalid argument for power function

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Thu, 2008-05-08 at 18:34 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > momjian(at)postgresql(dot)org (Bruce Momjian) writes:
> > > Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^ 0.0
> > > return 1, rather than error.
> >
> > This is wrongly described, and the implementation is still not correct
> > either, because it should throw an error for negative exponents.
> > Would you please *read* that wikipedia page you keep citing?
> > http://en.wikipedia.org/wiki/Exponentiation#Powers_of_zero
>
> I think this is fixed in the version I just committed:
>
> test=> select 0 ^ (-1);
> ERROR: invalid argument for power function
> test=> select 0 ^ (-1.0);
> ERROR: invalid argument for power function

Hopefully this only occurs for 0 ^ (n)? A negative exponent isn't a
problem for y ^ x when y <> 0 and x < 0. Just checking you don't just
throw out an error for any negative exponent, which is what "invalid
argument" sounds like, to me.

Wikipedia says that exponentiation of zero to a negative power implies
division by zero, so shouldn't we throw a "division by zero" error?

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Wikipedia says that exponentiation of zero to a negative power implies
> division by zero, so shouldn't we throw a "division by zero" error?

I think it should be a specific message like "zero raised to a negative
power is undefined". It's not like it's going to take us any extra code
to know that we are faced with that case.

BTW, I realized that SQL:2003 spells it all out for us in explicit
detail:

12)If <power function> is specified, then let NVEB be the <numeric value
expression base>, then let VB be the value of NVEB, let NVEE be the
<numeric value expression exponent>, and let VE be the value of NVEE.

Case:

a) If either VB or VE is the null value, then the result is the null value.

b) If VB is 0 (zero) and VE is negative, then an exception condition is
raised: data exception invalid argument for power function.

c) If VB is 0 (zero) and VE is 0 (zero), then the result is 1 (one).

d) If VB is 0 (zero) and VE is positive, then the result is 0 (zero).

e) If VB is negative and VE is not equal to an exact numeric value with
scale 0 (zero), then an exception condition is raised: data exception
invalid argument for power function.

f) If VB is negative and VE is equal to an exact numeric value with
scale 0 (zero) that is an even number, then the result is the result of
EXP(NVEE*LN(-NVEB))

g) If VB is negative and VE is equal to an exact numeric value with
scale 0 (zero) that is an odd number, then the result is the result of
-EXP(NVEE*LN(-NVEB))

h) Otherwise, the result is the result of
EXP(NVEE*LN(NVEB))

regards, tom lane

Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Wikipedia says that exponentiation of zero to a negative power implies
> > division by zero, so shouldn't we throw a "division by zero" error?
>
> I think it should be a specific message like "zero raised to a negative
> power is undefined". It's not like it's going to take us any extra code
> to know that we are faced with that case.
>
> BTW, I realized that SQL:2003 spells it all out for us in explicit
> detail:

...

> b) If VB is 0 (zero) and VE is negative, then an exception condition is
> raised: data exception invalid argument for power function.

Well, this indicates we shouldn't return "zero raised to a negative
power is undefined", but rather the power error we are giving now, or
are you saying we should return the "power" error code but an error
message mentioning zero?

> c) If VB is 0 (zero) and VE is 0 (zero), then the result is 1 (one).

I have updated the C comments to mention the spec also requires we
return 1 in this case.

C comment updated attached and applied.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> b) If VB is 0 (zero) and VE is negative, then an exception condition is
>> raised: data exception invalid argument for power function.

> Well, this indicates we shouldn't return "zero raised to a negative
> power is undefined", but rather the power error we are giving now, or
> are you saying we should return the "power" error code but an error
> message mentioning zero?

The spec says what the SQLSTATE code should be. We have always felt
free to word the message text more specifically than that, though.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> >> b) If VB is 0 (zero) and VE is negative, then an exception condition is
> >> raised: data exception invalid argument for power function.
>
> > Well, this indicates we shouldn't return "zero raised to a negative
> > power is undefined", but rather the power error we are giving now, or
> > are you saying we should return the "power" error code but an error
> > message mentioning zero?
>
> The spec says what the SQLSTATE code should be. We have always felt
> free to word the message text more specifically than that, though.

OK, I will work on it then.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> >> b) If VB is 0 (zero) and VE is negative, then an exception condition is
> >> raised: data exception invalid argument for power function.
>
> > Well, this indicates we shouldn't return "zero raised to a negative
> > power is undefined", but rather the power error we are giving now, or
> > are you saying we should return the "power" error code but an error
> > message mentioning zero?
>
> The spec says what the SQLSTATE code should be. We have always felt
> free to word the message text more specifically than that, though.

OK, error wording updated, attached, and applied.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +