NUMERIC's transcendental functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: NUMERIC's transcendental functions
Date: 2002-09-21 16:01:28
Message-ID: 9416.1032624088@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I have noticed a change in behavior following the recent changes for
casting of numeric constants. In prior releases, we got

regression=# select log(10.1);
log
------------------
1.00432137378264
(1 row)

CVS tip gives

regression=# select log(10.1);
log
--------------
1.0043213738
(1 row)

The reason for the change is that 10.1 used to be implicitly typed as
float8, but now it's typed as numeric, so this command invokes
log(numeric) instead of log(float8). And log(numeric)'s idea of
adequate output precision seems low.

Similar problems occur with sqrt(), exp(), ln(), pow().

I realize that there's a certain amount of cuteness in being able to
calculate these functions to arbitrary precision, but this is a database
not a replacement for bc(1). ISTM the numeric datatype is intended for
exact calculations, and so transcendental functions (which inherently
have inexact results) don't belong.

So proposal #1 is to rip out the numeric versions of these functions.

If you're too attached to them, proposal #2 is to force them to
calculate at least 16 digits of output, so that we aren't losing any
accuracy compared to prior behavior.

Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2002-09-21 18:38:08 Re: Inconsistent Conversion Names
Previous Message Tom Lane 2002-09-21 15:13:44 Re: Hosed PostGreSQL Installation