[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
test failures
From: |
John W. Eaton |
Subject: |
test failures |
Date: |
Mon, 23 Feb 2009 16:40:23 -0500 |
On 22-Feb-2009, John W. Eaton wrote:
| After the latest sparse changes, I see the following failures:
|
| >>>>> processing /export/home/jwe/src/octave/scripts/sparse/svds.m
| ***** testif HAVE_ARPACK
| [u2,s2,v2,flag] = svds(a,k,0);
| s2 = diag(s2);
| assert(flag,!1);
| assert(s(k:-1:1), s2, 1e-10);
| !!!!! test failed
| eigs: sigma must be a scalar or a string ***** testif HAVE_ARPACK
| idx = floor(n/2);
| % Don't put sigma right on a singular value or there are convergence
| sigma = 0.99*s(idx) + 0.01*s(idx+1);
| [u2,s2,v2,flag] = svds(a,k,sigma);
| s2 = diag(s2);
| assert(flag,!1);
| assert(s((idx+floor(k/2)):-1:(idx-floor(k/2))), s2, 1e-10);
| !!!!! test failed
| eigs: sigma must be a scalar or a string
|
| Could someone else take a look a the failing svds tests?
I looked at this in more detail and now I see that the reason these
tests are failing is because we now have
octave:1> 1 / sparse (2)
ans = Compressed Column Sparse (rows = 1, cols = 1, nnz = 1 [1e+02%])
)
(1, 1) -> 0.50000
and previously this returned a scalar (not sparse). This seems to be
incompatible with Matlab. But I'm not sure we should care too much
about that since it does not seem to consistently return a scalar for
mixed "sparse scalar" by scalar operations.
I see that eigs fails because we have this code:
if (args(2+arg_offset).is_real_scalar ()
|| args(2+arg_offset).is_complex_scalar ())
{
sigma = args(2+arg_offset).complex_value ();
have_sigma = true;
}
else if (args(2+arg_offset).is_string ())
{
typ = args(2+arg_offset).string_value ();
// Use STL function to convert to upper case
transform (typ.begin (), typ.end (), typ.begin (), toupper);
sigma = 0.;
}
else
{
error ("eigs: sigma must be a scalar or a string");
return retval;
}
and is_real_scalar is failing for a "sparse scalar". So maybe the
best fix is something like
2009-02-23 John W. Eaton <address@hidden>
* DLD-FUNCTIONS/eigs.cc (Feigs): If sigma argument is not a
string, try extraction as complex value and check for error
instead of inquiring about type first.
diff --git a/src/DLD-FUNCTIONS/eigs.cc b/src/DLD-FUNCTIONS/eigs.cc
--- a/src/DLD-FUNCTIONS/eigs.cc
+++ b/src/DLD-FUNCTIONS/eigs.cc
@@ -452,13 +452,7 @@
if (!error_state && nargin > (2+arg_offset))
{
- if (args(2+arg_offset).is_real_scalar ()
- || args(2+arg_offset).is_complex_scalar ())
- {
- sigma = args(2+arg_offset).complex_value ();
- have_sigma = true;
- }
- else if (args(2+arg_offset).is_string ())
+ if (args(2+arg_offset).is_string ())
{
typ = args(2+arg_offset).string_value ();
@@ -469,8 +463,15 @@
}
else
{
- error ("eigs: sigma must be a scalar or a string");
- return retval;
+ sigma = args(2+arg_offset).complex_value ();
+
+ if (! error_state)
+ have_sigma = true;
+ else
+ {
+ error ("eigs: sigma must be a scalar or a string");
+ return retval;
+ }
}
}
After checking in this change, I sometimes see errors like this:
octave:17> test svds
warning: returning fewer singular values than requested
warning: try increasing the value of sigma
***** testif HAVE_ARPACK
[u2,s2,v2,flag] = svds(a,k,0);
s2 = diag(s2);
assert(flag,!1);
assert(s(k:-1:1), s2, 1e-10);
!!!!! test failed
assert (s (k:-1:1),s2,1e-10) expected
38.034
38.034
38.015
38.015
38.004
38.004
but got
38.060
38.034
38.034
38.015
38.015
38.004
38.004
Dimensions don't match
These failures appear to be random. I don't see why this is happening.
Comments?
Thanks,
jwe
- test failures, John W. Eaton, 2009/02/22
- test failures,
John W. Eaton <=