Re: motion 24.03
Am 20.07.2011 um 18:33 schrieb Dan Zuras Intervals:
>> 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
No, floating point operations are settled to round to nearest for the Java VM, see
Java VM Specification Section 3.8.1 Java Virtual Machine Floating-Point Arithmetic and IEEE 754
http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html
> but in C++,
> they are supported via the means of standard math library
> function calls.
to my knowledge the only possible ways to address the rounding mode in C++ by using the C99
header fenv.h or to use inline assembler. The first method is not defined in the C++03 standard and the
second approach is a platform dependent way... Hence I can not find a specification in the current C++ standard
to set the rounding mode for floating point operations.
Marco
>
>>
>> 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