Re: Correction --- Motion P1788/M0033.01:NumberFormat -- discussion period begins
Vincent,
I want to be sure that I understand your definitions correctly.
So I ask a lot of small questions.
1) The draft of Level2
http://grouper.ieee.org/groups/1788/email/msg04488.html
had the definition of number format:
<<<<<
6.2. Number formats. Having regard to §6.1, a number format, or just format, is the set
of all pairs (x, f ) where x belongs to a finite subset F of the extended reals R∗ that contains −oo
and oo, and f is a name for F. Normally the format is identified with the set F. A floating-point
format in the 754 sense, such as binary64, is identified with the number format where F comprises
the set of extended-real numbers that are exactly representable in that format, where –0 and +0
both represent the mathematical number 0.
>>>>>
Do you want to replace that definition of "number format" by your definittion of "number format" ?
2) Do your (A1)-(A5) definitions define "number format" F as a finite set of extended real or
F is a set of pairs (x, f) with x - extended real (as in draft level 2) ?
3) Is the set F = { 0, -oo, +oo, NaN } (with some rounding) the minimal valid "number format" at level (A1)-(A5) ?
4) Is the set F = { 0, -1/3, +1/3, -oo, +oo, NaN } a valid "number format" at level (A1)-A5) ?
5) Do your (B1)-(B5) definitions define "number format" format as a finite subset set of floating-point data (Level 2 of IEEE754-2008 ) ?
6) Is the set { -0, +0, -oo, +oo, NaN } (with some rounding) the minimal valid "number format" at level (B1)-(B5) ?
7) I guess that the set { -0, +0, -1/3, +1/3, -oo, +oo, NaN } is not valid "the number format" at level (B1)-(B5).
Is it ?
8) Is IEEE754 Binary64 with excluded subnormals a valid "number format" at level (B1)-(B5) ?
9) Let is take two subsets of IEEE754-2008 floating-point data that correspond to Level2 Binary64 and Level2 Decimal64 .
Is their union is a valid number format at level (B1)-(B5) ?
10) You answered in another mail that Java types "int", "long", "BigInteger", "BigDecimal"
are not valid "P1788 number formats" because they don't contain special vales.
Nevertheless, the rationale says that
>> the constraints ...
>> allows conventional formats, such as floating-point numbers (with
>> or without subnormals), fixed-point numbers (including integers),
>> rational numbers (with bounded numerator and denominator),
What does it mean (especially "including integers") ?
-Dima
----- Исходное сообщение -----
От: rbk@xxxxxxxxxxxx
Кому: rbk@xxxxxxxxxxxxx
Копия: stds-1788@xxxxxxxxxxxxxxxxx, wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx
Отправленные: Вторник, 17 Апрель 2012 г 1:41:42 GMT +04:00 Абу-Даби, Маскат
Тема: Correction --- Motion P1788/M0033.01:NumberFormat -- discussion period begins
Juergen, P-1788
Sorry, this motion was seconded by Michel Hack, not
Bo, as I stated in my original motion.
Baker
P-1788:
Since Motion 33 has been made by Vincent Lefevre and
seconded by Michel Hack, the discussion period now
begins, and will end after Monday, May 7, 2012.
I append the motion.
Discussion on this motion will proceed according to the rules for
position papers.
Juergen: Please place the motion and associated information
in the appropriate place on the web page, as
you have aptly done in the past.
Acting secretary: Please record the transaction in the minutes.
As usual, please contact me if you need the password to the private
area of the P-1788 web site.
Best regards,
Baker (acting as chair, P-1788)
---------------------------------------------------------------
> On 04/11/2012 07:44 PM, Vincent Lefevre wrote:
>> Note: Here, IEEE 754 is IEEE 754-2008 (currently the latest version
>> of the IEEE 754 standard). Since not everyone can read Unicode symbols,
>> the infinity symbol is denoted oo (not inf, because inf is also an
>> operation defined by P1788).
>>
>> Motion
>> ======
>>
>> An argument or a result of some operations covered by the standard
>> can be a number. A number is defined at Level 1 as being any member
>> of the set Rbar = R U { -oo, +oo } of extended reals. This motion
>> defines the corresponding notion at Level 2, called "number format"
>> and denoted here F. For an inf-sup interval type, the bounds are
>> the members of a number format F. An implementation must support
>> at least one number format F. The requirements and recommendations
>> are:
>>
>> A1. F corresponds to a finite subset of R together with 3 special
>> datums: -oo, +oo (the infinities of Rbar) and NaN (not-a-number).
>>
>> A2. A datum can have different variants or different representations
>> (e.g. IEEE 754 qNaN / sNaN, cohorts for decimal floating-point
>> numbers, signed zeros), but they are not distinguished in F, possibly
>> except for the number 0, which may be regarded as signed by the P1788
>> implementation; in such a case, it has exactly two possible values,
>> denoted -0 and +0. When 0 is unsigned, the notation -0 or +0 can be
>> used and simply denotes 0.
>>
>> A3. The number 0 (either a single element 0 or the two elements -0
>> and +0) must be in F.
>>
>> A4. The format must be symmetric, i.e. if a real x is in F, then -x
>> is also in F.
>>
>> A5. An element of Rbar (Level 1) is mapped (rounded) to an element
>> of F (Level 2) according to the following rules:
>> * A constraint can be given on the rounding direction. It must
>> be satisfied.
>> * Following this constraint, the rounded result should be an
>> element of F that is the closest to the exact result (with
>> a special implementation-defined rule for the distance to
>> an infinity).
>> * In general, this element is unique, but there may exist two
>> elements satisfying this property (halfway cases). How these
>> cases are rounded should be documented by the implementation.
>>
>> The notion of a 754-conforming implementation has been introduced
>> in Motion 6.04. A 754 format must have the following additional
>> requirements:
>>
>> B1. The infinities correspond to the IEEE 754 infinities.
>>
>> B2. NaN corresponds to the IEEE 754 Level 2 NaN. At IEEE 754 Level 3,
>> it can be either qNaN or sNaN, but if a NaN is produced as a result,
>> it must be a qNaN (except documented otherwise by P1788).
>>
>> B3. The number 0 is signed.
>>
>> B4. Concerning A5, for each operation where an interval of type T is
>> involved, there must be at least one number format F (the one of the
>> interval bounds for inf-sup, or documented by the implementation for
>> implicit interval types) such that the rounding must be done according
>> to the rules given by the IEEE 754 standard (correct rounding).
>> In the case of rounding-to-nearest (no constraints on the direction),
>> which rounding function (among the two possible rounding-direction
>> attributes) is used must be defined by the implementation.
>>
>> The notion of number format F compatible with an interval type T can
>> be defined, if need be. The idea is to require F to be dense enough
>> in order to satisfy some properties when returning a numeric value.
>> Later motions can require that for some specific operations, F must
>> be compatible with T (but shouldn't if this isn't really necessary).
>> A number format F is said to be compatible with an interval type T
>> if:
>>
>> C1. For each non-empty interval I of type T (Level 2), there exists
>> a finite number x of F such that x \in I.
>>
>> Later motions may define other constraints (when need be).
>>
>> Rationale
>> =========
>>
>> The above constraints have been chosen not to be too strict in order
>> to allow conventional formats, such as floating-point numbers (with
>> or without subnormals), fixed-point numbers (including integers),
>> rational numbers (with bounded numerator and denominator),
>> double-double numbers (provided by the "long double" C type in the
>> current PowerPC ABI).
>>
>> A1. We require the subset to be finite is order to be able to specify
>> the rounding without ambiguity. A discrete subset would be sufficient
>> for this purpose, but P1788 will probably also need the notion of
>> smallest and largest finite element (see the discussions about the
>> midpoint). Arbitrary precision formats need to be parameterized (for
>> instance, by the precision and possibly the exponent size), so that
>> each format instance is finite.
>>
>> A2. Ideally, one should not need to distinguish -0 and +0 as far
>> as P1788 is concerned, but this is done mainly for 754-conforming
>> implementations.
>>
>> A3. The number 0 will probably be needed for some functions. And it
>> would be awkward not to require it anyway.
>>
>> A4. Symmetry may not really be necessary, but it may expected by the
>> user, and all known formats are symmetric (well, in general, not the
>> native C integer types, but this is the cause of various bugs and
>> they don't have infinities and NaN anyway).
>>
>> A5. Correct rounding is recommended, but not required because it may
>> be difficult or may not really be useful in exotic number formats.
>> For 754-conforming implementations, it is however required for some
>> number format associated with the interval type T, but not necessarily
>> for all supported number formats, so that we do not disallow things
>> like mixed radix.
>>
>> C1. A consequence: one can define a Level 2 midpoint that belongs to
>> any non-empty interval of type T.
>>
>> Note: The standard doesn't define operations on the number format
>> itself (e.g. the additions of two numbers). That's why the motion
>> doesn't contain any requirement concerning such operations.
>>
>
>
--
---------------------------------------------------------------
Ralph 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
---------------------------------------------------------------