octave-maintainers
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]