bugGNU Octave - Bugs: bug #54261, blkmm error for some size of input

 
 

bug #54261: blkmm error for some size of input

Submitter:  None
Submitted:  Sat 07 Jul 2018 11:52:19 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.4.0
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 10 Jul 2018 12:52:50 PM UTC, comment #5: 

Thanks, that looks good to me.

John W. Eaton <jwe>
Group administrator
Mon 09 Jul 2018 11:07:50 PM UTC, comment #4: 

@jwe: I checked the patch in under your credentials here (http://hg.savannah.gnu.org/hgweb/octave/rev/e6b037514f56).

I amended it slightly.  There seems to be a bit of a convention to use do_XXX for the internal function which implements the user visible XXX function.  Hence, I renamed blkmm_ov to do_blkmm.  I also rolled the templated blkmm and blkmm_ov in to the one function do_blkmm because they were both short and it didn't seem necessary to have so many templated functions.  I added a BIST test for this bug as well.

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Mon 09 Jul 2018 10:11:15 PM UTC, comment #3: 

I'm attaching a patch that I think eliminates as much duplicate code as possible.  The blkmm template and sub-functions (but not the blkmm_ov template) could also be moved into liboctave.


(file #44530)

John W. Eaton <jwe>
Group administrator
Mon 09 Jul 2018 08:09:18 PM UTC, comment #2: 

@jwe: Maybe you can answer this question.  The fix for this bug is conceptually simple, check for empty matrix inputs and return an empty matrix output if that is the case.  However, in order to get the correct output type, double; double complex; single; single complex, it appears like the code to check for an empty matrix would need to be repeated four times.  Simple, but ugly.

My proof of concept working only with double arrays is below


  // Special case of empty matrices
  if (m == 0 || n == 0)
    {
      retval = NDArray (dimz);
      return retval;
    }

  if (argx.iscomplex () || argy.iscomplex ())
    {
      if (argx.is_single_type () || argy.is_single_type ())
        {
          FloatComplexNDArray x = argx.float_complex_array_value ();
          FloatComplexNDArray y = argy.float_complex_array_value ();
          FloatComplexNDArray z (dimz);

          F77_XFCN (cmatm3, CMATM3, (m, n, k, np,
                                     F77_CONST_CMPLX_ARG (x.data ()), F77_CONST_CMPLX_ARG (y.data ()),
                                     F77_CMPLX_ARG (z.fortran_vec ())));
          retval = z;
        }
      else
        {
          ComplexNDArray x = argx.complex_array_value ();
          ComplexNDArray y = argy.complex_array_value ();
          ComplexNDArray z (dimz);

          F77_XFCN (zmatm3, ZMATM3, (m, n, k, np,
                                     F77_CONST_DBLE_CMPLX_ARG (x.data ()), F77_CONST_DBLE_CMPLX_ARG (y.data ()),
                                     F77_DBLE_CMPLX_ARG (z.fortran_vec ())));
          retval = z;
        }
    }


Is there any good way of avoiding the repetition of "if (m ==0 || n == 0)" within each branch of the if/else tree which decodes type?

If not, I'll just duplicate the tests.

Rik <rik5>
Group administrator
Mon 09 Jul 2018 06:58:29 PM UTC, comment #1: 

Confirmed.  I suppose what is really needed is a test in blkmm for an empty matrix (m = 0 or p = 0).  In that case, there is no need to call the underlying multiplication routines.  Doing a little debugging with ordinary matrices


octave:8> x = ones (0,3)
x = [](0x3)
octave:9> y = ones (3,4)
y =

   1   1   1   1
   1   1   1   1
   1   1   1   1

octave:10> x * y
ans = [](0x4)


So in the following case, the output should be [](0x4x3), instead of an error.


octave:11> x = zeros (0,3,3)
x = [](0x3x3)
octave:12> y = ones (3,4,3);
octave:13> c = blkmm (x,y)
error: Fortran procedure terminated by call to XERBLA



Rik <rik5>
Group administrator
Sat 07 Jul 2018 11:52:19 AM UTC, original submission:  

Let size(A)=[m,p,q], size(B)=[p,n,q], C=blkmm(A,B), then size(C)=[m,n,q].

If (m=0 and n=1) or (m=1 and p=0 and n!=1), then blkmm will raise the following error:

 ** On entry to DGEMV  parameter number  6 had an illegal value
unknown error in fortran subroutine


This is a small issue, since it only raises errors for some size of empty input.

The following test code will show the above result.

lim = 4;
a = randn(lim,lim,lim);
b = randn(lim,lim,lim);
err = [];
for m = 0:lim
for n = 0:lim
for p = 0:lim
for q = 0:lim
        try
                c = blkmm(a(1:m,1:p,1:q), b(1:p,1:n,1:q));
                assert(size_equal(c, zeros(m,n,q)));
        catch
                err = [err; m p n q];
                disp(lasterr);
        end
end
end
end
end
disp(err);


and the output of the above code is as follow.

 ** On entry to DGEMV  parameter number  6 had an illegal value
unknown error in fortran subroutine
......
 ** On entry to DGEMV  parameter number  6 had an illegal value
unknown error in fortran subroutine
   0   0   1   1
   0   0   1   2
   0   0   1   3
   0   0   1   4
   0   1   1   1
   0   1   1   2
   0   1   1   3
   0   1   1   4
   0   2   1   1
   0   2   1   2
   0   2   1   3
   0   2   1   4
   0   3   1   1
   0   3   1   2
   0   3   1   3
   0   3   1   4
   0   4   1   1
   0   4   1   2
   0   4   1   3
   0   4   1   4
   1   0   0   1
   1   0   0   2
   1   0   0   3
   1   0   0   4
   1   0   2   1
   1   0   2   2
   1   0   2   3
   1   0   2   4
   1   0   3   1
   1   0   3   2
   1   0   3   3
   1   0   3   4
   1   0   4   1
   1   0   4   2
   1   0   4   3
   1   0   4   4


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #44530:  diffs.txt added by jwe (6KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-09 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2018-07-09 jwe Attached File- Added diffs.txt, #44530
    2018-07-09 rik5 Carbon-Copy- Added jwe
    2018-07-09 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code