Re: Motion P1788/M0032.02: I vote NO
> > (b) if you treat the singletons as defining a number format
> > F=myFormat(T), it may be tricky for it to interoperate with ordinary
> > FP formsts.
>
> I agree. Actually I see some theoretical interest in Dmitry's idea.
> But in practice, I'm wondering... Would there any algorithm use his
> idea?
For now I know only one application of myFormat(T). This is centered point algorithm.
Center form solves the problem:
Input: f(x) - expression for f; g(x) - expression for df/dx ; interval X.
Output: Interval extension of f(X).
The mathematical (Level 1) formulation of centered form algorithm is
(1) return f(mid(X)) + (X - mid(X))*g(X)
Here f(mid(X)) is a point calculation of f.
Computer implementation of centerd form actually uses another formulation
(2) C = [mid_F(X),mid_F(X)]; return f(C) + (X - C)*g(X)
f(C) is an interval calculation of f that takes into account rounding errrors.
So computer implementations already use singleton C of datatype T.
We can consider it as value of myFormat(T).
The (2) works only when mid_F(X) \in X .
This condition \m in X may fail for offcenter intervals X=[a+b,a+c], where a, b, c \in F.
Is it necessary to switch from interval X of datatype T to number format mid_F(X) and
then return again to T-interval [mid_F(X),mid_F(X)] ?
We can use instead
(3) C = cent_T(X); return f(C) + (X - C)*g(X).
where cent_T(X) is an operation that maps T-interval X to T-singleton closest to level 1 mid(X).
We can consider cent_T(X) as mid_{myFormat(T)}(X) .
The cent_T([a+b,a+c]) will return T-singleton [a+roundNearest_F((b+c)/2),a+roundNearest_F((b+c)/2)]
for offcenter intervals X=[a+b,a+c], where a, b, c \in F .
The "point a+roundNearest_F((b+c)/2)" is contained in X so (3) is correct.
This solves the issue with offcenter intervals.
-Dima
----- Исходное сообщение -----
От: vincent@xxxxxxxxxx
Кому: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Понедельник, 16 Апрель 2012 г 18:54:24 GMT +04:00 Абу-Даби, Маскат
Тема: Re: Motion P1788/M0032.02: I vote NO
On 2012-04-16 07:05:29 +0100, John Pryce wrote:
> P1788
>
> On 16 Apr 2012, at 04:49, Michel Hack wrote:
> > I vote NO on M0032.02 -- the main issue for me being that the Level 2
> > midpoint might not be a member...
> >
> > Some of these difficulties might be cleared up if we firm up what
> > counts as a legitimate number format and a legitimate interval
> > format. For example, must we support off-center intervals
> > [a+b,a+c] with b and c of the same sign?
>
> On this last Q, I would say No, why should we, seeing what troubles
> they seem to cause? I would support the kind of restrictions on
> number format that Vincent, Dmitry and others are proposing.
I don't think they (as intervals) cause any specific trouble.
You need to make the difference between:
1. The troubles caused by some interval type.
2. The troubles caused by the relation between some interval type
and some number type.
The mentioned problems in recent discussions fall in (2), not in (1).
> Dmitry's idea "every nonempty interval of any type must contain a
> singleton interval of the same type" is different, being a
> restriction on interval types T rather than on number formats.
Yes.
> I'm a bit dubious,
Me too.
> because (a) it may be quite tricky to check for a given proposed T,
I'm not so sure.
> (b) if you treat the singletons as defining a number format
> F=myFormat(T), it may be tricky for it to interoperate with ordinary
> FP formsts.
I agree. Actually I see some theoretical interest in Dmitry's idea.
But in practice, I'm wondering... Would there any algorithm use his
idea?
> However, both those are really the problem of whoever invents T, not
> of 1788, so I could be convinced.
Yes. But problems are specific to some operations and/or algorithms.
And some operations and/or algorithms do not necessarily make sense
with some types. For instance, users of mid-rad probably use it for
approximations with guaranteed results, and are not interested in
splitting.
--
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)