From bug-octave-request at bevo dot che dot wisc dot edu Thu Sep 26 19:46:05 2002
Subject: Re: Test results for OS X
From: Per Persson <persquare at mac dot com>
To: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>,    John Eaton <jwe@bevo.che.wisc.edu>
Cc: bug-octave at bevo dot che dot wisc dot edu
Date: Thu, 26 Sep 2002 16:50:55 -0500

Thanks for the feedback and patch. With the patch, I still get the 
occasional FAIL in qr-7.m for the complex cases. However, the new 
testcase (rosser) fails too. Looking at the numbers I find roughly 2 
times the expected error...

octave:4> norm(q*r-a)
ans =  7.0957e-13
octave:5> eps
eps =  2.2204e-16
octave:7> ans/eps
ans = 3195.6

Since I'm running all kinds of tests, I also linked octave with ATLAS 
and, lo and behold, the rosser case passes!  On the other hand, there 
were some new failures:
FAIL: octave.test/linalg/schur-1.m
FAIL: octave.test/poly/residue-1.m
FAIL: octave.test/poly/roots-1.m
(haven't looked into any details yet)

While I'm at it, I'm going to try and link octave with the vecLib 
framework* provided by Apple to see what happens...

FYI, ATLAS did give a speed-up of approx 2x for the simple tests I 
performed.

Stay tuned!
Per

* The vecLib framework (a framework is an aggreagation of headers, 
libs, documentation etc, invoked with --with-blas='-framework vecLib' ) 
utilizes the AltiVec vector processing unit available on the PPC G4.

On Thursday, September 26, 2002, at 05:21 PM, Paul Kienzle wrote:

> On Wed, Sep 25, 2002 at 06:15:58PM -0500, John W. Eaton wrote:
>> On 25-Sep-2002, Per Persson <persquare at mac dot com> wrote:
>>
>> | FAIL: octave.test/linalg/qr-7.m
>> | --- fail for n=[1, 3, 5, 7]
>> | worst case n=1
>> | tol =  1.1369e-13
>> | n1 =  5.4872e-13
>> | n2 =  5.4773e-15
>>
>> Are these reasonable?  Should the tolerance be changed?
>
> Running through a couple of different 5000x20 random matrices, I
> occasionally get near the tolerance, so I'm not surprised that
> the occasional difficult matrix is generated, so these results
> are reasonable.
>
> We should probably eliminate the huge matrix tests.  I included
> them just to show that lapack could handle huge matrices if we
> call it correctly.  The old version of the qr routines would still
> succeed with these tests, they would just take a very long time
> to do it.
>
> Using just the 'tough' lauchli(15) matrix test, I get tolerances of 
> less
> than 10*eps on my machine.  An even better test is the rosser matrix
> (available on octave-forge) which is an 8x8 matrix for which 
> norm(q*r-a) is
> 4e-13 on my machine.  I'll put in a test for this against 2000*eps.
>
> The enclosed patch does these changes.
>
----
Per Persson
Blekinge Institute of Technology
Dept. of Signal Processing and Telecommunications

www:   http://www.its.bth.se/staff/pee
e-mail: per dot persson at bth dot se



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------