Re: Explicit vs Implicit bounds on range and precision
I agree with everything Dan Zuras wrote in his reply,
BUT I'm afraid he missed my point COMPLETELY:
> So you move your entire problem to a 1200 digit precision
> type with a 7 digit exponent range together with 100 digits
> & 4 exponent digits in the radius.
The critical part of my post was not even quoted in Dan's reply:
MH:
>> DZ: > But the limits are there all the same.
>>
>> Ok, so among format-derived constraints we should include
>> EXPLICIT bounds on precision and range.
>>
>> Many systems do have such controls -- but NOT ALL.
What I'm concerned about is formats that DON'T HAVE A SPECIFIABLE LIMIT
to range or precision. Most such formats are perhaps not relevant to
the REAL arithmetic that P1788 deals with -- they are either restricted
to integers, rationals (e.g. represented as pairs of integers, or a
finite set of Continued Fraction coefficients), or similar entities.
One such entity that *is* relevant however is Exact Real Arithmetic.
Typical representations are spigot algorithms that deliver better and
better rational approximations (here CF representations are ideal),
effectively using deferred evaluation with backtracking as needed.
Asking such a system to return the tightest interval leads to infinite
regress and must thus be avoided.
In other words, what Dan ASSUMES to be there (an explicitly specified
bound on precision and/or range) must be REQUIRED to be there for the
definition of "tightest" to make sense. Running out of resources does
not count because, as Vincent pointed out, that leads to non-predictable
behaviour.
Michel.
P.S. There is another booboo in Dan's examples: mid-rad representations
where the radius has a smaller exponent range than the midpoint.
Unless the radius is RELATIVE this won't work very well, as the
only valid enclosure for large midpoints would be Entire. Trouble
is, relative radii have trouble with zero-centered intervals...
I think Arnold's triplex formats can deal with this.
That's a completely different topic however.
---Sent: 2010-07-15 03:31:59 UTC