bug in numeric_power() function
I expected 0 ^ 123.3 to be 0, but it reported error as follows
postgres=# select 0 ^ 123.3;
ERROR: cannot take logarithm of zero
I find that there is a bug in numeric_power() function
the function caculates a ^ b based on the algorithm e ^ (lna * b)
as you see, ln0 is not valid
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
owner@postgresql.org] On Behalf Of Richard Wang
Sent: Tuesday, March 11, 2008 7:38 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] bug in numeric_power() functionI expected 0 ^ 123.3 to be 0, but it reported error as follows
postgres=# select 0 ^ 123.3;
ERROR: cannot take logarithm of zeroI find that there is a bug in numeric_power() function
the function caculates a ^ b based on the algorithm e ^ (lna * b)
as you see, ln0 is not valid
It seems an obvious work-around that:
if (b == 0) return 1;
if (a == 0) return 0;
could be inserted at the top.
Aside:
Having the ^ operator overloaded for exponentiation surprises me.
Does it really have the right precedence for performing exponentiation?
(E.g. you cannot do this in C++ because ^ will have the precedence of
xor, which is wrong).
"Richard Wang" <ruc_wang@hotmail.com> writes:
I expected 0 ^ 123.3 to be 0, but it reported error as follows
postgres=# select 0 ^ 123.3;
ERROR: cannot take logarithm of zero
Hmm, seems like the numeric and float8 power operators don't agree
about 0^0 either...
regards, tom lane
I also have a question here:
isn't dpow enough for calculation?
Why added numeric_power?
"Tom Lane" <tgl@sss.pgh.pa.us> д����Ϣ����:12538.1205298992@sss.pgh.pa.us...
Show quoted text
"Richard Wang" <ruc_wang@hotmail.com> writes:
I expected 0 ^ 123.3 to be 0, but it reported error as follows
postgres=# select 0 ^ 123.3;
ERROR: cannot take logarithm of zeroHmm, seems like the numeric and float8 power operators don't agree
about 0^0 either...regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Richard Wang wrote:
I expected 0 ^ 123.3 to be 0, but it reported error as follows
postgres=# select 0 ^ 123.3;
ERROR: cannot take logarithm of zeroI find that there is a bug in numeric_power() function
the function caculates a ^ b based on the algorithm e ^ (lna * b)
as you see, ln0 is not valid
I have developed the attached patch which fixes 0 ^ 123.3. It also
fixes the case for 0 ^ 0.0 so it returns 1 instead of an error --- see
the C comment for why one is the proper return value. float pow()
already returned one in this case:
test=> select 0 ^ 0;
?column?
----------
1
(1 row)
test=> select 0 ^ 0.0;
?column?
----------
1
(1 row)
test=> select 0 ^ 3.4;
?column?
----------
1
(1 row)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/pgpatches/powertext/x-diffDownload
Index: src/backend/utils/adt/numeric.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/numeric.c,v
retrieving revision 1.110
diff -c -c -r1.110 numeric.c
*** src/backend/utils/adt/numeric.c 21 Apr 2008 00:26:45 -0000 1.110
--- src/backend/utils/adt/numeric.c 7 May 2008 20:05:01 -0000
***************
*** 5170,5175 ****
--- 5170,5187 ----
int local_rscale;
double val;
+ /*
+ * This avoids log(0) for cases of 0 raised to a non-integer.
+ * We also treat 0 ^ 0 == 1 because it is the best value for discrete
+ * mathematics, and most programming languages do this.
+ * http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power
+ */
+ if (cmp_var(base, &const_zero) == 0)
+ {
+ set_var_from_var(&const_one, result);
+ return;
+ }
+
/* If exp can be represented as an integer, use power_var_int */
if (exp->ndigits == 0 || exp->ndigits <= exp->weight + 1)
{
***************
*** 5266,5280 ****
NumericVar base_prod;
int local_rscale;
- /* Detect some special cases, particularly 0^0. */
-
switch (exp)
{
case 0:
- if (base->ndigits == 0)
- ereport(ERROR,
- (errcode(ERRCODE_FLOATING_POINT_EXCEPTION),
- errmsg("zero raised to zero is undefined")));
set_var_from_var(&const_one, result);
result->dscale = rscale; /* no need to round */
return;
--- 5278,5286 ----
Bruce Momjian <bruce@momjian.us> writes:
I have developed the attached patch which fixes 0 ^ 123.3.
Did you actually read the wikipedia entry you cited?
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I have developed the attached patch which fixes 0 ^ 123.3.
Did you actually read the wikipedia entry you cited?
Considering that 0::float8 ^ 0::float8 yields 1, making the numeric operator
do the same might not be completely unreasonable, but I find the rationale
that it is better for discrete mathematics fairly ludicrous on multiple
levels.
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I have developed the attached patch which fixes 0 ^ 123.3.
Did you actually read the wikipedia entry you cited?
Yes:
The evaluation of 0^0 presents a problem, because different mathematical
reasoning leads to different results. The best choice for its value
depends on the context. According to Benson (1999), "The choice whether
to define 00 is based on convenience, not on correctness."[2] There are
two principal treatments in practice, one from discrete mathematics and
the other from analysis.
...
The computer programming languages that evaluate 00 to be 1[8] include
J, Java, Python, Ruby, Haskell, ML, Scheme, MATLAB, bc, R programming
language, and Microsoft Windows' Calculator.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I have developed the attached patch which fixes 0 ^ 123.3.
Did you actually read the wikipedia entry you cited?
But that's about 0^0, not about 0^123.3. See this other subsection:
http://en.wikipedia.org/wiki/Exponentiation#Powers_of_zero
0^123.3 is 0, not 1.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I have developed the attached patch which fixes 0 ^ 123.3.
Did you actually read the wikipedia entry you cited?
But that's about 0^0, not about 0^123.3. See this other subsection:
http://en.wikipedia.org/wiki/Exponentiation#Powers_of_zero
0^123.3 is 0, not 1.
Ah, got it, and I updated the patch to remove the commment about
"discrete".
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/pgpatches/powertext/x-diffDownload
Index: src/backend/utils/adt/numeric.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/numeric.c,v
retrieving revision 1.110
diff -c -c -r1.110 numeric.c
*** src/backend/utils/adt/numeric.c 21 Apr 2008 00:26:45 -0000 1.110
--- src/backend/utils/adt/numeric.c 7 May 2008 23:18:31 -0000
***************
*** 5170,5175 ****
--- 5170,5190 ----
int local_rscale;
double val;
+ /*
+ * This avoids log(0) for cases of 0 raised to a non-integer.
+ * Also, while 0 ^ 0 can be either 1 or indeterminate (error), we
+ * treat it as one because most programming languages do this.
+ * http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power
+ */
+ if (cmp_var(base, &const_zero) == 0)
+ {
+ if (cmp_var(exp, &const_zero) == 0)
+ set_var_from_var(&const_one, result);
+ else
+ set_var_from_var(&const_zero, result);
+ return;
+ }
+
/* If exp can be represented as an integer, use power_var_int */
if (exp->ndigits == 0 || exp->ndigits <= exp->weight + 1)
{
***************
*** 5266,5280 ****
NumericVar base_prod;
int local_rscale;
- /* Detect some special cases, particularly 0^0. */
-
switch (exp)
{
case 0:
- if (base->ndigits == 0)
- ereport(ERROR,
- (errcode(ERRCODE_FLOATING_POINT_EXCEPTION),
- errmsg("zero raised to zero is undefined")));
set_var_from_var(&const_one, result);
result->dscale = rscale; /* no need to round */
return;
--- 5281,5289 ----
Bruce Momjian wrote:
Ah, got it, and I updated the patch to remove the commment about
"discrete".
The page also says that 0^x is undefined when x is negative, not sure
about that one but I don't see it in your patch.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
Bruce Momjian wrote:
Ah, got it, and I updated the patch to remove the commment about
"discrete".The page also says that 0^x is undefined when x is negative, not sure
about that one but I don't see it in your patch.
That one was already handled:
test=> select 0 ^ -1;
ERROR: invalid argument for power function
test=> select 0 ^ -1.0;
ERROR: invalid argument for power function
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Applied.
---------------------------------------------------------------------------
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I have developed the attached patch which fixes 0 ^ 123.3.
Did you actually read the wikipedia entry you cited?
But that's about 0^0, not about 0^123.3. See this other subsection:
http://en.wikipedia.org/wiki/Exponentiation#Powers_of_zero
0^123.3 is 0, not 1.
Ah, got it, and I updated the patch to remove the commment about
"discrete".--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +