mxGetData gets garbage
in [Matlab]
|
From: John Boone on 6 Aug 2010 12:27 To Whomever, I apologize in advance for the length of this post. However, I think you will find it necessary. I am trying to create a MEX function that takes in a couple of matrices as inputs and does stuff to them before outputting other values to the original Matlab function that called the MEX function. My problem occurs when the inputs are extracted with the mxGetData() function. A condensed version of my code looks like this: void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[]) { // declare variables double *G, *X, *P, *sigma; bool *Opt; // check proper number of arguments if (nrhs != 5) mexErrMsgTxt("Incorrect number of inputs"); if (nlhs != 4) mexErrMsgTxt("Incorrect number of outputs"); // check out input parameters if (!mxIsDouble(prhs[0])) mexErrMsgTxt("Error - G must be a double");} if (!mxIsDouble(prhs[1])) mexErrMsgTxt("Error - X must be a double");} // extract inputs G = (double *)mxGetData(prhs[0]); X = (double *)mxGetData(prhs[1]); <do stuff> } My problem is that on the Matlab side of things, a simple example of G may look something like this: ..47 .34 .25 1 0 0 0 0 0 ..89 .34 .58 0 1 0 0 0 0 ..63 .26 .95 0 0 1 0 0 0 ..38 .27 .27 0 0 0 0 0 -1 ..59 .72 .64 0 0 1 0 0 0 ..83 .98 .52 0 0 0 1 0 0 ..13 .63 .29 0 0 0 0 1 0 And in the MEX function, I will get this: ..47 .34 .25 .89 .34 .58 .63 .26 .95 ..38 .27 .27 .59 .72 .64 .83 .98 .52 ..13 .63 .29 -1 0 0 1 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 There are some things to note about the two matrices above. First, the dimensions are the same in Matlab and in the MEX function (7-by-9 in this example). So although the second matrix might look, at a glance, like the first matrix but flipped over on its side, the two matrices are not transposes of each other. Second, although there are a lot of zeros in the matrices above (and in the real matrices in my programs), mxIsSparse(prhs[0]) is false. Third, the second matrix, X, gets extracted with no mistakes, so I do not think this is column-ordering vs. row-ordering or something similar. However, the matrix X is a full double matrix. Also, I'm using the 64-bit version of Matlab 2009a on a windows platform with Microsoft Visual C++ 2008 as my compiler. I've done some research on the internet to try to find a cause/solution or even someone who has a similar problem, but so far I've turned up nothing. Does anyone have any clue what's going on here? TIA, J Boone
From: James Tursa on 6 Aug 2010 12:43 "John Boone" <johnboone2026(a)gmail.com> wrote in message <i3hd4o$552$1(a)fred.mathworks.com>... > > I am trying to create a MEX function that takes in a couple of matrices as inputs and does stuff to them before outputting other values to the original Matlab function that called the MEX function. My problem occurs when the inputs are extracted with the mxGetData() function. A condensed version of my code looks like this: (snip) > I'm using the 64-bit version of Matlab 2009a on a windows platform with Microsoft Visual C++ 2008 as my compiler. I've done some research on the internet to try to find a cause/solution or even someone who has a similar problem, but so far I've turned up nothing. Does anyone have any clue what's going on here? You have a bug in your code. But without seeing your code we cannot help you much. For instance, you say you don't think it is a row vs column ordering mixup, but that is just a statement from you that doesn't really help us much unless we can look at your code to see if it is true. Maybe it is a mistake in how you are printing the values out, or how you are indexing into the arrays, or etc. etc. etc. I would hazard a guess that it is not a problem with mxGetData itself, but since I don't have a 64-bit system to check with I can't rule that out based on any tests I can run. You really will need to boil down your problem to a small size and post your code if you want any meaningful help. James Tursa
From: Steven_Lord on 6 Aug 2010 13:13 "John Boone" <johnboone2026(a)gmail.com> wrote in message news:i3hct9$jve$1(a)fred.mathworks.com... > To Whomever, > > I apologize in advance for the length of this post. However, I think you > will find it necessary. > > I am trying to create a MEX function that takes in a couple of matrices as > inputs and does stuff to them before outputting other values to the > original Matlab function that called the MEX function. My problem occurs > when the inputs are extracted with the mxGetData() function. A condensed > version of my code looks like this: *snip* James answered some of your other questions; I want to address one that he didn't. > Second, although there are a lot of zeros in the matrices above (and in > the real matrices in my programs), mxIsSparse(prhs[0]) is false. That is most likely the correct behavior. mxIsSparse does NOT answer the question "Does the input have only a few (for some definition of few) nonzero elements?" It DOES answer the question "Does the input have the sparse attribute?" http://www.mathworks.com/access/helpdesk/help/techdoc/apiref/mxissparse.html You can pass the matrix zeros(1000) [which has NO nonzero elements] into your MEX-file and call mxIsSparse on it, and if you do you will receive the answer false. On the other hand, you could pass sparse(ones(3)) [which has ALL nonzero elements] into that same MEX-file and mxIsSparse will return true for that matrix. -- Steve Lord slord(a)mathworks.com comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ To contact Technical Support use the Contact Us link on http://www.mathworks.com
From: Bruno Luong on 6 Aug 2010 14:30 > > There are some things to note about the two matrices above. > > First, the dimensions are the same in Matlab and in the MEX function (7-by-9 in this example). So although the second matrix might look, at a glance, like the first matrix but flipped over on its side, the two matrices are not transposes of each other. For array, Matlab memory organization is column ordering, and C is row ordering. My guess is that you "forget" that when retrieve your data. > > Second, although there are a lot of zeros in the matrices above (and in the real matrices in my programs), mxIsSparse(prhs[0]) is false. Sparse has nothing to do with a number of zeros in the matrix. SPARSE is distinct from FULL by the a sophisticated internal storing that is appropriate for manipulating array with a lot of zero. For example: sparse(ones(5)) is a sparse matrix. zeros(5) is a full matrix. > > Third, the second matrix, X, gets extracted with no mistakes, so I do not think this is column-ordering vs. row-ordering or something similar. However, the matrix X is a full double matrix. > > Also, I'm using the 64-bit version of Matlab 2009a on a windows platform with Microsoft Visual C++ 2008 as my compiler. I've done some research on the internet to try to find a cause/solution or even someone who has a similar problem, but so far I've turned up nothing. Does anyone have any clue what's going on here? > As previously stated, you forget that Matlab is column ordering, like fortran. Bruno
|
Pages: 1 Prev: mxGetData gets garbage Next: interpolation NaN data at 3D array |