Fw: Motion P1788/M0044:Constructors -- Voting Period begins - controlling rounding mode

[Ian McIntosh <ianm@xxxxxxxxxx>]

I've merged two email streams back together in the attached emails.  See STREAM 1 and STREAM 2 for the originals.


RBK>  Yes, I am aware of access to changing the rounding mode in modern
RBK>  programming languages. What I was not aware of was that implementers
RBK>  interpreted this to apply to text-to-interval conversions, ...

Two good questions in one - should they and do they?


I apologize for the length of the following.  Most standards are written to be precise not brief.  You can skip to the bold parts.

IEEE 754-2008:

  4.1 Attribute specification
    Some attributes have the effect of an implicit parameter to most individual operations of this standard;
    language standards shall specify
     ― rounding-direction attributes (see 4.3)

  4.3 Rounding-direction attributes
   Except where stated otherwise, every operation shall be performed as if it first produced an intermediate
    result correct to infinite precision and with unbounded range, and then rounded that result according to one
    of the attributes in this clause.
    The rounding-direction attribute affects all computational operations that might be inexact.

  4.3.2 Directed rounding attributes
    Three other user-selectable rounding-direction attributes are defined, the directed rounding attributes
    roundTowardPositive, roundTowardNegative, and roundTowardZero.

  5.1 Overview
    General-computational operations produce floating-point or integer results, round all results
    according to Clause 4, ...

  5.4 formatOf general-computation operations
  5.4.2 Conversion operations for floating-point formats and decimal character sequences:
    Implementations shall provide ... conversions to and from decimal character sequences.
    ...
    ― formatOf-convertFromDecimalCharacter(decimalCharacterSequence)

Note conversions from text to floating-point are part of general-computation operations, to which rounding-direction attributes apply.

  5.12 Details of conversion between floating-point data and external character sequences
    ... Note that
    conversions between supported formats of different radices are correctly rounded and set exceptions
    correctly as described in 5.4.2, subject to limits stated in 5.12.2 below.

In the cases we're discussing, the external text sequence is in decimal radix and the internal floating-point value is in binary radix.  The conversion is to be correctly rounded.

  5.12.2 External decimal character sequences representing finite numbers
    An implementation shall also provide operations that convert external decimal character sequences to all
    supported formats. These operations can be thought of as parameterized by the result format.
    Within the limits stated in this clause, conversions in both directions shall preserve the value of a number
    unless rounding is necessary and shall preserve its sign. If rounding is necessary, they shall use correct
    rounding and shall correctly signal the inexact and other exceptions.
    ...
    There might be an implementation-defined limit on the number of significant digits that can be converted
    with correct rounding to and from supported binary formats. That limit, H, shall be such that H ≥ M + 3 and
    it should be that H is unbounded.
    For all supported binary formats the conversion operations shall support correctly rounded conversions to
    or from external character sequences for all significant digit counts from 1 through H (that is, for all
    expressible counts if H is unbounded).
    ...
      ― Intervals are respected, in the sense that directed-rounding constraints are honored even when
      more than H significant digits are given: the directed rounding error has the correct sign in all
      cases, and never exceeds 1 + 1/1000 units in the last place in magnitude.

So IEEE 754 says conversions from text to floating-point are to be correctly rounded, and correctly rounded includes using the rounding directions towards negative and towards positive.


Of course IEEE 754 isn't a language standard, so we have to look at those too.  The following are from the 1999 version of the C Standard "ISO/IEC 9899:1999 (E)".

The first point is that the C standard doesn't require that an implementation use IEEE 754 or IEC 60559.

Something that's a concern is in
  5.2.4.2.2 Characteristics of floating types <float.h>
    The accuracy of the floating-point operations (+, -, *, /) and of the library functions in
    <math.h> and <complex.h> that return floating-point results is implementation defined.
    The implementation may state that the accuracy is unknown.

So while it can't round incorrectly, if an implementation documents it, it could provide less accuracy which can have the same result.  If it doesn't document the accuracy of text to floating-point conversions then they should be accurate.  Specific macros must be defined describing the minimum accuracy.

Annex F (normative) IEC 60559 floating-point arithmetic
    An implementation that
    defines _ _STDC_IEC_559_ _ shall conform to the specifications in this annex. Where
    a binding between the C language and IEC 60559 is indicated, the IEC 60559-specified
    behavior is adopted by reference, unless stated otherwise.

So if an implementation claims by defining the __STDS_IEC_559__ macro that it implements that standard, it is required to except where the C standard says otherwise.

  F.3 Operators and functions
    — The translation time conversion of floating constants and the strtof, strtod,
    strtold, fprintf, fscanf, and related library functions in <stdlib.h>,
    <stdio.h>, and <wchar.h> provide IEC 60559 binary-decimal conversions. The
    strtold functions in <stdlib.h> provide the conv function recommended in the
    Appendix to ANSI/IEEE 854.
    ...
    — The fegetround and fesetround functions in <fenv.h> provide the facility
    to select among the IEC 60559 directed rounding modes represented by the rounding
    direction macros in <fenv.h> (FE_TONEAREST, FE_UPWARD, FE_DOWNWARD,
    FE_TOWARDZERO) and the values 0, 1, 2, and 3 of FLT_ROUNDS are the
     IEC 60559 directed rounding modes.

That means if the implementation claims to support IEC 60559 / IEEE 754 both strtod ( ) and the simpler atof ( ) used in the suggested function must follow the IEC 60559 / IEEE 754 specification, and that means they must round correctly in the specified rounding direction both at compile time and in the library.


RBK>  ... and that
RBK>  the text-to-interval conversion is done correctly from the point of
RBK>  view of interval computations.

And another good question.  If IEEE 754-2008 is followed, then the conversions and rounding-mode control will be done as intervals need.

- - - - -

LW>  The above code fragment makes a very dangerous assumption, to wit, that the atof() function from the compiler library is round-safe, which means that all of the functions it calls must also be round-safe.
LW>  In my experience few implementations make that claim.  And some of those that do make the claim are false.

If they claim 754 conformance, they don't need to specifically claim that atof ( ) rounds correctly - it's part of the larger claim.  If they make the claim falsely the bug should be reported.

LW>  A library wherein atof() is just a wrapper around a more capable function such as strtod() [or strtof() or strtold()] one often finds that the more sophisticated inner function makes assumptions
LW>  about the rounding environment that may not be lightly violated.

Whether atof ( ) is a standalone function or internally calls strtod ( ) or something else, the implementation is responsible for it working correctly.

LW>  I happen to agree that it should work.  But my opinion seems to carry little weight against the fact that for many compilers, it does not in fact work.
LW>  
LW>  Do we care about the difference between that should work and what does work?  I think we should care.

We should (1) define our standard assuming that other standards are followed, (2) expect our standard's implementers to open bug reports and compiler / library implementers to fix them when other standards are not correctly implemented, and of course (3) be prepared for alternative solutions and workarounds.  We cannot be effective if we start by assuming that other standards are not correctly implemented though.

In cases where it does not work, one workaround might be to split the suggested function into several, with the two calls to atof ( ) in separate functions to bypass an optimization error assuming the two calls to atof ( ) can be commoned into one, or ignoring the FENV_ACCESS pragma.  Another would be to store inputs and outputs into volatile variables to prevent such optimizations.  Compiling without optimization would be a third.  There might be a compiler bad enough to need more than one of those.  If a library's atof ( ) doesn't honour the rounding mode, a 1788 implementer can write one that does.  Or even use inline asm or assembler.

There are some potential problem areas:
  1.  Not all C implementations claim to implement 754.  Not all can, because they run in a non-754 environment.
  2.  Those that do could document that their atof ( ) is inaccurate.  That will of course cause lots of problems.
  3.  They can have library bugs.
  4.  Optimization can introduce bugs, like just calling atof ( ) once and reusing a value from the wrong rounding mode, or rearranging the order of the rounding mode settings and the conversions.
  5.  There may be languages that could have intervals added to them which do not interface well to C.  If implementations of them claim 754 conformance, then a similar function can be written.

I didn't intend my function to be more than a quick example showing that directed rounding can be used in programming languages, but aside from bugs which should be fixed I think the approach is valid for C implementations which support 754.

- Ian McIntosh          IBM Canada Lab         Compiler Back End Support and Development


STREAM 1:

----- Forwarded by Ian McIntosh/Toronto/IBM on 05/17/2013 12:22 PM -----

From:	Vincent Lefevre <vincent@xxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	05/17/2013 08:49 AM
Subject:	Re: Motion P1788/M0044:Constructors  -- Voting Period begins - controlling rounding mode

---

On 2013-05-17 04:11:16 -0500, Ralph Baker Kearfott wrote:
> Yes, I am aware of access to changing the rounding mode in modern
> programming languages. What I was not aware of was that implementers
> interpreted this to apply to text-to-interval conversions, and that
> the text-to-interval conversion is done correctly from the point of
> view of interval computations.

Well, for string conversion, this is a bug. But all operations are
concerned by bugs, even the basic arithmetic operations. See:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37838

For C's math.h functions, this is worse, as the ISO C standard doesn't
require the rounding direction to be honored. You could only rely on
QoI.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


STREAM 2:

----- Forwarded by Ian McIntosh/Toronto/IBM on 05/17/2013 12:21 PM -----

From:	Lee Winter <lee.j.i.winter@xxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Cc:	stds-1788@xxxxxxxxxxxxxxxxx
Date:	05/16/2013 09:24 PM
Subject:	Re: Motion P1788/M0044:Constructors -- Voting Period begins - controlling rounding mode

---

On Thu, May 16, 2013 at 8:12 PM, Ian McIntosh <ianm@xxxxxxxxxx> wrote:

BK>  To do so would require a facility for rounding the text value 0.1 down into the binary format and also rounding it up.
BK>  . . .
BK>  I don't think it is readily accessible by default in common programming languages.



The 1999 version of the C standard has functions to get and set the rounding mode.  They can be called from C++ or from Fortran.  Fortran also has its own IEEE modules which could be used.

For example. in an environment that supports changing the rounding mode (as opposed to having static rounding modes), a function something like the (completely untested) following should work.

#include <stdlib.h>
#include <fenv.h>

typedef struct interval_s
{
    double lower;
    double upper;
} interval_t;

interval_t text2interval (const char const* text)
{
#pragma STDC FENV_ACCESS ON
    interval_t result;
    int original_rounding_mode = fegetround ( );
    (void) fesetround (FE_DOWNWARD);
    result.lower = atof (text);
    (void) fesetround (FE_UPWARD);
    result.upper = atof (text);
    (void) fesetround (original_rounding_mode);
    return result;
}

The above code fragment makes a very dangerous assumption, to wit, that the atof() function from the compiler library is round-safe, which means that all of the functions it calls must also be round-safe..  In my experience few implementations make that claim.  And some of those that do make the claim are false.

A library wherein atof() is just a wrapper around a more capable function such as strtod() [or strtof() or strtold()] one often finds that the more sophisticated inner function makes assumptions about the rounding environment that may not be lightly violated.

I happen to agree that it should work.  But my opinion seems to carry little weight against the fact that for many compilers, it does not in fact work.

Do we care about the difference between that should work and what does work?  I think we should care.

Lee Winter
Nashua, New Hampshire
United States of America (RIP)