Version 1.6 of ais/ai-00315.txt

Unformatted version of ais/ai-00315.txt version 1.6
Other versions for file ais/ai-00315.txt

!standard A.5.3 (00)          04-02-27 AI95-00315/02
!class amendment 02-09-30
!status No Action (8-0-1) 04-09-17
!status work item 03-11-04
!status received 02-09-26
!priority Low
!difficulty Medium
!subject Full support for IEC 559:1989
!summary
A new mode, named IEC 559 mode, is defined to provide support for IEC 559:1989
!problem
!proposal
The IEC 559 mode is a mode "stricter than strict". That is, all the requirements for strict mode apply, plus some others. It is unspecified which mode is the default, if the three modes actually differ, and how the user selects a particular mode.
In the IEC 559 mode, Interfaces.IEEE_Float_32 must be present. Other types in Interfaces, e.g. IEEE_Float_64, must be present if fully supported by the hardware. By fully supported, we mean that all the requirements of IEC 559:1989, with the possible exception of those pertaining to binary <-> decimal conversions, are satisfied by the underlying hardware. If a format is supported by the hardware, but some of its operations trap to software, we do not require the existence of a corresponding type in Interfaces.
Float must be functionally equivalent to IEEE_Float_32. If Long_Float and IEEE_Float_64 both exist, they must be functionally equivalent. The attributes of IEEE_Float_32 and IEEE_Float_64, if present, must have the value specified in AARM G.2.2(11.a-g) (with Signed_Zeros = True).
The permission of G.2.1(16) does not apply. Furthermore, the accuracy rules in G.2.1(7-8) apply to the function Sqrt in any instantiation of Ada.Numerics.Elementary_Functions.
The value returned by Sqrt (-0.0) must be -0.0. No exception is raised in this case.
The attributes Image and Value and the procedures Put and Get in any instantiation of Ada.Text_IO.Float_IO comply with the following accuracy requirements:
o If the argument has the form M * 10.0 ** N where M is an integer in the range
-Max_M .. Max_M and N is an integer in the range -Max_N .. Max_N, then the conversion is exact.
o Otherwise if the rounding mode is Round_To_Nearest the error of the converted
result does not exceed by more than 0.47 units in the destination's least significant digit the error that would be incurred by rounding to the nearest value, provided that overflow/underflow does not occur.
o In the directed rounding modes the error has the correct sign and does not
exceed 1.47 units of the last place.
Max_M is 1E9 - 1 for IEEE_Float_32 and 1E17 - 1 for IEEE_Float_64. Max_N is 13 for IEEE_Float_32 and 27 for IEEE_Float_64.
Image, Value, Put and Get are monotonic. If the rounding mode is Round_To_Nearest applying Image followed by Value, or Put followed by Get, is the identity as long as the strings have at least 9 significant digits for IEEE_Float_32 and 17 significant digits for IEEE_Float_64.
The operators "<=", "<", "=", ">", ">=" for a floating-point type return False in the unordered case. The operator "/=" returns True in the unordered case. (Note that this means that 'not (X < Y)' may be distinct from 'X >= Y'. Optimizers, beware!)
The arithmetic operators properly operate on NaNs and infinities, and comply with the current rounding mode.
For every subtype S of a floating-point type T, the following additional attributes are defined:
S'Infinity returns a value of type T that represents +oo.
S'Quiet_NaN returns a value of type T that is a quiet NaN; if the
hardware supports several representations for quiet NaNs, it is implementation defined which one is returned by this attribute.
S'Signalling_NaN returns a value of type T that is a signalling NaN; if the
hardware supports several representations for signalling NaNs, it is implementation defined which one is returned by this attribute.
S'Is_NaN A function with the specification:
function S'Is_NaN (X : T) return Boolean;
returns True if X is a quiet or signalling NaN.
S'Finite A function with the specification:
function S'Finite (X : T) return Boolean;
returns True if X is neither an infinity nor a NaN.
S'Unordered A function with the specification:
function S'Unordered (X, Y : T) return Boolean;
returns True if X and Y are unordered.
The attributes Is_NaN, Finite and Unordered are static if their prefix and arguments are.
Implementation Advice
The attribute X'Valid should return True if and only if S'Is_Nan (X) returns False. In particular, an infinity should be a valid value.
Bounded (Run-Time) Errors
Any usage of a signalling NaN, other than passing it to one of the attributes Is_NaN, Finite, Unordered or Valid, is a bounded error. The possible consequences are that Program_Error is raised, or Constraint_Error is raised, or the signalling NaN behaves as a quiet NaN.
The evaluation of a language-defined relational operator is a bounded error if one of the operands is a quiet NaN. The possible consequences are that Program_Error is raised, or the result of the evalution is False, or the result of the evaluation is True.
The conversion of a quiet NaN to a numeric type with a different underlying representation is a bounded error. The possible consequences are that Program_Error is raised, or the result of the conversion is a quiet NaN (if the target type supports such a value).
The following predefined package is added:
package Ada.Numerics.IEC_559 is
type Rounding_Modes is (Round_To_Nearest, Round_Towards_Zero, Round_Up, Round_Down); procedure Set_Rounding_Mode (R : Rounding_Modes); function Rounding_Mode return Rounding_Modes;
type Format is (Single, Single_Extended, Double, Double_Extended); procedure Set_Rounding_Precision (F : Format); function Rounding_Precision return Format;
-- The following is called "exception" by IEC 559:1989... type Event is (Invalid_Operation, Division_By_Zero, Overflow, Underflow, Inexact); procedure Set_Flag (E : Event; To : Boolean); function Flag (E : Event) return Boolean;
type Events is array (Event) of Boolean; procedure Set_Flags (E : Events); function Flags return Events;
-- Is this the right level of granularity? type Operation is (Add, Subtract, Multiply, Divide, Remainder, Sqrt, Float_Float_Conversion, Float_Integer_Conversion, Integer_Float_Conversion, Rounding, Binary_Decimal_Conversion, Decimal_Binary_Conversion, Comparison);
generic type T is digits <>; package Traps is type Trap_Handler is access function (E : Event; Op : Operation; Fmt : Format; Result : T; Arg1, Arg2 : T) return T; procedure Enable_Trap (H : Trap_Handler; E : Event); procedure Disable_Trap (E : Event); function Trap_Is_Enabled (E : Event) return Boolean; function Handler (E : Event) return Trap_Handler; end Traps;
end Ada.Numerics.IEC_559;
This package operates on global, system-wide state that is modified or used by a variety of floating-point operations. Only basic facilities are provided here. It is expected that more elaborate facilities can be built as needed by the user (e.g using protected objects to deal with race conditions or controlled objects to protect against aborts.)
The rounding mode specifies how arithmetic operations round the (infinitely precise) mathematical result to the destination format. When a partition starts, the rounding mode is Round_To_Nearest.
Some machines (e.g. the x86 family) always operate on an extended floating-point format. The rounding precision makes it possible to reduce the precision of the computations. This is important to avoid double rounding in precision-reducing operations. Set_Rounding_Precision has no effect on hardware that perform all computations in the destination format. When a partition starts, the rounding precision must correspond to the most precise supported format.
Events (called exceptions in IEC 559:1989, but we cannot use that name) describe conditions that may happen as part of some floating-point operation. Event flags may be read/written either one by one or as a whole.
An event may cause a trap. If it doesn't cause a trap, execution proceeds normally. If it causes a trap, the corresponding handler is called. IEC 559:1989 describes the arguments that are passed to the handler. The value of Result, Arg1 and Arg2 are converted to type T before calling the handler. This conversion never causes a trap (although it may result in infinities being passed to the handler). If some of the arguments Result, Arg1 and Arg2 are not relevant for a given event, the value T'Quiet_NaN is passed to the handler.
The handler may return a value, in which case execution proceeds as if this value had been the actual result of the operation.
The value null for a handler represents the Ada default, which is to ignore Underflow and Inexact, raise Constraint_Error on Division_By_Zero and Overflow, and is unspecified for Invalid_Operation. The Ada default is in effect when a partition starts.
The correspondence between Ada operations and IEC 559 operations is unspecified. Therefore, relying on the operation passed to the handler may be unreliable, unless code statements are used.
!discussion
!example
!ACATS test
!appendix

!topic        IEEE 754 numerics model
!reference  RM95-G.2
!from         Juergen F H Winkler  2002.09.26
!keywords  numerics, IEEE 754,  rounding

!discussion
IEEE 754 is supported by most microprocessors in use today.
It has more useful features than are required by the strict mode of RM95.
Examples of such features are:
-  different rounding modes
-  infinities and NaNs
-  tight accuracy requirement for sqrt
   (Intel processors e.g. implement additional functions)

[Win 2002] contains an example, where the different rounding modes are
crucial (sect. 7.1).

[DK 98] contains several examples which show that the support of Java
for IEEE 754 is not sufficient.

Ada would be the first language to let the user use the IEEE 754
features of the processor. Up to now they can only be used in assembler.
It would therefore be useful if Ada contained a numerics model
with all the properties of IEEE 754.

DK 98
Kahan, W; Darcy, Joseph D.: How Java's Floating-Point Hurts Everyone Everywhere.
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf, June 18, 1998. (visited:
2000.Nov.04 )

Win 2002
Winkler, Jrgen F. H.: A safe variant of the unsafe integer arithmetic of Java.
Software - Practice and Experience 32, 7(2002) 669..701.  DOI: 10.1002/spe.454

****************************************************************

From: Robert Dewar
Sent: Thursday, September 26, 2002  11:47 AM

Please do NOT send HTML to public lists, this is totally uselress and
bad netiquette. If you are using some microsoft mailer that does this
by default, please turn off the option. Many people throw away messages
with HTML junk in them so probably your message got ignored by some people.

Regarding IEEE fpt, a lot of work has been done in this area. You should
familiarize yourself with the work of the NRG in this area, and you should
probably also read Brian Siritisky's thesis. This same advice applies to
anyone else who wants to discuss this issue technically.

****************************************************************

From: Randy Brukardt
Sent: Thursday, September 26, 2002  12:34 AM

Besides echoing Robert's comment that sending HTML to mailing lists is
frowned upon, I'd like to point that this list is for PROPOSALS and
discussion about proposals for changes and corrections to the Ada
Programming Language. There is no proposal in your message, simply a
statement that it would be nice if Ada supported something. You need to
include a proposal of how this support could be accomplished in Ada, and
(preferably) an example of some problem that can be solved with that
proposal that cannot be solved with existing Ada.

I've privately forwarded a rules summary to Juergen separately.

****************************************************************

From: Robert Dewar
Sent: Thursday, September 26, 2002  1:25 PM

Ed points out that I made a horrible mistake in my last message, for
which I apologize, must be losing my mind today (Ed = Ed Schonberg):

I said

<<Regarding IEEE fpt, a lot of work has been done in this area. You should
familiarize yourself with the work of the NRG in this area, and you should
probably also read Brian Siritisky's thesis. This same advice applies to
anyone else who wants to discuss this issue technically.
>>

I meant not Brian Siritsky, but rather Sam Figueroa. This is a PhD thesis
from the department of CS at New York University, 1999, Robert Dewar, advisor.
I will try to track down a better reference.

****************************************************************

From: Robert Dewar
Sent: Thursday, September 26, 2002  1:29 PM

Note that Sam's thesis contains a completely worked out proposal in this
area (IEEE754 support in Ada).

****************************************************************

From: John Halleck
Sent: Thursday, September 26, 2002  2:35 PM

  http://www.cs.nyu.edu/csweb/Research/Theses/figueroa_sam.pdf
  for the pdf version.  Back up one for other options.

****************************************************************


Questions? Ask the ACAA Technical Agent