Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Request for motion [Fwd: Input from IFIP WG 2.5 to IEEE Interval Standards Working Group]

Jim (et al),

Thank you for the info and perspective.

Best regards,

Baker

James Demmel wrote:
Thanks to Chenyi and Dan for their comments. I wanted to raise the BLAS 1/2/3 issue, because if we want folks to begin developing software using interval tools, rather than making them relive the EISPACK/LINPACK/LAPACK experience of doing it first with BLAS 1, and eventually with BLAS 3, we might want to let developers skip directly to BLAS 3.
The larger cost of an interval operation vs a floating point operation means that the relative benefit of BLAS 3 over BLAS 1 will be less with intervals than floats. But since the speed of flops is increasing at about 60%/year, vs 23%/year for DRAM 
bandwidth and perhaps 7%/year for DRAM latency, the relative benefit of
BLAS 3 over BLAS 1 will only grow. (Note: this data is from pre 2004 processors, 
so a bit old, but the same trend holds).
Also, there is "autotuning" technology (eg ATLAS) to automatically tune BLAS, that might simplify producing fast interval code. The rapid change in processor technologies is 
leading many groups to work on developing such tools.
On the other hand, I am not volunteering to do any of this work, so please take 
my advice with an appropriate grain of salt :) .

Jim


Chenyi Hu wrote:

Dan, et al,
Just for your information, about a decade ago, Jim and I were on the BLAST working group led by Jack. That group tried to establish an Interval BLAS standard including BLAS-1, -2, and -3. The final document is available at http://www.netlib.org/blas/blast-forum/chapter5.pdf. Also, my former graduate student Michael Nooner made a reference implementation which is available at http://www.cs.uca.edu/interval/intbox/ with documentation. We further described the design and implementation as chapter 10 in the book "Knowledge Processing with Interval and Soft Computing" published by Springer last year. Since we did not have a standard on interval computing, the Interval BLAS was listed under Journal of Development in the final document of BLAST. 
Regards,

Chenyi
Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx> 9/10/2009 10:26 AM >>> 
Date: Thu, 10 Sep 2009 09:43:41 -0500
From: "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>
To: Chenyi Hu <chu@xxxxxxx>
CC: James Demmel <demmel@xxxxxxxxxxxxxxx>,
        Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>,
        Nathalie Revol <Nathalie.Revol@xxxxxxxxxxx>,
stds-1788@xxxxxxxxxxxxxxxxx, Ronald Boisvert <boisvert@xxxxxxxx>, 
        Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
Subject: Re: Request for motion [Fwd: Input from IFIP WG 2.5 to IEEE Interval 
 Standards Working Group]

Chenyi, Jim, et al,

Yes, we are taking a step-by-step approach.  Also, the dot product
is  BLAS level 1 operation, and we have been given a request to
consider it :-)

The officers have been discussing among themselves the most
efficient way of doing the steps, to come to consensus and
a high-quality final document.  One possibility is, essentially,
voting on pieces of the Vienna proposal.  I note the Vienna
proposal contains statements concerning the accurate dot product.

Concerning BLAS level 2 and BLAS level 3, we'll need to decide
if this is within our scope and whether it is practical to do
by the document's delivery date to the Sponsor.

Sincerely,

Baker



    Begin IMHO

    The opening of this rather large can of worms is one of
    the reasons I initially wondered if now is the right time
    to consider these operations.

    Still, the issue of whether or not interval versions of
    the BLAS 2 & 3 operations are within the scope of 1788
    or not would seem to me to depend on the collective
    expertise of our committee members.

    For while the higher BLAS functions are derivative in the
    same sense as Jim & company think of them, they are also
    likely to be implemented directly in floating-point rather
    than with our primative interval operations.

    I am no expert in this but I have learned enough about
    interval linear algebra to know that many of these functions
    are computationally intractable when implemented directly in
    interval primitives.  Rather, it is more likely that such
    operations will (at least internally) need to convert to a
    midpoint radius form & use accurate floating-point BLAS
    together with a Jacobian which will then have to be
    converted (conservatively) back into [xlo,xhi] form.

    Thus they will require all the expertise our interval
    experts can bring to the problem & is (IMHO) something we
    should provide for our otherwise inexperienced customers.

    Or, at the very least, something we should DEFINE for our
    users & provide example libraries for our implementors.

    End IMHO

    All this will be true whenever we tackle these problems.

    On the one hand, it might be better if we knew something
    about the details of 1788 before any BLAS are attempted.

    On the other hand, given that they are such an important
    application for our customers, those who attack this problem
    NOW can advise us of the effect of many of our decisions on
    their work.

    Chickens & eggs come to mind for some reason. :-)


                Dan