On Sat, 2 Apr 2016 11:27:19 -0700 (PDT), Quadibloc <[email protected]>
wrote:

Using the guard, round, and sticky bits, it is possible to always compute, = >in a reasonable time, the nearest rounded value for addition, subtraction, = >multiplication, division - and even square root.

However, according to the Wikipedia page on the IEEE 754 standard, while th= >is was all the 1985 standard asked, the current standard insists on correct=
rounding even for the transcendental functions - log and trig functions. U=
nlike rounding to a precision of a unit just over half the least difference=
between floating-point numbers, this can take a long time in a few, rare, =
cases.

Even so, some math libraries are currently offered, so says Wikipedia, whic= >h meet this standard. I am surprised. And I hardly think that it is wise to=
make such a requirement, or attempt to meet it, for most implementations.

Even getting the nearest rounded value for division, while easy enough for = >some algorithms, imposes an unreasonable burden if one wishes to use a fast=
division algorithm such as Newton-Raphson or Goldschmidt.

The requirement for basic arithmetic and sqrt is essential. Correct
round for log functions should be relative easy. A 'tricky' part are
the trigonometric functions. But there are long-known well-known
algorithms for range reduction (Payne/Hanek, see e.g.
K.C. Ng, Argument Reduction for Huge Arguments: Good to the Last Bit,
Technical report, SunPro, 1992. Available from <http://www.validlab.com/arg.pdf>), this is used in many libraries
related to or derived from Sun FDLIBM
(<http://www.netlib.org/fdlibm>).

As in many situation you have to decide whether to trade-off accuracy
vs. speed, although if in doubt I would almost always choose accuracy
(and the overhead is not that large, because in practice you can you a

multi-stage range reduction, with Payne/Hanek used for the worst
cases).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Using the guard, round, and sticky bits, it is possible to always compute, in a reasonable time, the nearest rounded value for addition, subtraction, multiplication, division - and even square root.

However, according to the Wikipedia page on the IEEE 754 standard, while this was all the 1985 standard asked, the current standard insists on correct rounding even for the transcendental functions - log and trig functions. Unlike rounding to a precision
of a unit just over half the least difference between floating-point numbers, this can take a long time in a few, rare, cases.

Even so, some math libraries are currently offered, so says Wikipedia, which meet this standard. I am surprised. And I hardly think that it is wise to make such a requirement, or attempt to meet it, for most implementations.

Even getting the nearest rounded value for division, while easy enough for some algorithms, imposes an unreasonable burden if one wishes to use a fast division algorithm such as Newton-Raphson or Goldschmidt.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, April 4, 2016 at 4:10:15 AM UTC-6, Wolfgang Ehrhardt wrote:

Even getting the nearest rounded value for division, while easy enough for = >some algorithms, imposes an unreasonable burden if one wishes to use a fast=
division algorithm such as Newton-Raphson or Goldschmidt.

I see now what I was overlooking.

Doing a division and having any idea of what the last bits are requires dividing the whole number.

But for multiplication, one can just multiply the last few bits of both numbers to know the last few bits of the product.

So the overhead involved of doing a back multiply at the end of a division to find the exact result can indeed be low enough to be acceptable even when one is looking for the ultimate possible speed.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, April 2, 2016 at 12:27:20 PM UTC-6, Quadibloc wrote:

However, according to the Wikipedia page on the IEEE 754 standard, while this was all the 1985 standard asked, the current standard insists on correct rounding even for the transcendental functions - log and trig functions.

I see now that this was not the case, it was merely encouraged.

And apparently it's not as completely impossible as I thought: the documentation
on the CRLIBM mathematics library explains how this goal can be achieved for single-precision numbers, and approached for double-precision.

John Savard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)