| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear all,
I realise that few people are familiar with
mid-rad computations. Sunaga original
paper is probably the best source.
For engineers it will be interesting to see how
Sunaga computes rigorously in mid-rad arithmetic.
We reworded his method in our paper:
Markov, S., Okumura, K.: The Contribution of T. Sunaga to
Interval Analysis and Reliable Computing, in: Csendes, T. (ed.),
Developments in Reliable Computing, Kluwer, 1999, 167--188.
There in section:
3. Sunaga’s Proposal for Application of Interval Analysis to Reliable
Numerical Computation
we described Sunaga's rigorous method. I strogly recommend
engineering specialist to look at Sunaga's method. I attach
a pre-published copy of the paper (without photo of Sunaga).
Regards,
Svetoslav
On 11 May 2010 at 12:36, Svetoslav Markov wrote:
From: "Svetoslav Markov" <smarkov@xxxxxxxxxx>
To: John Pryce <j.d.pryce@xxxxxxxxxxxx>, 1788 <stds-
1788@xxxxxxxxxxxxxxxxx>
Date sent: Tue, 11 May 2010 12:36:59 +0300
Subject: Re: mid-rad, inf-sup, a caution...
Priority: normal
> 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
>
Attachment:
MKOHSH99.pdf
Description: Binary data