Re: motion 24.03
> Date: Wed, 20 Jul 2011 16:29:07 +0200
> From: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> To: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> CC: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: motion 24.03
>
> Dear Prof. Kulisch, P1788,
>
>
> I have the following questions and comments on Motion 24.03.
>
> Q1) Does the motion text
>
> "Every IEEE 1788 compliant system shall provide the four basic
> arithmetic operations addition, subtraction, multiplication, and
> division with rounding downwards and upwards."
>
> mean that the exact result r (in R) of each operations is rounded to
>
> max( {x in F | x <= r} ) for rounding downward (d1)
> min( {x in F | x >= r} ) for rounding upward (u1)
>
> or does it mean that r is rounded to an arbitrary number
>
> x in F with x <= r for rounding downward (d2)
> x in F with x >= r for rounding upward (u2)
>
> ?
The answer to this one is (d1) & (u1), the nearest
representable floating-point number in the desired
direction.
>
>
>
> Am 20.07.2011 09:55, schrieb Ulrich Kulisch:
> > Dear P1788 members,
> >
> > the motion 24.03 text is now very short. So let me list a few
> > arguments in favour of the motion:
> >
> > . . .
> >
> > -The operations are requested on the system level. So on processors that
> > provide IEEE 754 arithmetic it is trivial providing these operations
> > (although perhaps not most efficiently).
>
> Q2) What does system level mean? Hardware only? Is the Java VM a system?
As far as the IEEE is concerned, the term system
refers to that combination of hardware & software
that is presented to the user as a consistent
interface to our standard arithmetic.
Thus, Java VM is an excellent example of a system.
>
> >
> > . . .
> >
>
>
> If your answer for Q1 is (d1) and (u1) than we exclude implementations
> in programming languages without support for directed rounding, e.g. all
> Java VM based languages (Java, Scala, Groovy, Clojure ...) or pure
> (standard) and platform independent C++ (to my knowledge the still
> current C++03 standard did not define support for switching the rounding
> mode. Commonly the switching of the rounding mode is done in C++ using
> the C99 header fenv.h if supported, or with inline assembler.)
I am unfamiliar with most of the languages on your list
but I think you will find that both Java & C++ already
support basic arithmetic with directed roundings.
You will have to ask someone else about Java but in C++,
they are supported via the means of standard math library
function calls.
>
> The problem with (d1) and (u1) is the accuracy of one ulp, which is hard
> to achieve in many programming languages / systems.
>
> Best regards
>
> Marco
>
Not so.
Back in the late 70s & early 80s it was proven that the
basic arithmetic functions could be correctly rounded
with a fixed finite O(1) amount of work/circuitry
independent of their precision. In the end, that was
why add, subtract, multiply, divide, & square root were
on the list of required functions for 754.
Most other algebraic functions are suspected of being
able to be rounded correctly with an amount of work
proportional to the precision, O(p). In all cases
proven so far the precision required is either about
2p or something substantially < 3p.
Transcendental functions are proving hard to tackle
but even here all known cases are strictly < 3p.
Oddly enough, the hard part seems to lie in the
exponent range more than in the precision.
But it is always possible to correctly round any
function. And in the 80s, a couple variations on
algorithms that try 2p, then 4p, then 8p, ... were
shown to eventually work. And since there are no
known cases which require more than 3p, these methods
are very efficient, if not proven to be so.
Further, these last algorithms have been available
in open source math libraries for decades. So all
a new programming language has to do is download one
& use it.
Prof Kulisch is correct: These operations are easy
to do, readily available, & usually already supported
in hardware.
Dan