Re: Will someone make a formal motion? Re: mid-rad, inf-sup, a caution...

[Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>]

> Subject: Re: Will someone make a formal motion? Re: mid-rad, inf-sup, a caution...
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Wed, 12 May 2010 07:26:42 +0100
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> P1788
> 
> On 11 May 2010, at 23:04, Ralph Baker Kearfott wrote:
> > Would someone care to make a motion along the following lines?
> > 
> > "Conversion between midpoint-radius text format and standardized
> > inf-sup numbers and conversion between standardized inf-sup
> > numbers and midpoint-radius text formats will be standardized.
> > Otherwise, the standard will be silent concerning midpoint-radius
> > representations and midpoint-radius arithmetic."
> > 
> > I think we should have such a motion now while the discussion is
> > fresh in peoples' minds, and such a motion would supply needed
> > guidance.  Whomever (if anyone) moves it should feel free to
> > alter it in any way, including removing "not"  (i.e. affirming
> > standardization of mid-rad), referring to the Vienna proposal,
> > etc.
> 
> I would support such a motion. Dan, thanks for offering to move it.

	You're welcome.  At the very least it will focus
	the discussion.  Which is what I believe Baker
	had in mind anyway.

> 
> I think the recent discussion has shown that mid-rad is very valuable
> but its applications don't overlap much with what our standard is about.
> No case has been made for supporting *software* that provides the full
> range of arithmetic, standard functions, etc., with *rigorous enclosure*,
> using a mid-rad representation of *real* intervals. If that were worth
> doing, practical systems would have appeared long ago to compete with
> the inf-sup ones. 
> 
> But the case for standardizing as Baker proposes is strong.
> 
> I looked briefly at GD&T (geometric dimensioning and tolerancing) pages
> on the Web and saw
> - Tolerances are lengths. So what is physically meaningful is to make
> linear combinations of (length+tolerance) -- mostly add & subtract,
> but also rotate a vector of them. Maybe one could multiply to get
> tolerances whose dimension is area or volume; but more complicated
> things, like log(length+tolerance), hardly make sense in that
> engineering context.
> - Rigorous enclosure is totally irrelevant.
> - mid-rad, strictly, is irrelevant, because a one-sided tolerance on
> a nominal value is the rule rather than the exception. The
> Vienna-recommended "triple" is more relevant.
> 
> The other applications people have cited confirm this, IMO.

	BTW, in my less than professional life, I am also a
	machinist.  (I have been involved in building a large
	telescope for the past 2 decades.  Long story.  Don't
	ask. :-)  And you should know that meeting the written
	tolerances doesn't always guarantee that the parts fit
	together.  But mechanical people are known to be
	practical about it.  If the bolt doesn't fit, they
	throw it away & use another that does.  If two plates
	don't quite mate, they drill & tap new holes.  It is
	rare but it happens.

	Still, for us, perhaps this is in keeping with the
	observation that mid-rad doesn't always assure
	containment.

	Then again, perhaps the machinists just make mistakes. :-)

> 
> Nate, you cite GD&T as contributing to a multi-billion dollar industry.
> I respect it as such. I also respect video gaming and film animation
> as multi-billion dollar industries; but I wouldn't use their models
> of Newton's laws of motion as the basis of landing a rocket on Mars.
> It's horses for courses.
> 
> Nate, you point out mid-rad can save memory, hence bandwidth, on large
> interval calculations. But the saving is always less than 50%, ne c'est
> pas? because one has to store the "mid" value to full precision. If you
> had a method that saves an order or two of magnitude, it would be more
> convincing. But that usually comes from an improved algorithm.
> 
> John

	Nate's observation flows from the presumption that
	a narrow interval can be more compactly encoded
	than with inf-sup.  Well, that & the presumption
	that adequately narrow intervals are common enough
	to justify the recoding.

	Both are probably true.  At least, on the average.

	If so then is it desirable to do the arithmetic in
	inf-sup & convert to mid-rad on storage?

	The tradeoff would seem to be between the cost of CPU
	power & cost of memory.  Of the two, I think memory
	is getting cheaper faster than CPUs.  At least that
	has been true in the past.

	Still, it is a reasonable approach.  Cost aside, the
	memory required may be the thing that sets the limit
	on what can be done on a given system.


				Dan