Re: Unbounded intervals
On 2012-04-26 10:03:40 -0500, Nate Hayes wrote:
> Vincent Lefevre wrote:
> >On 2012-04-25 09:05:19 -0500, Nate Hayes wrote:
> >>A few points:
> >>
> >> -- No computer (that I'm aware of) can numerically prove hardly
> >>anything
> >>useful about the domain of a function beyond the underlying numeric
> >>limits
> >>of the system; so for this reason alone, truly unbounded intervals are
> >>never
> >>necessary in numeric models or computations (you have never answered my
> >>original question from long ago to show a counter-example of this).
> >
> >I disagree. If the user asks for the range of 1/[0,1], the math result
> >is [1,+inf]. This is useful information, at least much more than an
> >error.
>
> You've avoided the question again.
I'm not avoiding it. This is a perfect answer to your question.
Others have given other examples.
> The question is, what is an example of an interval algorithm, for
> example, that proves all the zeros of a function on the domain
> [MAXREAL,+Inf].
This question is pointless. If there is an unbounded interval in
the problem, then you need unbounded intervals to be able to express
the problem!
Algorithms will obviously depend on the function, on the implementation
parameters (e.g. whether you have enough precision or not), and so on.
There are well-known techniques such as scaling (look at the MPFR code,
for instance). There are also implementation limits.
> Vincent Lefevre wrote (cont.):
> >You may build a theory where the computed result as a *family* of
> >intervals, but then you should stop calling that an interval. This
> >is obviously more complex (as a specification) than unbounded
> >intervals and I don't see what it would bring.
>
> During the course of this discussion, it appears your position changed from
> unbounded intervals are "essential" to "they make algorithms more easy to
> define at Level 1." But my observations are that both these statements are
> not true.
It has not changed. Simplicity is essential.
> >>for this reason it is possible to define
> >>midpoint([1,+OVR]) at Level 1 in the same way P1788 is currently
> >>considering to do so at Level 2.
> >
> >How would you define it at Level 1, as a *real number*?
> At Level 2 P1788 has considered to define midpoint([1,+Inf]) = (1+REALMAX)/2
> or something similar.
No, it is REALMAX, if one really wants the midpoint to be defined.
> At Level 1, midpoint([1,OVR]) could for the same reasons be
> similarly be defined (1+H_f)/2.
This would be bad, even if you define it as H_f (a bit like in Level 2),
because at Level 1, you have intervals like [1,4*H_f], whose Level 1
midpoint is 2*H_f+1/2 > H_f. Thus conventional inequalities (see the
discussion about midpoint) would no longer hold at Level 1.
> >> -- Replacing "midpoint" with "any member of the interval" gives a
> >>valid
> >>mathematical definition of the Interval Newton, but such a definition is
> >>also then no longer an algorithm because the exact method of choosing
> >>"any
> >>member of the interval" is left undefined.
> >
> >Well, once the one who writes the algorithm choose the member in
> >question, he has an algorithm. This member can potentially be a
> >parameter, and it will still be an algorithm. I don't see any problem
> >with that!
>
> The problem is one cannot choose midpoint as this parameter at Level 1
> without causing the Interval Newton to be undefined when unbounded interval
> is provided as input.
This is not a problem. You don't necessarily need a midpoint at
Level 1 for this algorithm.
> You are the one who said unbounded intervals are important to ensure
> algorithms are easy to define at Level 1. But this is clearly not
> always the case.
The problem is just with your reasoning.
--
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)