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. # #================================================== [EMAIL PROTECTED] # ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org