I am trying to create an interface for seamlessly calling MATLAB from Mathematica, based on an earlier program called mEngine. This program is based on MATLAB Engine, which seems to allow only the following operations:
What I need to do is create seamless wrappers for MATLAB functions (at least the simple ones) in Mathematica, e.g. something like this:
inv = wrapMatlabFunction["inv"] inv[matrix]
Then the Mathematica variable 'matrix' would be sent to MATLAB, the inv() function called on it, and the results returned.
The only way to transfer data to MATLAB using the MATLAB engine seems to be creating a (global) variable in the workspace (engPutVariable). This is ugly and may lead to naming conflicts with existing variables. Retrieving data also seems to be allowed only for variables (but not for function return values that are not assigned to a variable).
Is it possible to transfer data (a C array) to MATLAB for the purpose of passing it to a MATLAB function as argument without creating a global workspace variable? What about retrieving the result (and handling multiple return)?
If there's no way around creating intermediary variables, is there a way not to make them global (to avoid naming conflicts)?
Is there any other programming interface to MATLAB, apart from "MATLAB engine" that would make the task I described above easier and safer? I found MatlabControl, which is a Java interface, but it seems to rely on unsupported/undocumented functionality. It does have an feval function though.
*EDIT* I need a solution that works on OS X. I believe the COM interface doesn't.
Maybe you can adapt this FEX submission, which mimics the capability of mexCallMATLAB with an Engine interface:
Basically it puts all the variables into the Engine workspace under (hopefully) unique names, calls the function, retrieves the (hopefully) unique results, and cleans up after itself.
The documentation does not indicate that engPutVariable creates a global variable: it indicates that it creates a variable in the engine workspace. If you were to evaluate a string that used the "global" command then you should be able to access the true global workspace; likewise you should be able to access the base workspace via assignin(). It is not clear that the base workspace is the same or different than the engine workspace.
MATLAB has the global workspace, and the base workspace, and then it has one workspace per function. MATLAB does not have any operations to create independent workspaces, so it is not surprising that the engine interface does not offer any facility along those lines.
Possibly you are thinking that you would like to be able to create engine variables that are scoped (and automatically cleaned up) according to the scoping of the Mathematica function you are using. That might be convenient, but remember that MATLAB is operating as a completely different program that only does what it is told. So if you want some kind of scoping like this, you are going to have to implement it at the Mathematica level. Does modern Mathematica offer the equivalent of MATLAB's onCleanup() that is called automatically when the local scope is being destroyed (if it offers object oriented programming with local objects then the answer is Yes.) If it does then your wrapper can create a local object that does the cleanup on the MATLAB side.
What to use to avoid variable name classes? I would suggest structures on the MATLAB side, perhaps tables on the Mathematica side. Create a (random?) scope name, check to see if it is already in use, if not use that name as the structure name for the local variables; at the end of the routine, destroy the structure.