> From: "Erik E. Fair" <fair@clock.org>
> Subject: Re: -mieee option
>
> Perhaps we could encourage a college or university to use NetBSD as a case
> study of floating point implementation for a Computer Science course in
> Numerical Analysis. If they audit and verify our implementations, we'd get
> a serious checkout, and they'd have a target to learn from...

Ack! No, please...

It's the consumers of floating point cycles that matter, here.

Also, the rationale for the compromises made on the RISC processors
is very much rooted in the difference between engineering and theory.

To play devil's advocate for a second: the argument _for_ the most costly
ieee fp "feature", ops on denorms, runs like this:

	it would be nice if certain mathematical identities held down to
	the 10^-38 format limit, which is another way of saying that it
	would be nice if the difference between calculations on arbitrary
	quantities differed by no more than the unavoidable difference between
	two representable quantities ... i.e., roundoff error

		so, ideally, within roundoff error:
			[1] (x-y) + y ~= x
			[2] iff x != y then x - y != 0
			[3] 1/(1/x) ~= x

	If you underflow to zero instead of to a denorm, some of these
	guarantees start to break down, for certain test cases, at around
	10^-31, whereas with gradual underflow (doing ops on denorms) you
	can preserve them down to 10-38 (but not below, contrary to popular
	belief, ieee FP doesn't get you nice arithmetic properties on data
	below the format limit)

OK, that's the argument _for_. It has a certain theoretical appeal, but an
engineer might say any or all of the following:

	* in the real world, the data is rarely valid beyond two or three
	  significant figures anyway, and _never_ to the last bit, besides,
	  other things are hurting the last bit anyway

	* you are just moving the limit from 10^-31 to 10^-38, if 10^-31 isn't
	  good enough, 10^-38 probably isn't either, and if it is, just go
	  to double precision and call it a day

	* if underflow is such a problem, you need another bit in the exponent

	* if precision or exponent range is such a problem, the calculation
	  should be done in (duhhh) double precision, giving you an exponent
	  range of 10^-308 (!)

Furthermore, there is an unavoidable correlation between the number of bits
in the operands and the cost and speed of the functional units. Denorms
effectively require much wider normalized operands. An engineer might also
say: for the cost and time penalty of doing _that_, I could give you 128-bit
arithmetic in HW.

Sigh, I hope I haven't put everyone to sleep. Please rest assured that your
faithful NetBSD developers do understand something on the subject...hey, wake
up! 

	Ross.Harvey@Computer.Org