Обсуждение: Regression error on float8
I'm getting the following regression errors with a backend built using Visual C++: *** ./expected/float8-exp-three-digits-win32.out Wed Jun 8 23:15:29 2005 --- ./results/float8.out Sun Apr 23 20:44:44 2006 *************** *** 324,331 **** | 0 | 0 | 1004.3 | 10.014312837827 | -34.84 | -3.26607421344208 ! | 1.2345678901234e+200 | 4.97933859234765e+066 ! | 1.2345678901234e-200 | 2.3112042409018e-067 (5 rows) SELECT '' AS five, * FROM FLOAT8_TBL; --- 324,331 ---- | 0 | 0 | 1004.3 | 10.014312837827 | -34.84 | -3.26607421344208 ! | 1.2345678901234e+200 | 4.9793385923476e+066 ! | 1.2345678901234e-200 | 2.31120424090182e-067 (5 rows) SELECT '' AS five, * FROM FLOAT8_TBL; ====================================================================== Any pointers appreciated... //Magnus
"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& 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/ > From each according to his ability. To each according to his ability to litigate.
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