Re: Will someone make a formal motion? Re: mid-rad, inf-sup, a caution...
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.
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.
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
John
- References:
- Re: mid-rad, inf-sup, etc.
- Re: mid-rad, inf-sup, etc.
- mid-rad, inf-sup, a caution...
- From: Dan Zuras Intervals
- Re: mid-rad, inf-sup, a caution...
- Re: mid-rad, inf-sup, a caution...
- Re: mid-rad, inf-sup, a caution...
- Re: mid-rad, inf-sup, a caution...
- Will someone make a formal motion? Re: mid-rad, inf-sup, a caution...
- From: Ralph Baker Kearfott