Date: Wed, 05 Mar 2008 22:56:06 -0800 From: Colin Percival <cperciva@freebsd.org> To: Colin Percival <cperciva@FreeBSD.ORG>, Peter Jeremy <peterjeremy@optushome.com.au>, Bruce Evans <bde@FreeBSD.ORG>, src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/include _types.h Message-ID: <47CF9586.70707@freebsd.org> In-Reply-To: <20080306063452.GB48339@zim.MIT.EDU> References: <200803051121.m25BLE03035426@repoman.freebsd.org> <20080305182531.GS68971@server.vk2pj.dyndns.org> <20080306021222.GA46783@zim.MIT.EDU> <47CF5D19.3090100@freebsd.org> <20080306033246.GA47280@zim.MIT.EDU> <47CF7EBF.6000009@freebsd.org> <20080306063452.GB48339@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote:
> On Wed, Mar 05, 2008, Colin Percival wrote:
>> Setting the i387 FPU to 53-bit precision gives standards-compliant
>> behaviour whether people are using "double" or "long double".
>
> Not quite.
How is it not standards-compliant?
>> Yes and no. Double rounding isn't allowed;
>
> Yes, it is.
No, it isn't. The following code
double x, y, z;
x = 1.0;
y = 0x1.0p-53 + 0x1.0p-75;
z = x + y;
z = z - 1.0;
if (z == 0.0)
printf("BUGGY MATH\n");
else
printf("IEEE754-COMPLIANT MATH\n");
should never output "BUGGY MATH", since x + y should round up to
1 + 2^(-52); but if you set the i387 to use extended precision, it
gets the wrong answer.
>>> The downside is that this breaks long doubles.
>> Except that it doesn't. Using 53-bit precision for long doubles is
>> a perfectly valid and standards-compliant option.
>
> It's impossible to implement efficient library functions that
> produce correct long double results
You could have stopped this sentence here -- for all practical purposes,
correctly rounded trigonometric functions are not feasible.
> when the FPU is set to 64-bit
> mode and avoid double rounding and related problems when the FPU
> is set to 53-bit mode.
Fortunately, library functions aren't required to have any particular
error bounds. It's always nice if they are correct to within 0.6ulp
instead of 0.8ulp or suchlike -- but nobody should be proving code
correctness based on assumed properties of library transcendental
functions. People should, and do, prove code correct based on the
assumption that double precision arithmetic behaves like double precision
arithmetic, however (myself included).
Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47CF9586.70707>