Re: mid-rad, inf-sup, a caution...
P1788
On 9 May 2010, at 18:41, Dan Zuras Intervals wrote:
> Hossam's analogy is an excellent one. The issue of mid-rad
> versus inf-sup is, for us, very VERY much like the the issue
> of binary versus decimal was for 754. Like binary & decimal,
> mid-rad & inf-sup each have their adherents & appripriate
> application areas. Not only are the underlying mental models
> different in the two forms, the very concept of precision &
> range is defined differently with mid-rad being able to
> represent some intervals more precisely & others badly or not
> at all. Similarly, one cannot say that Decimal64 is more or
> less precise than Binary64 in that some numbers are more
> precise in one & some more precise in the other.
>
> His analogy is so good that I am persuaded that we should
> consider giving mid-rad full first class status.
>
> His analogy is also so good that a caution applies.
A.
I note that Baker originally wrote
> ... warrant standardizing separate *interchange* formats ...
That may be relatively easy - easier than making mid-rad a first-class companion to inf-sup. I should appreciate mid-rad experts clarifying some points about the specification that would be needed if it's ONLY interchange format we talk about:
- Who will benefit? Who wants to exchange interval data between systems, based
on mid-rad formats?
- Do we just cover formats based on the basic 754 FP formats,
or are multi-precision formats *essential*?
- Should we consider it normal that the midpoint m and radius r be of
*different* formats, e.g., m is binary<N> for large N and r is binary32,
say?
- Can we assume the radius is never less than about 1 ulp of the midpoint's
precision? I.e., if r gets very small, one stores m to increased precision
to match.
B.
Giving mid-rad first class status ("MRFCS") seems MUCH more problematic.
- Practical problem: It will seriously extend the project deadline.
- Theoretical problems: No unique hull operation. What to do with unbounded
intervals?
Svetoslav, you write
> Moreover, many facts lead me to conclude that mid-rad is a "primary type"
> deserving a "first class treatment"!
Well, will you please give some of these facts? Generally, I would like to know:
- Who will benefit? What group of people needs the portability of mid-rad
algorithms and code that is provided by MRFCS?
Not the multi-precision (M-P)people, as far as I can see, because they have various "proprietary" storage schemes. At least one is actually inf-sup. The ones based on triples are similar to, but not same as, mid-rad. Is the M-P community frustrated because of the difficulty of exchanging algorithms between different M-P systems?
Not people like Siegfried, because INTLAB only uses mid-rad inside an algorithm, but stores data and final results in inf-sup form.
Michel Hack observes that mid-rad expresses a different mental model from inf-sup. Important point, but how does that translate into a need to support software? I'm not saying it doesn't - probably I'm just ignorant.
Please stand up, the people who actually need MRFCS for practical computing, rather than as an abstract principle. Say how it will help you.
John