Re: Siegfrieds recent paper
On 2012-01-03 00:26:32 +0100, Siegfried M. Rump wrote:
> A happy and successful New Year 2012 to everybody!
Happy New Year!
> >P1788 delivers
> >
> > A = infsup(0,1000); % [0,1000]
> > B = exp(A); % [1,inf]
> > C = 1/B; % [0,1]
> > D = 1/C; % [1,inf] with decoration
> > E = 1/D; % [0,1] with decoration
>
> Is the decoration "possiblyUndefined" ? It bothers me that I have to
> ask for that :(
Yes.
> In any case, the evaluation of E is a (complicated) way to evaluate
> f(x)=1/(1/1/exp(x)))=exp(-x). In my proposed arithmetic E=[0,1]
> without decoration, so f(A) is included in A and proves that
> f=exp(-x) has a fixed point in A=[0,1000]. The proof is rigorous
> without necessity to check a decoration.
This is a particular example. I think that in most of the cases,
your arithmetic won't bring anything better. And you may generate
unnecessary NaI's, e.g. when one knows from the context that the
result is well-defined (i.e. when undefinedness in some operations
comes from the fact that intervals are supersets of the range of
the real results).
> I don't like the idea that decorations have to be checked. My
> experience with it some time ago is that I did Arnold a favour and
> put some decorations into INTLAB. After less than a month I forgot
> about my own implementation and wrote a potentially erroneous
> program because I forgot to check decorations. Consequently I
> removed it from INTLAB again.
Just consider that a possiblyUndefined decoration means NaI in your
case. You can define a function fixed_point_test that checks the
inclusion and the decoration. That would be really clear IMHO.
> I like to follow the KISS principle, i.e. all interval results
> should be valid as is.
With P1788, they are.
--
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 / Arénaire project (LIP, ENS-Lyon)