Wrong result when using BLAS dot product routine (DDOT) from a MEX file

Hello,

I am trying to call some BLAS routines from MEX code. First, I am trying to compute a scalar product with the fuction DDOT.

Here is my MEX file:

#include "mex.h"
#include "blas.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
  double *A, *B, C;
  int m, one=1;
  A = mxGetPr(prhs[0]);
  B = mxGetPr(prhs[1]);
  m = mxGetM(prhs[0]); /* number of rows */

    /* Pass all arguments to Fortran by reference */
    C = (double) ddot(&m,A,&one,B,&one);

    /* create output */
    plhs[0] = mxCreateDoubleScalar(C);

    return;
  }

The compilation returns no error. When using it, though, I do not get the expected result:

>> a = ones(2,1);
>> b = ones(2,1);
>> mydot(a,b)

ans =

       0

Am I calling DDOT inappropriately?

-- H. G.

[James Tursa]

I would advise using mxGetNumberOfElements instead of mxGetM, to make the routine a bit more robust for row vs column vector inputs.

Answer 1

[Titus Edelhofer]

Hi,

you need to change the variable definition of m and one and use two variables for "one":

ptrdiff_t m, one1 = 1, one2 = 1;
C = (double) ddot(&m,A,&one1,B,&one2);

Then it works.

Titus

[James Tursa]

mwSignedIndex is usually what is recommended for the integer arguments of BLAS and LAPACK functions for the libraries that MATLAB ships with ... at least that is what is used in the example code. I haven't scanned through the header files to see if this always reduces to ptrdiff_t or not.

Using two different variables for "one" should not be necessary ... all of the arguments are inputs that should be treated as read-only by DDOT.

[José Goulart]

Thanks a lot, Titus and James, now it works!

Indeed, the problem was the type of the variables m and one. By declaring them as ptrdiff_t or as mwSignedIndex, the response comes out as expected.

Moreover, as James said, it works fine when I use a single variable "one"---no need to define two variables one1 and one2.

Cheers!