Regression error on float8

"Magnus Hagander" <mha@sollentuna.net> writes:

I'm getting the following regression errors with a backend built using
Visual C++:

Is HAVE_CBRT getting defined? Either their cbrt() routine or our
default one seems to be generating slightly-off answers. The default
one (at the bottom of float.c) certainly looks a bit cheesy, but if it
fails this test you'd think we'd have heard about that sooner.

regards, tom lane

I'm getting the following regression errors with a backend

built using

Visual C++:

Is HAVE_CBRT getting defined? Either their cbrt() routine or
our default one seems to be generating slightly-off answers.
The default one (at the bottom of float.c) certainly looks a
bit cheesy, but if it fails this test you'd think we'd have
heard about that sooner.

HAVE_CBRT is not set.

If I undefine HAVE_CBRT on Linux, I get the exact same failure! So it
seems our own version of cbrt() is broken wrt our own regression tests
:-( Must be that nobody else (at least on i386) uses that code.

The mingw version does appear to work, but it's noticably more complex,
see
http://cvs.sourceforge.net/viewcvs.py/mingw/runtime/mingwex/math/cbrt.c?
rev=1.1&view=auto.

It's placed in the public domain, so we should be able to use it if we
want to
(http://cvs.sourceforge.net/viewcvs.py/mingw/runtime/DISCLAIMER?rev=1.1&amp;
view=auto).

What do you think is best - try to adapt that version, or update our
regression tests outputs to accept the output from our current code?

//Magnus

On Mon, Apr 24, 2006 at 03:01:51PM +0200, Magnus Hagander wrote:

If I undefine HAVE_CBRT on Linux, I get the exact same failure! So it
seems our own version of cbrt() is broken wrt our own regression tests
:-( Must be that nobody else (at least on i386) uses that code.

<snip>

What do you think is best - try to adapt that version, or update our
regression tests outputs to accept the output from our current code?

Given that our output gets very very close, perhaps we should take a
hint from the end of the MinGW version, do a single Newton iteration to
fixup those last few digits.

Adding this before the last line of our version of cbrt():

tmpres -= ( tmpres - (x/(tmpres*tmpres)) )*0.33333333333333333333;

Makes it give the same result as my system version...
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout <kleptog@svana.org> writes:

Given that our output gets very very close, perhaps we should take a
hint from the end of the MinGW version, do a single Newton iteration to
fixup those last few digits.

That seems like a plan to me.

regards, tom lane

What do you think is best - try to adapt that version, or

update our

regression tests outputs to accept the output from our current code?

Given that our output gets very very close, perhaps we should
take a hint from the end of the MinGW version, do a single
Newton iteration to fixup those last few digits.

Adding this before the last line of our version of cbrt():

tmpres -= ( tmpres - (x/(tmpres*tmpres)) )*0.33333333333333333333;

Makes it give the same result as my system version...

That totally didn't work on visual c++ at least. It fixes those two
ones, but it breaks the other lines in the same test:

*** ./expected/float8-exp-three-digits-win32.out        Wed Jun  8
23:15:29 2005
--- ./results/float8.out        Mon Apr 24 21:57:40 2006
***************
*** 321,329 ****
  SELECT '' AS five, f.f1, ||/f.f1 AS cbrt_f1 FROM FLOAT8_TBL f;
   five |          f1          |        cbrt_f1        
  ------+----------------------+-----------------------
!       |                    0 |                     0
        |               1004.3 |       10.014312837827
!       |               -34.84 |     -3.26607421344208
        | 1.2345678901234e+200 | 4.97933859234765e+066
        | 1.2345678901234e-200 |  2.3112042409018e-067
  (5 rows)
--- 321,329 ----
  SELECT '' AS five, f.f1, ||/f.f1 AS cbrt_f1 FROM FLOAT8_TBL f;
   five |          f1          |        cbrt_f1        
  ------+----------------------+-----------------------
!       |                    0 |                   NaN
        |               1004.3 |       10.014312837827
!       |               -34.84 |     -1.08869140448069
        | 1.2345678901234e+200 | 4.97933859234765e+066
        | 1.2345678901234e-200 |  2.3112042409018e-067
  (5 rows)

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

That totally didn't work on visual c++ at least. It fixes those two
ones, but it breaks the other lines in the same test:

It's a couple bricks shy of a load (doesn't handle zero or negative
input correctly) but easily fixed. I'm just about to commit it.

regards, tom lane

That totally didn't work on visual c++ at least. It fixes those two
ones, but it breaks the other lines in the same test:

It's a couple bricks shy of a load (doesn't handle zero or
negative input correctly) but easily fixed. I'm just about
to commit it.

Great. I'll check it out on VC++ as soon as it propagates out to
anoncvs.

//Magnus