octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #54261] blkmm error for some size of input


From: Rik
Subject: [Octave-bug-tracker] [bug #54261] blkmm error for some size of input
Date: Mon, 9 Jul 2018 16:09:18 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0

Follow-up Comment #2, bug #54261 (project octave):

@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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54261>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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