Re: Unbounded intervals
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.
> -- An overflown interval [1,+OVR] := { [1,a] | a >= H_f }, where H_f is
As an unknown bounded interval with an arbitrary bound, the result
for 1/[0,1] would be incorrect, because the computed result must
contain the mathematical result.
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.
> a parameterization of any would-be Level 2 format, is functionally
> equivalent to an unbounded interval but retains a notion of the "largest
> representable number";
I don't see how this notion of the "largest representable number" is
retained.
> 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*?
The only information that you would have is an unbounded interval
containing the midpoint.
> -- 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!
--
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)