Re: NUMERIC's transcendental functions

Tom Lane wrote:
>
> 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?

One problem is, that division already has an inherently inexact
result. Do you intend to rip that out too while at it? (Just
kidding)

Proposal #2.667 would be to have a GUC variable for the default
precision.

Jan

>
> regards, tom lane

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being
right. #
# Let's break this rule - forgive
me. #
#==================================================
JanWieck(at)Yahoo(dot)com #