Thread Subject: Call a MEX function from Matlab Engine?

I have a mex file test.mexw32 in
'C:\Documents and Settings\Dave\My Documents\Visual Studio
2005\Projects\Matlab MEX'

My function simply squares the input. In matlab, test(4)
tells me 16.

Now in my c++ code, I did this:

engEvalString(ep, "cd 'C:\Documents and Settings\Dave\My
Documents\Visual Studio 2005\Projects\Matlab MEX';");

engEvalString(ep, "a=test(4);");
mxArray *test2 = NULL;
test2 = mxCreateDoubleMatrix(1, 1, mxREAL);
test2 = engGetVariable(ep, "a");
double *myout2;
myout2 = mxGetPr(test2);
cout << myout2[0] << endl;

I get a "Access violation reading location" error. What have
I done wrong?

Thanks,

Dave

"David Doria" <daviddoria@gmail.com> wrote in message
<frc4bp$ipi$1@fred.mathworks.com>...
> I have a mex file test.mexw32 in
> 'C:\Documents and Settings\Dave\My Documents\Visual
Studio
> 2005\Projects\Matlab MEX'
>
> My function simply squares the input. In matlab, test(4)
> tells me 16.
>
> Now in my c++ code, I did this:
>
> engEvalString(ep, "cd 'C:\Documents and Settings\Dave\My
> Documents\Visual Studio 2005\Projects\Matlab MEX';");
>
> engEvalString(ep, "a=test(4);");
> mxArray *test2 = NULL;
> test2 = mxCreateDoubleMatrix(1, 1, mxREAL);
> test2 = engGetVariable(ep, "a");
> double *myout2;
> myout2 = mxGetPr(test2);
> cout << myout2[0] << endl;
>
> I get a "Access violation reading location" error. What
have
> I done wrong?
>
> Thanks,
>
> Dave

Comments:

1) You should reply to the original threads in this
newsgroup rather than creating new ones. That way people
can keep track of the original problem and the various
solutions discussed along the way.

2) You don't list your mex file, so I don't know what it
returns as an output. Does it work? Does it return a
double, an integer? Try calling your mex file from MATLAB
to verify this, e.g.

>> test(4)
>> class(ans)

If it is not a double class, then of course your mxGetPr
call and the follow-on myout2[0] calculation can certainly
cause an access violation. Your earlier thread posting
indicated your MyFunc returned an integer. Is this what
you are using? In general, you should always check the
class, number of elements, etc. of an mxArray before using
it.

3) The first of these two lines is pointless:

> test2 = mxCreateDoubleMatrix(1, 1, mxREAL);
> test2 = engGetVariable(ep, "a");

Why? Because you first create a brand new mxArray and
store a pointer to it in test2. Then you immediately wipe
this pointer out with a brand new pointer to the mxArray
returned by engGetVariable. This is a memory leak. You
just wiped out your only handle to the heap memory
allocated for the first double matrix you created.
MATLAB's memory manager will fortunately clean this up for
you when the mex file exits, but it is still bad.

4) I am assuming that the engine opened properly.

James Tursa

1) sorry, I thought now it was a different question

2) I mentioned that test(4) in matlab outputs 16, but I
actually dont remember now if it returned an int or a
double(i'll check in the morning). I figured that matlab
would convert it to its "matrix" class anyway - does it not?
Would I just change double *myout2; to int *myout2?
Assuming the function did return an int, in this case it
should be converting from an int to a double, can it not do
that automatically?

2b) If I use mxGetData instead of mxGetPr does that kind of
fix the type automatically?

3) gotcha, I thought I may have to initialize it or
something first, but I guess I was wrong.

4) Yea the engine did open; I plotted some junk before this
to test that.

I'm not a stellar c++ program and this is as far as the
matlab help got me, so I really appreciate the help!

David


"James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in
message <frc7ir$s19$1@fred.mathworks.com>...
> "David Doria" <daviddoria@gmail.com> wrote in message
> <frc4bp$ipi$1@fred.mathworks.com>...
> > I have a mex file test.mexw32 in
> > 'C:\Documents and Settings\Dave\My Documents\Visual
> Studio
> > 2005\Projects\Matlab MEX'
> >
> > My function simply squares the input. In matlab, test(4)
> > tells me 16.
> >
> > Now in my c++ code, I did this:
> >
> > engEvalString(ep, "cd 'C:\Documents and Settings\Dave\My
> > Documents\Visual Studio 2005\Projects\Matlab MEX';");
> >
> > engEvalString(ep, "a=test(4);");
> > mxArray *test2 = NULL;
> > test2 = mxCreateDoubleMatrix(1, 1, mxREAL);
> > test2 = engGetVariable(ep, "a");
> > double *myout2;
> > myout2 = mxGetPr(test2);
> > cout << myout2[0] << endl;
> >
> > I get a "Access violation reading location" error. What
> have
> > I done wrong?
> >
> > Thanks,
> >
> > Dave
>
> Comments:
>
> 1) You should reply to the original threads in this
> newsgroup rather than creating new ones. That way people
> can keep track of the original problem and the various
> solutions discussed along the way.
>
> 2) You don't list your mex file, so I don't know what it
> returns as an output. Does it work? Does it return a
> double, an integer? Try calling your mex file from MATLAB
> to verify this, e.g.
>
> >> test(4)
> >> class(ans)
>
> If it is not a double class, then of course your mxGetPr
> call and the follow-on myout2[0] calculation can certainly
> cause an access violation. Your earlier thread posting
> indicated your MyFunc returned an integer. Is this what
> you are using? In general, you should always check the
> class, number of elements, etc. of an mxArray before using
> it.
>
> 3) The first of these two lines is pointless:
>
> > test2 = mxCreateDoubleMatrix(1, 1, mxREAL);
> > test2 = engGetVariable(ep, "a");
>
> Why? Because you first create a brand new mxArray and
> store a pointer to it in test2. Then you immediately wipe
> this pointer out with a brand new pointer to the mxArray
> returned by engGetVariable. This is a memory leak. You
> just wiped out your only handle to the heap memory
> allocated for the first double matrix you created.
> MATLAB's memory manager will fortunately clean this up for
> you when the mex file exits, but it is still bad.
>
> 4) I am assuming that the engine opened properly.
>
> James Tursa
>
>

I don't know if you need this much advice, but here
goes ...

"David Doria" <daviddoria@gmail.com> wrote in message
<frccfq$l2f$1@fred.mathworks.com>...
>
> 2) I mentioned that test(4) in matlab outputs 16, but I
> actually dont remember now if it returned an int or a
> double(i'll check in the morning). I figured that matlab
> would convert it to its "matrix" class anyway - does it
not?

There is no such thing as a "matrix" class. The class
types are things
like "double", "single", "int32", "int16", etc. Variables
of these class types can be scalars, vectors, matrices, or
multi-dimensional arrays. If you type in a constant
number, like the argument 4 in your test(4) call, MATLAB
will convert the 4 into an mxArray of type double class,
with dimensions 1 x 1 (i.e. scalar). This is what gets
passed to the test function. If test is a mex function,
then that means that prhs[0] will be a pointer to an
mxArray of type double with one element. There is no
automatic conversion as far as accessing this data is
concerned. It is a 64-bit floating point value and needs
to be treated as such in your C++ code. There are various
ways to get the scalar value for use in your C++ code:

    double d;
    double *dp;
    dp = mxGetPr(prhs[0]);
    d = *dp;

or

    double d;
    double *dp;
    dp = (double *) mxGetData(prhs[0]);
    d = *dp;

or

    double d;
    d = *(mxGetPr(prhs[0]));

If you know the input has an integer value and want to use
it as an int, you can use a cast to do this, for instance

    int i;
    i = (int) *(mxGetPr(prhs[0]));

but you CANNOT do something like this

    int i;
    int *ip;
    ip = mxGetPr(prhs[0]); // bad bad bad
    i = *ip;

and the use of a cast doesn't fix this either

    int i;
    int *ip;
    ip = (int *) mxGetPr(prhs[0]); // bad bad bad
    i = *ip;

These last two cases takes the result of mxGetPr, which is
always a pointer to double, and then subsequently treats
it as a pointer to int when dereferencing. Since the
underlying bits are 64-bit floating point this will give
you garbage.

Same comments apply to the output of your mex function.
plhs[0] is created by you with whatever class type you
select. If you use mxCreateDoubleMatrix, for instance,
then the class will be double and the data will be 64-bit
floating point and must be treated as such. If your C++
code returns an int that you want stuffed into plhs[0],
then you would have to make sure it was cast either
explicitly or implicitly. For example suppose MyFunc
returns an int:

    int i;
    plhs[0] = mxCreateDoubleMatrix( 1, 1, mxREAL );
    i = MyFunc( blah blah );
    *(mxGetPr(plhs[0])) = (double) i;

Here we are getting an int result from MyFunc, casting
that result into a double, and then putting that into the
data area of plhs[0]. You don't actually *need* the
(double) cast in this assignment since it will happen
automatically in this case, but I think it is good
practice to put these in your code to make them obvious to
the reader what is going on.

> Would I just change double *myout2; to int *myout2?
> Assuming the function did return an int, in this case it
> should be converting from an int to a double, can it not
do
> that automatically?
>

See the above comments. You can certainly cast a double to
an int, but you cannot cast a pointer to double into a
pointer to int and then expect to get a correct answer
when dereferencing it.

I suggest you post your mex code so that I can look at it
and see what you are doing.

> 2b) If I use mxGetData instead of mxGetPr does that kind
of
> fix the type automatically?
>

No. mxGetData returns a pointer to void, whereas mxGetPr
returns a pointer to double, but they both return the same
value. i.e., the address they return is the same, namely
the starting address of the data. mxGetPr should only be
used with mxArrays of class double, and mxGetData should
be used for all other classes (single, int32, etc.) and
then a cast used ((float *), (int *), etc.) on the result
to get proper access to the data.

James Tursa

ok, I tried again to no avail...
I understand the stuff about the types and the pointer types
now, thanks for the explanation. I am clearly still missing
something else though.

In matlab, mexfunc(4) sets ans to 8. class(ans) is double.

Here is the MEX code: (mexfunc.cpp)

#include "mex.h"

void timestwo(double y[], double x[])
{
  y[0] = 2*x[0];
}

void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[] )
{
  double *x,*y;
  mwSize mrows,ncols;
  plhs[0] = mxCreateDoubleMatrix(1,1, mxREAL);
  x = mxGetPr(prhs[0]);
  y = mxGetPr(plhs[0]);
  timestwo(y,x);

}


And here is the c++ code:

engEvalString(ep, "cd 'C:\Documents and Settings\Dave\My
Documents\Visual Studio 2005\Projects\Matlab MEX';");

engEvalString(ep, "a=mexfunc(4);");
mxArray *test2 = NULL;
test2 = engGetVariable(ep, "a");
double *myout2;
myout2 = mxGetPr(test2); //Access violation on this line
double d;
d=*myout2;
cout << d << endl;

Any more clues for me? haha

Thanks,
Dave

"David Doria" <daviddoria@gmail.com> wrote in message
<frdvs6$lim$1@fred.mathworks.com>...
>
> Any more clues for me? haha
>
> Thanks,
> Dave

This worked for me. I suspect that your MATLAB engine cannot
see your test function, so when you try to execute it and
access the answer you get garbage. Print out the values of
all the pointers before you use them to verify this. Is test
on the path where the MATLAB engine can see it?

James Tursa

#include <iostream>
#include "engine.h"

using namespace std;

int main()
{
    Engine *ep;
    
    ep = engOpen(NULL);

//engEvalString(ep, "cd 'C:\Documents and
Settings\Dave\MyDocuments\Visual Studio 2005\Projects\Matlab
MEX';");

engEvalString(ep, "a=mexfunc(4);");
mxArray *test2 = NULL;
test2 = engGetVariable(ep, "a");
double *myout2;
myout2 = mxGetPr(test2); //Access violation on this line
double d;
d=*myout2;
cout << d << endl;

}

As you guessed, test2 was 00000000. For some reason my
compiler was completely skipping the line about "cd the
directory". I removed the couple of lines before this code
that i plotted something just to test if the engine opened
properly and the compiler complained that I had used \
instead of / in the path... Why it ignored it with the plot
command I have NO idea.

But it worked for me now as well. So now back to my first
question of how to call fminunc() from the engine. I'm not
sure if this is exactly what you were suggesting, but I
think it will work:

1) I have test.cpp which contains f() which I intend to
minimize:
//for now I made it extra simple
double f()
{
return 2.81;
}
2) I have mexfunc.cpp which contains mexFunction() which I
can now get the value from in main() in test.cpp
3) All thats left to do is call f() from mexFunction(). I
made a test.h and all I put in it is:
double f();

then in mexfunc.cpp I put:
#include "test.h"

Then I try to run 'mex mexfunc.cpp' in matlab and I get:

mexfunc.obj : error LNK2019: unresolved external symbol
"double __cdecl f(void)" (?f@@YANXZ) referenced in function
_mexFunction

Any thoughts? I promise (well maybe not!) I'll leave you
alone after this :)

Dave

I'll tell you why it ignored your "cd" command: you're
using C/C++ and your string contained "\". This is an
escape character in C strings. If you want your path to be
passed to MATLAB, you need to escape the escape character:

engEvalString(ep, "cd 'C:\\Documents and Settings\\Dave\\My
Documents\\Visual Studio 2005\\Projects\\Matlab MEX';");

oops.

Right, but I'm saying that with the escape characters in the
string the compiler actually complained that D and D and M
and V and P and M were not valid escape characters.

When I had some other matlab stuff in my c++ code WITH the
escape characters, the compiler didnt complain and compiled
fine. When I removed the other matlab stuff, and still had
the escape characters, it complained about the escape
characters. See what I'm saying? I no longer have a
question about it because it works not, but it was really odd.

"John Reilly" <jrhokie1.nospam@yahoo.com> wrote in message
<fre6t6$rm7$1@fred.mathworks.com>...
> I'll tell you why it ignored your "cd" command: you're
> using C/C++ and your string contained "\". This is an
> escape character in C strings. If you want your path to be
> passed to MATLAB, you need to escape the escape character:
>
> engEvalString(ep, "cd 'C:\\Documents and Settings\\Dave\\My
> Documents\\Visual Studio 2005\\Projects\\Matlab MEX';");
>
> oops.
>

Here is a complete working example. Maybe by comparing this
to what you have you can decipher what is wrong with your
code. Call the following file myfunc.cpp and make sure it
is on the MATLAB path. This is a simple mex function that
computes a quadratic function with obvious min at x = 4.0.
-------------------------------------------------
#include "mex.h"
#include "matrix.h"

double quadratic(double x)
{
  return 3.0 + (x - 4.0)*(x - 4.0);
}

void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[] )
{
  plhs[0] = mxCreateDoubleMatrix(1,1, mxREAL);
  *mxGetPr(plhs[0]) = quadratic(*mxGetPr(prhs[0]));
}
-------------------------------------------------
mex it as follows:

>> mex myfunc.cpp

Then call the following file engfunc.cpp. I used fminsearch
instead of fminunc for this example. This program opens the
engine, creates a function handle to the mex function
myfunc, calls fminsearch to find the minimum of this mex
function starting with a guess of 0, then gets the result
into the C++ code and displays it. I left the engine
running, but of course you could close it if you wanted to.
-------------------------------------------------
#include <iostream>
#include "engine.h"

using namespace std;

int main()
{
    Engine *ep;
    mxArray *test2;
    
    ep = engOpen( NULL );
    engEvalString( ep, "fun = @myfunc;" );
    engEvalString( ep, "a = fminsearch(fun,0);" );
    if( test2 = engGetVariable( ep, "a" ) )
    {
        cout << *mxGetPr( test2 ) << endl;
        mxDestroyArray( test2 );
    }
    else
    {
        cout << "Didn't work" << endl;
    }
}
-------------------------------------------------
I compiled it as follows for VC++ 8.0:
>> options = [matlabroot
'\bin\win32\mexopts\msvc80engmatopts.bat'];
>> mex('-f', options, 'engfunc.cpp', '-v');

You will of course have to modify this for your particular
compiler.

Then you can execute it as follows to find the minimum of
myfunc and display it to the screen from your engine app:

>> !engfunc
    4

I haven't included any error checking in the code to keep
things simple for the example. Well, no, actually the real
reason is that it is late and I am tired and just lazy, but
pretend the first reason I just gave is the correct one.

James Tursa

James, thanks for the example. However, I was able to get
that way working. What I need is for quadratic(double x) to
be in engfunc.cpp. This is my "main" program in which the
cost function relies on many other functions - I cannot
transfer them all to myfunc.cpp.

Is this possible?

"James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in
message <frftgn$630$1@fred.mathworks.com>...
>
> Here is a complete working example. Maybe by comparing this
> to what you have you can decipher what is wrong with your
> code. Call the following file myfunc.cpp and make sure it
> is on the MATLAB path. This is a simple mex function that
> computes a quadratic function with obvious min at x = 4.0.
> -------------------------------------------------
> #include "mex.h"
> #include "matrix.h"
>
> double quadratic(double x)
> {
> return 3.0 + (x - 4.0)*(x - 4.0);
> }
>
> void mexFunction( int nlhs, mxArray *plhs[],
> int nrhs, const mxArray *prhs[] )
> {
> plhs[0] = mxCreateDoubleMatrix(1,1, mxREAL);
> *mxGetPr(plhs[0]) = quadratic(*mxGetPr(prhs[0]));
> }
> -------------------------------------------------
> mex it as follows:
>
> >> mex myfunc.cpp
>
> Then call the following file engfunc.cpp. I used fminsearch
> instead of fminunc for this example. This program opens the
> engine, creates a function handle to the mex function
> myfunc, calls fminsearch to find the minimum of this mex
> function starting with a guess of 0, then gets the result
> into the C++ code and displays it. I left the engine
> running, but of course you could close it if you wanted to.
> -------------------------------------------------
> #include <iostream>
> #include "engine.h"
>
> using namespace std;
>
> int main()
> {
> Engine *ep;
> mxArray *test2;
>
> ep = engOpen( NULL );
> engEvalString( ep, "fun = @myfunc;" );
> engEvalString( ep, "a = fminsearch(fun,0);" );
> if( test2 = engGetVariable( ep, "a" ) )
> {
> cout << *mxGetPr( test2 ) << endl;
> mxDestroyArray( test2 );
> }
> else
> {
> cout << "Didn't work" << endl;
> }
> }
> -------------------------------------------------
> I compiled it as follows for VC++ 8.0:
> >> options = [matlabroot
> '\bin\win32\mexopts\msvc80engmatopts.bat'];
> >> mex('-f', options, 'engfunc.cpp', '-v');
>
> You will of course have to modify this for your particular
> compiler.
>
> Then you can execute it as follows to find the minimum of
> myfunc and display it to the screen from your engine app:
>
> >> !engfunc
> 4
>
> I haven't included any error checking in the code to keep
> things simple for the example. Well, no, actually the real
> reason is that it is late and I am tired and just lazy, but
> pretend the first reason I just gave is the correct one.
>
> James Tursa
>

"David Doria" <daviddoria@gmail.com> wrote in message
<frgbgs$hn8$1@fred.mathworks.com>...
> James, thanks for the example. However, I was able to get
> that way working. What I need is for quadratic(double x) to
> be in engfunc.cpp. This is my "main" program in which the
> cost function relies on many other functions - I cannot
> transfer them all to myfunc.cpp.
>
> Is this possible?

No. The MATLAB engine cannot make calls back into your C++
code, and there is no way to call MATLAB functions directly
from within your C++ main application code.

For a mex routine you can use mexCallMATLAB to make direct
calls to MATLAB functions, but there is no equivalent
engCallMATLAB function available. I have written an
engCallMATLAB function to do this (see FEX submission
17494), but this submission merely mimics this capability
with a series of engPutVariable, engEvalString, and
engGetVariable calls. This is the only way to call a MATLAB
function from within your C++ main application.

But I don't understand why you can't simply make a simple
mexFunction front end file, include your entire application,
and make make a mex routine out if it that way. Don't worry
about having a bunch of extra stuff (some of which, like the
console i/o, won't even work in a mex routine) in this file,
since you won't be using that part of the code anyway. Don't
worry about stripping out only those functions you need.
Just put the mexFunction up front and call your desired
functions and return a plhs[0] appropriately and let the
other stuff be dead code. It seems like this would work just
fine with a minimum amount of work on your part. Are you
saying that somehow your mex function needs to communicate
with your engine application code while it is calculating a
result? Or that your engine application code needs to give
the mex function extra inputs that are determined in real
time? Or what? Please clarify.

James Tursa

Sorry I was not clear. The actual c++ function I want to
minimze is

double CostFunction();

CostFunction() calls many other functions such as
DistanceToPoint(), DistanceToPolygon() blah blah and also
records alot of things that are globals for the sake of the
OpenGL portion of my program. Also, these Distance()
functions that I mention rely on alot of classes that I
wrote such as
class Polygon
class Edge
etc

I don't see how I can mex call of those things. Maybe I
simply can't do this. I found a package called GSL (GNU
scientific library) that has some unconstrained
minimization, and also a package for GSL called OOL (Open
Optimization Library) that contains some basic constrained
minimization functions. These seem to work fine, but I
would have like to confirm their results with the matlab
fminunc() and fmincon() functions.

Thanks for all your help - at least I learned alot about mex
even if I can't apply it to this problem!

David

"David Doria" <daviddoria@gmail.com> wrote in message
<frh3ul$qi1$1@fred.mathworks.com>...
> Sorry I was not clear. The actual c++ function I want to
> minimze is
>
> double CostFunction();

I don't get it. What is the independent variable here? Cost
function based on what independent input(s)? How were you
thinking of calling fminunc or fmincon?

> CostFunction() calls many other functions such as
> DistanceToPoint(), DistanceToPolygon() blah blah and also
> records alot of things that are globals for the sake of the
> OpenGL portion of my program. Also, these Distance()
> functions that I mention rely on alot of classes that I
> wrote such as
> class Polygon
> class Edge
> etc
>
> I don't see how I can mex call of those things. Maybe I
> simply can't do this.

Compiling is not the issue, really. You can use all of your
classes and custom functions in a mex routine. Think of it
this way: A mex routine is a dll with no console i/o
capability that hooks directly into MATLAB as a callable
function, whereas an engine application is a stand-alone
program with full console i/o capability that communicates
with a separate MATLAB process via (I think) a COM link. But
in both cases you still have full access to everything that
a C++ compiler can compile.

Sounds like you need your mex routine to communicate data
with your engine application (i.e., the globals you mention
and maybe other things). Is this correct? If so, then that
is going to be a problem. We can probably set up something
to transmit fundamental types back & forth (int, double,
etc.), but if you need to transmit class variables back &
forth then that would be a huge issue and probably not worth
the effort.

> I found a package called GSL (GNU
> scientific library) that has some unconstrained
> minimization, and also a package for GSL called OOL (Open
> Optimization Library) that contains some basic constrained
> minimization functions. These seem to work fine, but I
> would have like to confirm their results with the matlab
> fminunc() and fmincon() functions.

If you can set your problem up so that your cost function
fits into something fminunc and fmincon can handle, then
maybe it can be done. But if you have a lot of global class
variable etc that your cost function depends on, then it
will probably be too much work.

James Tursa