Re: mid-rad, inf-sup, a caution...

["Chenyi Hu" <chu@xxxxxxx>]

Dear All,

I'd like to make a few general comments on this topic:

First, interval is just a data type. Both mid-rad and inf-sup are two different representations of it. Interval arithmetic has  been traditionally applied to find reliable bounds. In which, obviously, inf-sup is a much preferred approach. However, interval computing can do much more than reliably bounding numerical solutions.  The article "You Queue" on page 8 of the April 2010 issue of SIAM News, the author wrote "UQ (Uncertainty Quantification) has become increasingly prominent at SIAM meetings,..." Using interval to describe uncertainty has been a common approach, such as confidence interval etc. In describing uncertainty, not rigorous bounds, the mid-rad presentation seems much more reasonable and practical than inf-sup.

Second, there have been some interesting results lately on using interval to model uncertainty. Although I hate to do self-promotion shamelessly, just for your reference, you might want to have a glance on the following (both available online): 

"Chapter 4: Interval Matrices in Knowledge Discovery," by Baker and me, in the  book "Knowledge Processing with Interval and Soft Computing" published by Springer. In that chapter, we discussed about using mid-rad approach to find approximate solutions for interval linear systems of equations and SVD/PCA for interval matrix. The computational approaches may not very suitable with inf-sup representation.

"Impacts of Interval Computing on Stock Market Variability Forecasting," J. Computational Economics, 2009 33:263-276. Ling T. He and I somewhat compared the mid-rad approach with min-max approach on the stock market forecasting. The mid-rad approach shows clear advantage.

Third, with the above in mind, I advocated mid-rad before in this group. I have to admit that I do not know much about hardware implementation. hence, I do not know how much work would be needed to make mid-rad in the standard. I still remember, when Arnold asked if the standard provide an conversion would meet the needs, I answered yes to this group.  

Last, but not the least, experts who knows the complexity of including mid-rad in the standards, please let us know how much more time we need for including mid-rad in the standard. I hope it will not 7 years as Dan mentioned in revising 754 to include decimal.  If I could make a choice, I'd say let us get a standard out as our first priority. Including mid-rad if it does not require too much extra time. Otherwise, leaving it for Version 2.0 might not be a bad idea. Especially, people can use conversion for applications other than finding reliable bounds.

Thanks for your time,

Chenyi

Chenyi Hu
 
Ph.D., Professor and Chairman
Computer Science Department
University of Central Arkansas
http://www.cs.uca.edu