Re: Motion 46: finalise interval literals, amendments

[Ian McIntosh <ianm@xxxxxxxxxx>]

Compliance is a good question.  I'm not allowed to look into how competitors do things so can't give an answer based on investigation.


If you implement C99 (the 1999 version of the ANSI C standard) or the 2011 version, then you or the operating system must have implemented functions to get and set the rounding mode to the four 754 BFP settings.  Those are pointless unless the generated code honours the rounding mode.  If you claim IEEE 754 compliance but using those functions to control the rounding mode of subsequent operations including conversions doesn't work, it is a bug and should be fixed.

Consider though that while most hardware and their compilers only support dynamic rounding (a register says which mode to use), some only support static rounding (the instruction says which mode to use) and some support a mixture.  That will affect how 1788 will be implemented.  The C99 functions assume dynamic rounding.


The aspect of 1788 correctness I'm most concerned about is optimization of code containing interval variables being set to the same interval literal, or to the same variable, or one to another.  Depending on the semantics we and/or those specifying language bindings choose, optimization could produce unintended results and unless interval types are built in to the compiler (something I don't want) all ways to get it right may be difficult and painful.  With different semantics (which we don't all agree on) things may go well, but decisions should be made on what's the right thing to do, not what works with current languages and optimizers.


On the general subject of correctness:
Can anybody here write a 1000 line email with absolutely no errors?  Having somebody proofread it helps, as does using a spell checker and a grammar checker, but 1000 lines error free is very very difficult.  So can anybody write a 5000 line standard perfectly?  With design and code reviews and test cases, but also with misreadings, misunderstandings and mistakes, how many bugs would you expect in a 10,000 line minimalist or 25,000 line maximalist implementation of that standard?  Or in a multi-million line optimizing compiler the implementation relies on?
Fortunately many bugs are relatively benign, at least until two or more are combined . . .
Who cares if the design needs O rings, unless they leak in cold weather and the President wants a launch on a cold day to bolster his speech?  Who cares if insulation falls off, unless it damages tiles and the tiles must be intact for a safe reentry?  Who cares if there are bugs in the ten million lines of code in one recent car whose manufacturer of course can't duplicate the reported problems of emergency braking just as the software might have decided to do regenerative braking?
It's the unconsidered interactions that have the worst consequences.
So of course you can expect bugs, even in a minimalist implementation of a minimalist standard.  Use all possible methods to do better, but never expect software to be totally correct and always take precautions against failure including hiring good bug fixers.  And if a maximalist standard means users don't read, understand and remember every little detail, or a minimalist standard means users don't understand parts that were too concise, or have to write more code because you omitted some functionality many need, expect even more trouble from those user issues.

And no, I'm not a pessimist, I'm an optimist with experience.

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


Ralph Baker Kearfott ---07/05/2013 02:52:47 PM---Ian et al, Yes.  The question is, "How many systems comply with this aspect of 754,

From:	Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	07/05/2013 02:52 PM
Subject:	Re: Motion 46: finalise interval literals, amendments

---

Ian et al,

Yes.  The question is, "How many systems comply with this aspect of 754, 
and, if so,
how easy is it to access this feature?"  A related question is "If 
compliance with
this aspect of 754 is spotty, what does that say about future compliance 
(or implementation of)
1788?"  In particular, if such compliance is a problem, Ned's argument 
about a minimalist
set of requirements looks attractive.

Comments?

Baker

On 07/04/2013 04:35 PM, Ian McIntosh wrote:
>
> Where you've marked, the "If rounding is necessary, they shall use 
> correct rounding" means both using the correct directed rounding mode 
> when one was specified or the default rounding mode if not, and also 
> doing that rounding correctly.
>
> - Ian McIntosh          IBM Canada Lab         Compiler Back End 
> Support and Development
>
>
> Inactive hide details for Ralph Baker Kearfott ---07/04/2013 03:15:44 
> PM---Ned, See "****==>" in the appended excerpt from 754-Ralph Baker 
> Kearfott ---07/04/2013 03:15:44 PM---Ned, See "****==>" in the 
> appended excerpt from 754-2008.
>
>
>     From: 
>
> 		 
> Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
>
>     To: 
>
> 		 
> Ian McIntosh/Toronto/IBM@IBMCA
>
>     Date: 
>
> 		 
> 07/04/2013 03:15 PM
>
>     Subject: 
>
> 		 
> Re: Motion 46: finalise interval literals, amendments
>
> ------------------------------------------------------------------------
>
>
>
> Ned,
>
> See "****==>" in the appended excerpt from 754-2008.
>
> Doesn't this say that directed roundings shall be available?
>
> Baker
>
> ================================================================
> * 5.4.2 Conversion operations for floating-point formats and decimal
> character sequences
>
> * 5.12 Details of conversion between floating-point data and external
> character
> sequences 5.120
>
> This clause specifies conversions between supported formats 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.
>
> Implementations shall provide conversions between each supported binary
> format and external decimal
> character sequences such that, under roundTiesToEven, conversion from
> the supported format to external
> decimal character sequence and back recovers the original floating-point
> representation, except that a
> signaling NaN might be converted to a quiet NaN. See 5.12.1 and 5.12.2
> for details.
> Implementations shall provide exact conversions from each supported
> decimal format to external decimal
> character sequences, and shall provide conversions back that recover the
> original floating-point
> representation, except that a signaling NaN might be converted to a
> quiet NaN. See 5.12.1 and 5.12.2 for
> details.
>
> Implementations shall provide exact conversions from each supported
> binary format to external character
> sequences representing numbers with hexadecimal digits for the
> significand, and shall provide conversions
> back that recover the original floating-point representation, except
> that a signaling NaN might be converted
> to a quiet NaN. See 5.12.1 and 5.12.3 for details.
>
> * 5.12.2 External decimal character sequences representing finite numbers
> 5.12 .0
> An implementation shall provide operations that convert from all
> supported floating-point formats to
> external decimal character sequences (see 5.4.2). For finite numbers,
> these operations can be thought of as
> parameterized by the source format, the number of significant digits in
> the result (if specified), and whether
> the quantum is preserved (for decimal formats). Note that specifying the
> number of significant digits and
> specifying quantum preservation are mutually incompatible. The means of
> specifying the number of
> significant digits and of specifying quantum preservation are
> language-defined and are typically embodied
> in the conversionSpecification of 5.4.2.
>
> 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.
>
> All conversions from external character sequences to supported decimal
> formats shall preserve the quantum
> (see 5.4.2) unless rounding is necessary. At least one conversion from
> each supported decimal format shall
> preserve the quantum as well as the value and sign.
>
> ================================================================
>
>
> On 07/04/2013 01:26 PM, Ned Nedialkov wrote:
> > On 2013-07-04, at 6:24 PM, "J. Wolff von Gudenberg" 
> <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> >> John,
> >>   here is my second part of the comment on motion 46
> >>
> >>
> >>   If the underlying type is IEEE754 conformant and provides the 
> covertFormat function with rounding,
> > I should check this myself, but I don't recall IEEE requiring 
> directed roundings when converting a string
> > to say double.
> >
> >
>
>
> -- 
>
> ---------------------------------------------------------------
> R. Baker Kearfott,    rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
> (337) 482-5270 (work)                     (337) 993-1827 (home)
> URL: http://interval.louisiana.edu/kearfott.html
> Department of Mathematics, University of Louisiana at Lafayette
> (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
> Box 4-1010, Lafayette, LA 70504-1010, USA
> ---------------------------------------------------------------
>
>
>


-- 

---------------------------------------------------------------
R. Baker Kearfott,    rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------