varargout{1:nargout}
in [Matlab]
|
From: George Coles on 18 Jan 2010 15:46 Praetorian <ashish.sadanandan(a)gmail.com> wrote in message <48c9fecc-e565-4f1d-9277-cd03bff66c51(a)l19g2000yqb.googlegroups.com>... > On Jan 18, 10:08 am, Praetorian <ashish.sadanan...(a)gmail.com> wrote: > > On Jan 18, 9:27 am, "George Coles" <geo...(a)quantitative.com> wrote: > > > > > > > > > Loren Shure <loren.sh...(a)mathworks.com> wrote in message <MPG.25be2afb1f703587989...(a)news.mathworks.com>... > > > > In article <hisld7$so...(a)fred.mathworks.com>, geo...(a)quantitative.com > > > > says... > > > > > I have tried to find some documentation regarding using the varargout mechanism with mex functions. Perhaps I did not look hard enough, but I have not seen any discussion of why this seems not to work. I wrote a simple test function that creates the same number of dummy outputs as the value in the nrhs argument in mexFunction(). If I call > > > > > > > [a,b,c] = test(1,2,3), > > > > > > > setting the output arguments manually, it works. If I use > > > > > > > varargout{1:nargout} = test(1,2,3) > > > > > > > nargout always seems to be equal to 1. Does anyone know if this should be supported, and if not, does anyone know of a workaround? > > > > > > > thx > > > > > George > > > > > > The latter is correct as is. varargout{1:3} produces a length 3 comma- > > > > separated list, not a list of outputs as in your first syntax. As a > > > > result, test(1,2,3) only sees one output (varargout{1}). > > > > > > -- > > > > Loren > > > >http://blogs.mathworks.com/loren > > > > > My situation is that I have a mex function written in c++ that takes a string argument, which is a query submitted to a specialized database API. The query could return any number of columns, each of which is returned from the mex function as a cell array. If the number of columns returned is known, or guessed, it is straightforward to hard-code the size of the cell array that holds all the outputs. What I am trying to support is the scenario where the number of return values is not known in advance. > > > I would like to detect the number of output arguments that have been placed into > > > plhs[0] ... plhs[n]. > > > Does this clarify my earlier question? Is it possible? My workaround now is to parse the query string and discover the number of columns to expect but it would be more robust to use built-in Matlab features to accomplish the same goal. > > > > > thx > > > g > > > > The nargout syntax seems to work for me. Here are the files I created > > to test this: > > > > -------------- mexfile ------------------------ > > > > #include "mex.h" > > > > void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray > > *prhs[]) > > { > > mexPrintf( "nlhs = %d\n", nlhs ); > > > > for( int i = 0; i < nlhs; i++ ) { > > plhs[i] = mxCreateDoubleMatrix( 0, 0, mxREAL ); > > } > > > > } > > > > ------------ end mexfile ------------------- > > > > ------------ mfile ----------------------- > > > > function varargout = mtest > > > > [varargout{1:nargout}] = mextest; > > > > ------------ end mfile ----------------- > > > > Now call mtest as follows: > > > > [a b c d] = testmfile > > nlhs = 4 > > a = > > [] > > b = > > [] > > c = > > [] > > d = > > [] > > > > Is this what you were looking for? > > > > HTH, > > Ashish. > > I screwed up the m file name in the call example because I renamed the > file before I posted: > > [a b c d] = mtest > nlhs = 4 > a = > [] > b = > [] > c = > [] > d = > [] My test mex code looks just like yours. When the user knows the number of args out to expect, I agree this works. But what about when the mex code populates the plhs array with a number of arguments that is only known by the mex function? Essentially what I need is for the mex function to set nargout, not the caller.
From: Praetorian on 18 Jan 2010 16:53 On Jan 18, 1:46 pm, "George Coles" <geo...(a)quantitative.com> wrote: > Praetorian <ashish.sadanan...(a)gmail.com> wrote in message <48c9fecc-e565-4f1d-9277-cd03bff66...(a)l19g2000yqb.googlegroups.com>... > > On Jan 18, 10:08 am, Praetorian <ashish.sadanan...(a)gmail.com> wrote: > > > On Jan 18, 9:27 am, "George Coles" <geo...(a)quantitative.com> wrote: > > > > > Loren Shure <loren.sh...(a)mathworks.com> wrote in message <MPG.25be2afb1f703587989...(a)news.mathworks.com>... > > > > > In article <hisld7$so...(a)fred.mathworks.com>, geo...(a)quantitative..com > > > > > says... > > > > > > I have tried to find some documentation regarding using the varargout mechanism with mex functions. Perhaps I did not look hard enough, but I have not seen any discussion of why this seems not to work. I wrote a simple test function that creates the same number of dummy outputs as the value in the nrhs argument in mexFunction(). If I call > > > > > > > [a,b,c] = test(1,2,3), > > > > > > > setting the output arguments manually, it works. If I use > > > > > > > varargout{1:nargout} = test(1,2,3) > > > > > > > nargout always seems to be equal to 1. Does anyone know if this should be supported, and if not, does anyone know of a workaround? > > > > > > > thx > > > > > > George > > > > > > The latter is correct as is. varargout{1:3} produces a length 3 comma- > > > > > separated list, not a list of outputs as in your first syntax. As a > > > > > result, test(1,2,3) only sees one output (varargout{1}). > > > > > > -- > > > > > Loren > > > > >http://blogs.mathworks.com/loren > > > > > My situation is that I have a mex function written in c++ that takes a string argument, which is a query submitted to a specialized database API. The query could return any number of columns, each of which is returned from the mex function as a cell array. If the number of columns returned is known, or guessed, it is straightforward to hard-code the size of the cell array that holds all the outputs. What I am trying to support is the scenario where the number of return values is not known in advance. > > > > I would like to detect the number of output arguments that have been placed into > > > > plhs[0] ... plhs[n]. > > > > Does this clarify my earlier question? Is it possible? My workaround now is to parse the query string and discover the number of columns to expect but it would be more robust to use built-in Matlab features to accomplish the same goal. > > > > > thx > > > > g > > > > The nargout syntax seems to work for me. Here are the files I created > > > to test this: > > > > -------------- mexfile ------------------------ > > > > #include "mex.h" > > > > void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray > > > *prhs[]) > > > { > > > mexPrintf( "nlhs = %d\n", nlhs ); > > > > for( int i = 0; i < nlhs; i++ ) { > > > plhs[i] = mxCreateDoubleMatrix( 0, 0, mxREAL ); > > > } > > > > } > > > > ------------ end mexfile ------------------- > > > > ------------ mfile ----------------------- > > > > function varargout = mtest > > > > [varargout{1:nargout}] = mextest; > > > > ------------ end mfile ----------------- > > > > Now call mtest as follows: > > > > [a b c d] = testmfile > > > nlhs = 4 > > > a = > > > [] > > > b = > > > [] > > > c = > > > [] > > > d = > > > [] > > > > Is this what you were looking for? > > > > HTH, > > > Ashish. > > > I screwed up the m file name in the call example because I renamed the > > file before I posted: > > > [a b c d] = mtest > > nlhs = 4 > > a = > > [] > > b = > > [] > > c = > > [] > > d = > > [] > > My test mex code looks just like yours. When the user knows the number of args out to expect, I agree this works. But what about when the mex code populates the plhs array with a number of arguments that is only known by the mex function? Essentially what I need is for the mex function to set nargout, not the caller. AFAIK, what you're asking for is not possible. NARGOUT is an input to a function indicating how many outputs the caller desires to obtain, not the other way around. In your case, I'd follow James' advice, output a single argument from your mex file in plhs[0], This should be a cell array which you can populate with an arbitrary number of elements as your mex function desires. HTH, Ashish.
From: George Coles on 18 Jan 2010 17:12 Praetorian <ashish.sadanandan(a)gmail.com> wrote in message <8c4578cb-37a3-4232-ab8f-881081535d39(a)a6g2000yqm.googlegroups.com>... > On Jan 18, 1:46 pm, "George Coles" <geo...(a)quantitative.com> wrote: > > Praetorian <ashish.sadanan...(a)gmail.com> wrote in message <48c9fecc-e565-4f1d-9277-cd03bff66...(a)l19g2000yqb.googlegroups.com>... > > > On Jan 18, 10:08 am, Praetorian <ashish.sadanan...(a)gmail.com> wrote: > > > > On Jan 18, 9:27 am, "George Coles" <geo...(a)quantitative.com> wrote: > > > > > > > Loren Shure <loren.sh...(a)mathworks.com> wrote in message <MPG.25be2afb1f703587989...(a)news.mathworks.com>... > > > > > > In article <hisld7$so...(a)fred.mathworks.com>, geo...(a)quantitative.com > > > > > > says... > > > > > > > I have tried to find some documentation regarding using the varargout mechanism with mex functions. Perhaps I did not look hard enough, but I have not seen any discussion of why this seems not to work. I wrote a simple test function that creates the same number of dummy outputs as the value in the nrhs argument in mexFunction(). If I call > > > > > > > > > [a,b,c] = test(1,2,3), > > > > > > > > > setting the output arguments manually, it works. If I use > > > > > > > > > varargout{1:nargout} = test(1,2,3) > > > > > > > > > nargout always seems to be equal to 1. Does anyone know if this should be supported, and if not, does anyone know of a workaround? > > > > > > > > > thx > > > > > > > George > > > > > > > > The latter is correct as is. varargout{1:3} produces a length 3 comma- > > > > > > separated list, not a list of outputs as in your first syntax. As a > > > > > > result, test(1,2,3) only sees one output (varargout{1}). > > > > > > > > -- > > > > > > Loren > > > > > >http://blogs.mathworks.com/loren > > > > > > > My situation is that I have a mex function written in c++ that takes a string argument, which is a query submitted to a specialized database API. The query could return any number of columns, each of which is returned from the mex function as a cell array. If the number of columns returned is known, or guessed, it is straightforward to hard-code the size of the cell array that holds all the outputs. What I am trying to support is the scenario where the number of return values is not known in advance. > > > > > I would like to detect the number of output arguments that have been placed into > > > > > plhs[0] ... plhs[n]. > > > > > Does this clarify my earlier question? Is it possible? My workaround now is to parse the query string and discover the number of columns to expect but it would be more robust to use built-in Matlab features to accomplish the same goal. > > > > > > > thx > > > > > g > > > > > > The nargout syntax seems to work for me. Here are the files I created > > > > to test this: > > > > > > -------------- mexfile ------------------------ > > > > > > #include "mex.h" > > > > > > void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray > > > > *prhs[]) > > > > { > > > > mexPrintf( "nlhs = %d\n", nlhs ); > > > > > > for( int i = 0; i < nlhs; i++ ) { > > > > plhs[i] = mxCreateDoubleMatrix( 0, 0, mxREAL ); > > > > } > > > > > > } > > > > > > ------------ end mexfile ------------------- > > > > > > ------------ mfile ----------------------- > > > > > > function varargout = mtest > > > > > > [varargout{1:nargout}] = mextest; > > > > > > ------------ end mfile ----------------- > > > > > > Now call mtest as follows: > > > > > > [a b c d] = testmfile > > > > nlhs = 4 > > > > a = > > > > [] > > > > b = > > > > [] > > > > c = > > > > [] > > > > d = > > > > [] > > > > > > Is this what you were looking for? > > > > > > HTH, > > > > Ashish. > > > > > I screwed up the m file name in the call example because I renamed the > > > file before I posted: > > > > > [a b c d] = mtest > > > nlhs = 4 > > > a = > > > [] > > > b = > > > [] > > > c = > > > [] > > > d = > > > [] > > > > My test mex code looks just like yours. When the user knows the number of args out to expect, I agree this works. But what about when the mex code populates the plhs array with a number of arguments that is only known by the mex function? Essentially what I need is for the mex function to set nargout, not the caller. > > AFAIK, what you're asking for is not possible. NARGOUT is an input to > a function indicating how many outputs the caller desires to obtain, > not the other way around. In your case, I'd follow James' advice, > output a single argument from your mex file in plhs[0], This should be > a cell array which you can populate with an arbitrary number of > elements as your mex function desires. > > HTH, > Ashish. Ashish thanks for your replies. I guess I am going to need to do what you suggest. I have had unrelated issues populating one large cell array, that I think are related to calculating the sequential index, and I found that I could populate one-d cell arrays with no problem, which led to this question. Thanks again.
From: James Tursa on 18 Jan 2010 20:41 "George Coles" <george(a)quantitative.com> wrote in message <hj2mbk$pe4$1(a)fred.mathworks.com>... > > I have had unrelated issues populating one large cell array, that I think are related to calculating the sequential index, and I found that I could populate one-d cell arrays with no problem, which led to this question. A cell array is just an array of mxArray * variables. i.e., the data area of a cell array is an array of mxArray * variables, and mxGetData returns a pointer to the first cell. Indexing into it is the same as indexing into any n-dimensional array regardless of type. e.g., compare the output of mxGetCell(yourcellarray,0) with mxGetData(yourcellarray) and you see they are the same. The main gotcha is if you reuse variables without telling MATLAB about it. e.g., if you do something like this: mxArray *cell; : plhs[0] = mxCreateCellMatrix(m, n); cell = mxCreateDoubleScalar(1.0); // or whatever mxSetCell(plhs[0], 0, cell); mxSetCell(plhs[0], 1, cell); Now there is a problem because you have reused cell without telling MATLAB about it. When MATLAB eventually clears this variable in the workspace you will likely get a seg fault or a crash as it tries to clear the same memory twice. The proper way to resuse variables is to copy them or create a shared data copy (undocumented). e.g., mxArray *cell; : plhs[0] = mxCreateCellMatrix(m, n); cell = mxCreateDoubleScalar(1.0); // or whatever mxSetCell(plhs[0], 0, cell); cell = mxDuplicateArray(cell); mxSetCell(plhs[0], 1, cell); or mxArray *mxCreateSharedDataCopy(const mxArray *mx); // Undocumented function prototype : mxArray *cell; : plhs[0] = mxCreateCellMatrix(m, n); cell = mxCreateDoubleScalar(1.0); // or whatever mxSetCell(plhs[0], 0, cell); cell = mxCreateSharedDataCopy(cell); mxSetCell(plhs[0], 1, cell); James Tursa
From: James Tursa on 18 Jan 2010 21:53 "James Tursa" <aclassyguy_with_a_k_not_a_c(a)hotmail.com> wrote in message <hj32jh$im0$1(a)fred.mathworks.com>... > > ... compare the output of mxGetCell(yourcellarray,0) with mxGetData(yourcellarray) and you see they are the same. I was not quite clear on that point. Comparing mxGetCell(yourcellarray,0) with *((mxArray *)mxGetData(yourcellarray)) would yield the same value. James Tursa
|
Next
|
Last
Pages: 1 2 Prev: Different p-code on Runtime Server? Next: a simple pde question, please don't ignore |