The conversions should be defined if
either inf or sup or both is an infinity, and if either M or R is an infinity,
and if inf and sup or M and R are NaNs. Are the specified conversions
the desired ones for those cases? It seems conversions from [inf,
sup] to (midpoint +/- radius) representation need to special case infinities.
For example, converting [-Infinity,
+Infinity] meaning the value could be anything to midpoint +/- radius representation
gives (NaN +/- NaN) when I would expect (0 +/- Infinity). Converting
(0 +/- Infinity) to [inf, sup] representation does give [-Infinity, +Infinity]
as I would expect.
It's less clear what the result of converting
[0, +Infinity] to midpoint +/- radius representation should be, but
(maximum_finite +/- maximum_finite) seems best, and converting that to
[inf, sup] representation would give [0, +Infinity] as long as the sup
calculation rounds up.
I'd prefer to see the standard define
two distinct types (per precision) "Interval" and "Approximate"
and have everybody implement both, instead of some doing one and some the
other. Their semantics are not quite identical, and calculations
using one will often differ from those using the other.
An interval is a tool, not a statement
of absolute truth. The (midpoint +/- radius) representation does
seem a better fit for approximations using Gaussian distributions with
standard deviation or half width of confidence interval or whatever, but
that's how it's thought of and used, not an intrinsic property of the representation.
Whether one uses an [inf, sup] range or a (midpoint +/- radius) representation,
one interval can be used to mean "I believe with certainty that the
true value is in this range." while another in the same program can
be used to mean "I believe that it's N % likely that the true value
is in this range."
- Ian Toronto
IBM Lab 8200 Warden D2-445 905-413-3411
Chenyi Hu <chu@xxxxxxx>
10/02/2009 09:45 AM
Please respond to
Chenyi Hu <chu@xxxxxxx>
To
Ian McIntosh/Toronto/IBM@IBMCA
cc
Subject
Re: the "set paradigm" is
harmful
Yes, as Baker suggested, I would like to make the
motion as the follow:
An interval can be represented in two ways in the IEEE-1788 standard. One
of them is its lower and upper bounds as [inf, sup]. The other is its midpoint
and radius as {M, R}. When the rounding error is ignored, the transformation
between these two representations are: M = (inf + sup)/2, and R = (sup
- inf)/2; and inf = M - R. and sup = M + R. To ensure enclosure property
in the [inf, sup] form, transformation from {M, R} form to [inf,
sup] form must consider rounding mode properly in implementation.
==============
The rationales for this motion have been discussed lately and in
Baker's comments.
Chenyi Hu
>>> Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx> 2/10/2009 7:43
AM >>>
Svetoslav et al,
I see several possibilities of accommodating midpoint-radius
representations in the standard. One might be to simply
specify two representations for intervals, and specify
conversion between the two. (That might be the simplest way.)
Does anyone care to make a formal motion to that effect?
If such a motion passes, we can then work out details.
There is another representation of intervals in use to avoid
having to change the rounding mode: [-inf,sup]. However, we
may be able to accommodate that representation within the [inf,sup]
representation by "as if" wording.
Baker
P.S. I'm not sure in exactly what places, if any, the issue of accommodating
midpoint-radius impacts the two motions currently
being
formally processed. (P1788/M0001.01_StandardizedNotation
and
P1788/M0002.01_ProcessStructure) The first deals
with the
notation to be used in the standards document and
the second deals
with the structure of the standards document (and
not its actual
content). If there is anything within these
motions that
impacts midpoint-radius, please be VERY specific about
where.
On 2/10/2009 3:53 AM, Svetoslav Markov wrote:
>
>
>
> On 9 Feb 2009 at 9:19, Michel Hack wrote:
>
>> Earlier I wrote:
>> ... when the radius exceeds either an absolute or
a relative threshold.
>>
>> Change "either" to "both". One applies
for small absolute values, the
>> other for the rest.
>>
>> Btw, I realise that one can also have an approximate number arithmetic
>> with containment properties, and that this is probably what Svetoslav
>> had in mind -- but my comments about restriction to narrow intervals
>> remain applicable.
>>
>> Michel.
>
>
> Surely, MR-presented intervals, resp. approximate numbers,
> admit probabilistic interpretation, e.g. midpoint can
> be mean value, in Gaussian distributions radius can be
> standard deviation or half-width of confidence interval, etc.
> (Note that the guaranteed containment property can be still there,
> say within the 95% of probability). Such interpretations depend on
the
> particular models/problems. MR-presentation supports various
> interpretations as summarized in Arnolds classification. Note that
> MR-form intervals incorporate the set paradigm --- up to the
> special cases (oo, a], [b, oo). That is why MR-form is even more
> important than sup-inf form. MR-form is more convenient than the
> sup-inf form in many applications (possibly for Taylor polynomials
> as well). Some authors often use this form as an intrinsic form in
> computations/proofs and then translate results in sup-inf form
> (notably J. Rohn). This form incorporates and enhances several
> suggestions made by U. Kulisch.
>
> Conclusion is: MR-presentation of intervals deserves (at least) equal
> consideration in the standard as the sup-inf form.
>
> Remark 1. Narrow intervals indeed have certain important properties.
>
> Remark 2. Centered multiplication may be optionally implemented,
> whereas the "true" interval multiplication should be (of
course) obligatory
> in the standard. Centered multiplication is only an approximation
of
> the true one, but is faster.
>
> Svetoslav
>
>
--
---------------------------------------------------------------
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
---------------------------------------------------------------