Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-08 Thread Bruce Momjian 

Applied.

---

Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Bruce Momjian <[EMAIL PROTECTED]> 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  <[EMAIL PROTECTED]>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  <[EMAIL PROTECTED]>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

Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-07 Thread Bruce Momjian 
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  <[EMAIL PROTECTED]>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

Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-07 Thread Alvaro Herrera 
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 Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-07 Thread Bruce Momjian 
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> 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  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
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 -	1.110
--- src/backend/utils/adt/numeric.c	7 May 2008 23:18:31 -
***
*** 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 

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-07 Thread Alvaro Herrera 
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> 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 Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-07 Thread Bruce Momjian 
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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  <[EMAIL PROTECTED]>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

Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-07 Thread Peter Eisentraut 
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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.

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-07 Thread Tom Lane 
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have developed the attached patch which fixes 0 ^ 123.3.

Did you actually read the wikipedia entry you cited?

regards, tom lane

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] bug in numeric_power() function

2008-05-07 Thread Bruce Momjian 
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 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 

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  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
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 -	1.110
--- src/backend/utils/adt/numeric.c	7 May 2008 20:05:01 -
***
*** 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 

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches