James Tursa

Wow, I think I am finally getting this stuff. I have to admit it took be awhile to get the meaning of your other posts, but this one for some reason just stood out. These lines from your description were the key:

POSitive half unity: 51
POSitive unity: 102

After that it was simply putting this together with both of these lines:

X = sin(360°)
180 = sin(360°)

to get that this was a POSitive Program Of Sines (POS), or POS POS! Yeah, I finally got it! So I think you should re-title this submission as:

POS POS: Sin Cos 01

A few suggestions for improvement:

1) Don't use bool to point to the MATLAB logical data. MATLAB supplies a data type for this, mxLogical. Using bool only sets you up for an unexpected failure on machines where sizeof(bool) is not 1.

2) Don't use nz to allocate the memory for the new array. There might be a lot of wasted space involved in the input array and there is not point in propagating that waste. Instead, just go get the actual number of current non-zero elements and use that, since you know your result will not be larger than this. e.g.,

    mwSize n, n2;
    jc = mxGetJc(prhs[0]);
    n = mxGetN(prhs[0]);
    nz = jc[n];
        :
    v = mxCreateSparseLogicalMatrix (m, n, nz);

3) There is no code to realloc the memory if a large percentage was reset to zero. e.g., an input matrix that is nearly the same as an identity matrix. Although not an error, you might think about including this.

4) I know you supplied an m-file with the help (very good), but it might be good to copy the calling info into the cpp source file so that a user can have this all in one file when editing the source. Again, not an error but it helps others to read your code.

5) Your nlhs test isn't the best, as it doesn't cover some possible erroneous inputs (e.g., what if user tries to fill two output variables?):

if (nlhs > 0)
plhs[0] = v;

 A better method is as follows:

// at the beginning of your code:
    if( nlhs > 1 ) {
        mexErrMsgTxt("Too many outputs, expecting at most one.");
}

// at the end of your code
    plhs[0] = v;

i.e., at the end of your code don't do any test, just set plhs[0]. That way it will work if the user doesn't try to set the result to any variable ... in that case the result simply goes into ans. This always works, even if nlhs == 0.

6) You might consider making this a self-building mex routine. For an example of this, see one of my submissions, e.g.,

http://www.mathworks.com/matlabcentral/fileexchange/22239

7) With some very minor tweaking, you could also supply a C source code version so the users that only have access to the supplied lcc compiler can use this out of the box.

The code appears to work fine, and is indeed much faster than a loop. I would probably rate it a 3 at this point, but I will wait for author's response to my comments before rating and may go higher.

Thanks for the 5* rating. The #define for mwSize is needed for older versions of MATLAB that do not have this. That way the same source code can be used with either newer or older versions. I am a bit surprised that the .for extension didn't work ... I had no idea there was a Fortran compiler out there that didn't know what to do with a .for file! But this is good to know. In the future I will use .f extensions (or .f90) for my Fortran submissions.

A better bsxfun substitute can be found here by Doug Schwarz:
http://www.mathworks.com/matlabcentral/fileexchange/23005

Wow, this just got me out of a very nasty fix (I came to the end of 400 lines of Fortran, then realised I couldn't pass the logical result back!).

Thanks, James, 5*

Although, if I were nit-picking, I probably wouldn't have added the type definitions of mwSize etc - I think to prevent confusion it'd be better to throw an error if they aren't defined - and keep their definitions all in one place (typically the fintrf.h file).