Re: mid-rad, inf-sup, a caution...
John Pryce wrote:
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?
Has anyone in this forum ever worked with a mechanical engineer or
architect, or seen the computer software tools they use? In those
applications and domains, tolerancing of parts is almost always done in
mid-rad, e.g.,
http://www.youtube.com/watch?v=H7f5cjspuAs&feature=related
we should be so lucky that some of the largest and most successful software
companies in the world, such as Autodesk, Dassault Systems, Parametric
Technology, etc. would some day use our P1788 standard. Having at least an
interchange format for mid-rad with standardized conversion rules I suspect
would be a minimal requirement.
I would also point out that at least in this sense, mid-rad as an
"interchange format" is already a global, multi-billion dollar industry.
Something that can't be said for inf-sup.
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.
In terms of interval hardware, mid-rad has an ability to encode an interval
in much fewer bits than inf-sup. This means more intervals can be stored in
memory, and bandwith to and from the processors will be better than for
inf-sup. So this in my view is a strong reason to consider that there will
someday be a competitive advantage for vendors who wish to support hardware
implementations of mid-rad over inf-sup.
How this may or may not impact P1788, I'm not sure. But it seems to me worth
looking at.
Nate