Date: Mon, 4 Feb 2002 00:39:07 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jeroen Ruigrok/asmodai <asmodai@wxs.nl> Cc: <standards@FreeBSD.ORG> Subject: Re: Possible math problems Message-ID: <20020204001700.A19228-100000@gamplex.bde.org> In-Reply-To: <20020203111121.GF52378@daemon.ninth-circle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Feb 2002, Jeroen Ruigrok/asmodai wrote: > http://win-www.uia.ac.be/u/cant/ieeecc754.html > > Which is a math testsuite, and linked to from the IEEE 754 page. > > In the basic operations I noticed the following: > > Testrun: ./IeeeCC754 -c -s BasicOp/testsets/divide > > Error Line 655: exponent different > Error Line 655: mantissa different > Operation: div > Round to nearest > Operand 1: 00bfffff > Operand 2: 3fc00000 > Flags expected: x u > Flags returned: x u > Correct result: 007fffff > Returned result: 00800000 ucbtest reports similar things. > Summary: > -------- > Implementation signals underflow in case the result > (1) is tiny after rounding and > (2) suffers denormalization loss > ('u' - underflow) > Errors: 16/5408 > Warnings: 0/5408 > Skipped: 0/5408 > > Only problems happened with the multiply/division operations. But it IIRC, the problems for division are caused by double rounding. IIRC, on i387's results are first rounded to extended precision and then rounded to the default precision. The Athlon needs to be bug for bug compatibile with Intel. > becomes more interesting when doing long precision. The error rate > increases a lot: > > Testrun: ./IeeeCC754 -c -d BasicOp/testsets/add > Errors: 0/3152 > > Testrun: ./IeeeCC754 -c -l BasicOp/testsets/add > Errors: 1788/3152 This is probably because the test neglects to set the precision so that long doubles sort of work. gcc doesn't support long doubles properly because it is too hard and slow to do it right. FreeBSD defaults to doing almost all calculations in double precision to limit the damage from the long double support so that it mostly doesn't affect double precision. Perhaps gcc-3 is better. C99 clearly doesn't permit the gcc-2 implementation; C90 was not so clear. ucbtest is aware of this problem but doesn't test long double precision IIRC. It sets the precision to double so that its tests have some chance of working if the default precision and/or compiler support is broken. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020204001700.A19228-100000>