Re: mid-rad, inf-sup, a caution...
Dear John,
On 11 May 2010 at 9:19, John Pryce wrote:
Subject: Re: mid-rad, inf-sup, a caution...
From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
Date sent: Tue, 11 May 2010 09:19:07 +0100
To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 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?
I have in mind some facts like:
- the simplicity of computations that engineers usually perform
by hand using the main value (midpoint) and a few digists
for the error bound. See. e. g. Sunaga paper.
- the few digits are really very few, say 1-3, see e. g. :
van Emden, M. H., On the Significance of Digits in
Interval Notation, Reliable Computing 10, 1, 45--58.
- the simplicity of the mid-rad formulae for arithmetic operations
vs sup-inf formulae;
- the FP standard for midpoint is available, it only needs to
be extended and completed so that the concept of an FP-number
is extended to the concept approximate number (which is actually
an interval).
- the interval quasilinear space naturally splits in
(is a direct sum of) the vector space of midpoints
and the quasilinear space of radiuses (error bounds), BUT
is not splitted in the spaces of endpoints!
> - Who will benefit?
IMO everybody will benefit. It is simpler to learn and use
mid-rad arithmetic, than inf-sup one.
Of course there will be problems, like those with infinite
intervals, but similar problems are with inf-sup.
Svetoslav
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