[Octave-patch-tracker] [patch #8119] Allow variable tolerance and improve error messages for assert.m script

[Dan Sebald]

Follow-up Comment #20, patch #8119 (project octave):

I was waiting on any response to a question on the discussion list about this
behavior:


>> a = [11 22]
a =

   11   22

>> a ([1; 2])
ans =

   11   22 


but haven't heard anything, so I've gone ahead and used (:) to columnize
results where necessary.

I've had to add more tests.  Consider the following scenario:


assert ([(complex (NA, 1)) (complex (2, NA))], [(complex (NA, 2)) 2])


There is 1 disagreement of NA, and one disagreement between the imaginary
parts.  However isfinite(complex(NA,1)) is zero, so the numerical test will
not check whether complex (NA, 1) equals complex (NA, 2).  So, I think we need
to break out the numerical tests into a real and imaginary test.  Here is the
result:


>> assert ([(complex (NA, 1)) (complex (2, NA))], [(complex (NA, 2)) 2])
error: ASSERT errors for:  assert ([(complex (NA, 1)), (complex (2,
NA))],[(complex (NA, 2)), 2])

  Location  |  Observed  |  Expected  |  Reason
   (1,2)         2NAi          2         'NA' mismatch
   (1,2)         2NAi          2         'NaN' mismatch
   (1,1)        NA+1i        NA+2i       Abs err NA exceeds tol 0


The reason text "Abs err NA exceeds tol 0" should probably read "Numbers are
not equivalent", but I think we want to retain the extent of disagreement for
the numerical case.

So, in the attached patch I'm taking a slightly different direction from
previous versions.  For the numeric tests, I've first processed the matrices
by converting any shared NA, NaN or +/-Inf to 0.  That way, the tests can
continue with a similar behavior to before, but also go further by comparing
any real or imaginary portion for which the other component is "!isfinite()". 
(When discrepancies are printed out, the NA, NaN and +/-Inf are retained.) 
Here are some samples (the 2NAi is a bug, reported here
https://savannah.gnu.org/bugs/index.php?39773):


>> assert ([(complex (NA, 1)) (complex (2, NA))], [(complex (NA, 2)) 2])
error: ASSERT errors for:  assert ([(complex (NA, 1)), (complex (2,
NA))],[(complex (NA, 2)), 2])

  Location  |  Observed  |  Expected  |  Reason
   (1,2)         2NAi          2         'NA' mismatch
   (1,2)         2NAi          2         'NaN' mismatch
   (1,1)        NA+1i        NA+2i       Abs err 1 exceeds tol 0

>> assert (complex (Inf, 0.2), complex (-Inf, 0.2 + 2*eps), eps)
error: ASSERT errors for:  assert (complex (Inf, 0.2),complex (-Inf, 0.2 + 2 *
eps),eps)

  Location  |  Observed  |  Expected  |  Reason
   (1,1)       Inf+0.2i    -Inf+0.2000000000000005i    'Inf' mismatch
   (1,1)       Inf+0.2i    -Inf+0.2000000000000005i    Abs err 4.44089e-16
exceeds tol 2.22045e-16


I think I like the way that behaves because it catches everything for which
there is disagreement, plus the reason description is more sensical.  What do
you think.

I also added sub (:, matsize != 1) to shrink the indexing, i.e.,:


  [tmp{:}] = ind2sub (matsize, erridx (:));
  subs = [tmp{:}];
  if (numel (matsize) == 2)
    subs = subs (:, matsize != 1);
  endif


so the output looks like:


>> assert ([2;2;3;3],[1;2;3;4]);
error: ASSERT errors for:  assert ([2; 2; 3; 3],[1; 2; 3; 4])

  Location  |  Observed  |  Expected  |  Reason
    (1)           2            1         Abs err 1 exceeds tol 0
    (4)           3            4         Abs err 1 exceeds tol 0
>> assert ([6;6;7;7],[5;6;7;8])
error: ASSERT errors for:  assert ([6; 6; 7; 7],[5; 6; 7; 8])

  Location  |  Observed  |  Expected  |  Reason
    (1)           6            5         Abs err 1 exceeds tol 0
    (4)           7            8         Abs err 1 exceeds tol 0
>> assert (1, 2)
error: ASSERT errors for:  assert (1,2)

  Location  |  Observed  |  Expected  |  Reason
     ()           1            2         Abs err 1 exceeds tol 0



(file #28827)
    _______________________________________________________

Additional Item Attachment:

File name: octave-assert_vector_tolerance-2013aug12.patch Size:18 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8119>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/