Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IEEE 754 Asks the Impossible
45 views
Skip to first unread message
Quadibloc
Apr 2, 2016, 2:27:20 PM4/2/16
to
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
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
Wolfgang Ehrhardt
Apr 4, 2016, 6:10:15 AM4/4/16
to
On Sat, 2 Apr 2016 11:27:19 -0700 (PDT), Quadibloc <jsa...@ecn.ab.ca>
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, =
>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=
>some algorithms, imposes an unreasonable burden if one wishes to use a fast=
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).
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).
Quadibloc
Aug 20, 2016, 1:22:03 PM8/20/16
to
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.
> >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.
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
Quadibloc
Aug 14, 2017, 6:26:06 PM8/14/17
to
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.
> 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.
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
0 new messages