cvs commit: src/sys/i386/include _types.h

[Colin Percival]

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