On 5/20/2005 2:26 PM, Tom Lane wrote:
numeric_power can in theory deliver an exact answer when the exponent is
a positive integer. Division can deliver an exact answer in some cases
too --- but the spec doesn't say it must do so when possible. So I
would say that there is no spec requirement f
Alvaro Herrera wrote:
> On Mon, May 30, 2005 at 11:29:48PM -0400, Bruce Momjian wrote:
>
> > test=> select 12345678901234567890 / 123;
> > ?column?
> >
> > 100371373180768845
> > (1 row)
>
> Well, that's a bug, right?
I don't think so. The fuller
On Mon, May 30, 2005 at 11:29:48PM -0400, Bruce Momjian wrote:
> test=> select 12345678901234567890 / 123;
> ?column?
>
>100371373180768845
> (1 row)
Well, that's a bug, right?
--
Alvaro Herrera ()
"Industry suffers from the managerial
Alvaro Herrera wrote:
> On Fri, May 20, 2005 at 01:03:08PM -0400, Tom Lane wrote:
>
> Oh, and while at it, it would be nice to solve the modulo bug that still
> lurks there:
>
> alvherre=# select 12345678901234567890 % 123;
> ?column?
> --
> -45
> (1 fila)
>
> alvherre=# select 12
Tom Lane wrote:
> Has anyone bothered to actually look into the code?
>
> regression=# select power(2::numeric,1000);
>
> power
> -
On Fri, May 20, 2005 at 01:03:08PM -0400, Tom Lane wrote:
> But having said that, I don't have a problem with putting in a
> pg_operator entry for numeric_power. And if someone wants to improve
> the scale factor calculations therein, go for it.
Oh, and while at it, it would be nice to solve the
On Fri, May 20, 2005 at 12:22:33PM -0500, Jim C. Nasby wrote:
> > which you could take as requiring us to provide numeric equivalents of
> > every floating-point operator, but I don't find that argument very
> > convincing for operations that are inherently not going to give exact
> > results. The
Claudio Succa <[EMAIL PROTECTED]> writes:
> With PostgreSQL 7.4.7 on Linux/Debian platform I had a different result so I
> made the subtraction of your figure:
> psql -h s1 -d rapp-test -c "select power(2::numeric,1000) -
I don't know what you're getting there, but there is no power() function
at
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> It's not only useless, it's dangerous. As fas as I know, numeric
> _guarantees_ the result of a operation to be correct to the last digit.
Nonsense ... see division. By your argument we should not implement
numeric / numeric.
On Fri, 2005-05-20 at 12:27, Florian G. Pflug wrote:
> Stephan Szabo wrote:
> > On Fri, 20 May 2005, John D. Burger wrote:
> >
> >
> >>I find all these statements about the near-uselessness of
> >>NUMERIC^NUMERIC to be pretty amazing. It's fine to say, "no one seems
> >>to be asking for this, so
Scott Marlowe <[EMAIL PROTECTED]> writes:
> Are you saying that the exponent operator will return inexact results?
For a fractional exponent, it generally has to, because there is no
finite exact result.
> If you're quoting the 92 spec, it seems to say that multiplication
> precision is also imp
On Fri, 2005-05-20 at 12:03, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Why are we allowing implicit casts from numeric to floating point?
>
> Because the SQL spec requires it.
>
> 2) If the data type of either operand of a dyadic arithmetic op-
> erator
Stephan Szabo wrote:
On Fri, 20 May 2005, John D. Burger wrote:
I find all these statements about the near-uselessness of
NUMERIC^NUMERIC to be pretty amazing. It's fine to say, "no one seems
to be asking for this, so we haven't implemented it yet", but, c'mon,
folks, Postgres gets used for more
On Fri, May 20, 2005 at 01:03:08PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Why are we allowing implicit casts from numeric to floating point?
>
> Because the SQL spec requires it.
>
> 2) If the data type of either operand of a dyadic arithmetic op-
>
17:28, venerdì 20 maggio 2005 - Tom Lane scrive:
|> Has anyone bothered to actually look into the code?
|>
|> regression=# select power(2::numeric,1000);
|>
|> power
|> --
Martijn van Oosterhout wrote:
On Thu, May 19, 2005 at 02:25:58PM -0700, Dann Corbit wrote:
Hmmm
I underestimated.
pow(9.9,9.9) =
Yeah, a number with x digits raised to the power with something y digits
long could have a length approximating:
x * (10^y) digits
So two numbers bot
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Why are we allowing implicit casts from numeric to floating point?
Because the SQL spec requires it.
2) If the data type of either operand of a dyadic arithmetic op-
erator is approximate numeric, then the data type of the re-
Why are we allowing implicit casts from numeric to floating point?
Doesn't that violate the principle of not doing any implicit casts that
would potentially drop precision? It seems that about half the arguments
here are related to getting unexpected or inaccurate results, presumably
from the impli
Stephan Szabo <[EMAIL PROTECTED]> writes:
> It also doesn't seem to work terribly well:
It's not terribly bright about figuring out how many significant digits
it should try to calculate, nor about how many it's actually got in the
result. Feel free to fix that ;-) I believe the numeric exp() an
That's because numerics default to 16 or something similar. If you want
more precision just explicitly cast it:
decibel=# select power(0.1::numeric(20,20),17);
0.1000
On Fri, May 20, 2005 at 09:30:16AM -0700, Stephan Szabo wrote:
>
> On Fri, 20 May 2005, Tom Lane wrote:
>
> > H
On Fri, 2005-05-20 at 11:16, Stephan Szabo wrote:
> On Fri, 20 May 2005, Scott Marlowe wrote:
>
> > 2: How many people who DO work with large exponents and need arbitrary
> > precision have looked at postgresql, typed in "select 3^100" got back
> > 5.15377520732011e+47, and simply went to anothe
On Fri, 2005-05-20 at 10:37, Bruce Momjian wrote:
> Scott Marlowe wrote:
> > I could be wrong, and would be unoffended to be proven so, but I don't
> > think I am. I think that argument is just hand waving.
> >
> > 2: How many people who DO work with large exponents and need arbitrary
> > precis
On Fri, 20 May 2005, Tom Lane wrote:
> Has anyone bothered to actually look into the code?
>
> regression=# select power(2::numeric,1000);
>
> power
> ---
On Fri, 20 May 2005, Scott Marlowe wrote:
> On Fri, 2005-05-20 at 09:06, Stephan Szabo wrote:
> > On Fri, 20 May 2005, John D. Burger wrote:
> >
> > > I find all these statements about the near-uselessness of
> > > NUMERIC^NUMERIC to be pretty amazing. It's fine to say, "no one seems
> > > to be
Scott Marlowe wrote:
> I could be wrong, and would be unoffended to be proven so, but I don't
> think I am. I think that argument is just hand waving.
>
> 2: How many people who DO work with large exponents and need arbitrary
> precision have looked at postgresql, typed in "select 3^100" got bac
Has anyone bothered to actually look into the code?
regression=# select power(2::numeric,1000);
power
-
On Fri, 2005-05-20 at 09:06, Stephan Szabo wrote:
> On Fri, 20 May 2005, John D. Burger wrote:
>
> > I find all these statements about the near-uselessness of
> > NUMERIC^NUMERIC to be pretty amazing. It's fine to say, "no one seems
> > to be asking for this, so we haven't implemented it yet", bu
On Fri, 20 May 2005, John D. Burger wrote:
> I find all these statements about the near-uselessness of
> NUMERIC^NUMERIC to be pretty amazing. It's fine to say, "no one seems
> to be asking for this, so we haven't implemented it yet", but, c'mon,
> folks, Postgres gets used for more than "busines
On Fri, May 20, 2005 at 08:19:58 -0400,
"John D. Burger" <[EMAIL PROTECTED]> wrote:
> I find all these statements about the near-uselessness of
> NUMERIC^NUMERIC to be pretty amazing. It's fine to say, "no one seems
> to be asking for this, so we haven't implemented it yet", but, c'mon,
> fol
I find all these statements about the near-uselessness of
NUMERIC^NUMERIC to be pretty amazing. It's fine to say, "no one seems
to be asking for this, so we haven't implemented it yet", but, c'mon,
folks, Postgres gets used for more than "business cases".
- John D. Burger
MITRE
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Probably, the important meaningful cases are ones that have small
> exponents (HOPEFULLY less than 25) used in interest calculations.
No, even in interest calculation floating point arithmetic is perfectly fine.
You do your floating point arithmetic to
, May 19, 2005 2:48 PM
> To: Dann Corbit
> Cc: Alvaro Herrera; John Burger; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] numeric precision when raising one numeric to
> another.
>
> On Thu, May 19, 2005 at 02:25:58PM -0700, Dann Corbit wrote:
> > Hmmm
> > I
ql.org
> Subject: Re: [GENERAL] numeric precision when raising one numeric to
> another.
>
> On Thu, May 19, 2005 at 02:25:58PM -0700, Dann Corbit wrote:
> > Hmmm
> > I underestimated.
> >
> > pow(9.9,9.9) =
>
> Yeah, a number with x d
On Thu, May 19, 2005 at 02:25:58PM -0700, Dann Corbit wrote:
> Hmmm
> I underestimated.
>
> pow(9.9,9.9) =
Yeah, a number with x digits raised to the power with something y digits
long could have a length approximating:
x * (10^y) digits
So two numbers both 4 digits long can
nal Message-
> From: Dann Corbit
> Sent: Thursday, May 19, 2005 2:20 PM
> To: 'Martijn van Oosterhout'
> Cc: Alvaro Herrera; John Burger; pgsql-general@postgresql.org
> Subject: RE: [GENERAL] numeric precision when raising one numeric to
> another.
>
> If you want t
numeric precision when raising one numeric to
> another.
>
> On Thu, May 19, 2005 at 10:41:51AM -0700, Dann Corbit wrote:
> > We use Moshier's excellent qfloat numbers.
> > http://www.moshier.net/qlib.zip
> > Documentation:
> > http://www.moshier.net/qlib
On Thu, May 19, 2005 at 10:41:51AM -0700, Dann Corbit wrote:
> We use Moshier's excellent qfloat numbers.
> http://www.moshier.net/qlib.zip
> Documentation:
> http://www.moshier.net/qlibdoc.html
>
> So, if you do the following query using CONNX:
> select convert(pow(9.5,5.9), varchar)
> You will g
ral@postgresql.org
> Subject: Re: [GENERAL] numeric precision when raising one numeric to
> another.
>
> On Wed, May 18, 2005 at 11:32:40PM -0400, Alvaro Herrera wrote:
> > On Wed, May 18, 2005 at 10:46:50PM -0400, John Burger wrote:
> > > For one thing. For another, I
n Burger
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] numeric precision when raising one numeric to
> another.
>
> On Wed, May 18, 2005 at 10:46:50PM -0400, John Burger wrote:
> > >>Considering that the SQL spec says the result of multiplication of
> &g
On Wed, May 18, 2005 at 11:32:40PM -0400, Alvaro Herrera wrote:
> On Wed, May 18, 2005 at 10:46:50PM -0400, John Burger wrote:
> > For one thing. For another, I believe the standard C library only has
> > floating point exponentiation functions, not that there aren't plenty
> > of numeric librar
On Wed, May 18, 2005 at 10:46:50PM -0400, John Burger wrote:
> >>Considering that the SQL spec says the result of multiplication of
> >>exact
> >>numeric types is exact numeric types of precision S1+S2, and
> >>exponentiation is nothing more than repeated multiplication,
> >
> >... not when the ex
Considering that the SQL spec says the result of multiplication of
exact
numeric types is exact numeric types of precision S1+S2, and
exponentiation is nothing more than repeated multiplication,
... not when the exponent is non-integral.
For one thing. For another, I believe the standard C librar
Scott Marlowe <[EMAIL PROTECTED]> writes:
> Considering that the SQL spec says the result of multiplication of exact
> numeric types is exact numeric types of precision S1+S2, and
> exponentiation is nothing more than repeated multiplication,
... not when the exponent is non-integral.
On Wed, 2005-05-18 at 16:42, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > It appears from checking the output of exponentiation of one numeric to
> > another, the output is actually in floating point. Is this normal and /
> > or expected?
>
> Yes, seeing that the only ^ operato
Scott Marlowe <[EMAIL PROTECTED]> writes:
> It appears from checking the output of exponentiation of one numeric to
> another, the output is actually in floating point. Is this normal and /
> or expected?
Yes, seeing that the only ^ operator we have is float8.
regression=# \do ^
45 matches
Mail list logo
