SAKAIDA Masaaki wrote:
> There are no problem concerning the NUMERIC test of INSERT/
> SELECT and add/subtract/multiply/division. The only problem is
> the processing time.
>
> One solution which solves this problem is to change the argument
> into *float8*. If the following changes are done, the processing
> will become high-speed than a previous about 10 times.
>
> File :"src/regress/sql/numeric.sql"
> Statement:"INSERT INTO num_result SELECT id, 0,
> POWER('10'::numeric,LN(ABS(round(val,300))) ..."
>
> Change: "LN(ABS(round(val,300))))"
> to: "LN(float8(ABS(round(va,300))))"
>
>
>
> # Another solution is to automatically convert the argument of the
> LOG function into double precision data type in the *inside*.
> (But, I do not know what kind of effect will be caused by this
> solution.)
The complex functions (LN, LOG, EXP, etc.) where added to
NUMERIC for the case someone really needs higher precision
than float8. The numeric_big test simply ensures that
someone really get's the CORRECT result when computing a
logarithm up to hundreds of digits. All the expected results
fed into the tables are computed by scripts using bc(1) with
a precision 200 digits higher than that used in the test
itself. So I'm pretty sure NUMERIC returns a VERY GOOD
approximation if I ask for the square root of 2 with 1000
digits.
One thing in mathematics that is silently forbidden is to
present a result with digits that aren't significant! But it
is the user to decide where the significance of his INPUT
ends, not the database. So it is up to the user to decide
when to loose precision by switching to float.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
