MATLAB.jl

[Dahua]

I created a package MATLAB.jl (https://github.com/lindahua/MATLAB.jl). 

This package allows users to call MATLAB functions from within Julia, thus making it easier to use the sheer amount of toolboxes available in MATLAB. I also believe this would be helpful for people to are migrating from MATLAB to Julia.

Some code snippets to give you a brief impression

using MATLAB

restart_default_msession()   # Open a default MATLAB session

x = linspace(-10., 10., 500)

@mput x                  # put x to MATLAB's workspace

@matlab plot(x, sin(x))  # evaluate a MATLAB function

x = linspace(-5., 5. 100)

y = x

@mput x y

@matlab begin

    (xx, yy) = meshgrid(x, y) 

    mesh(xx, yy, xx.^2 + yy.^2)

end
xx = jarray(get_mvariable(:xx))
yy = jarray(get_mvariable(:yy))

close_default_msession()    # close the default session (optional)

Enjoy! And please let me know your feedback. More functions are to be added soon.

If there is no substantial revision is needed, I may add it to METADATA.jl soon.

[Viral Shah]

This could be quite useful for Matlab users wanting to transition to julia.

Just from an aesthetics and symmetry perspective, it would be nice if there was an equivalent @mget, corresponding to @mput. I suggest using names such as @matlab_get and @matlab_put (avoid the underscore if you do not like it), which are more descriptive.

-viral

[Dahua]

Viral,

Thanks for the suggestion. Actually, I initially provided a @mget macro (it is easy to write one). But I am not completely sure what its behavior should be.

There are actually two issues related to converting MATLAB variables to Julia variables:

First, it is the issue of memory management. When the C-API mxGetVariable of MATLAB makes a deep copy of the variable to returns it. Then it will leave the Julia code to manage its life cycle. For the sake of performance, the function jarray only make a view of the returned object instead of doing another deep copy. So people have to write code as follows

x = get_mvariable(:a)  # return an instance of MxArray
a = jarray(x)          # makes a view of x (using pointer_to_array internally)
...                    # do stuff on a
delete(x)              # free the memory in x

If there is a way to attach x (an use-defined object) to a (an instance of Array), then I can use finalizer to simplify the memory management cycle though. Otherwise the finalizer associated with a doesn't know what to delete.

Second, the mapping from MATLAB to Julia is one-to-one. MATLAB is known to represent everything as a matrix (such as scalars and vectors)

Suppose a is a MATLAB variable (equivalent to 1x1 matrix), should "@mget a" make a scalar or a matrix of size 1-by-1? 

Such issues exist for other types. For example, if a is a char array, should it be converted to a String or a Array{Char}?, etc.

Another approach would be to just let @mget create a MxArray instance. And the user should choose to convert it in a way that they see fit. The package does provide a set of functions to do the conversion.

I am looking for suggestions on this.

[Dahua]

On Tuesday, March 5, 2013 11:28:14 AM UTC-6, Dahua wrote:

Viral,

Thanks for the suggestion. Actually, I initially provided a @mget macro (it is easy to write one). But I am not completely sure what its behavior should be.

There are actually two issues related to converting MATLAB variables to Julia variables:

First, it is the issue of memory management. When the C-API mxGetVariable of MATLAB makes a deep copy of the variable to returns it. Then it will leave the Julia code to manage its life cycle. For the sake of performance, the function jarray only make a view of the returned object instead of doing another deep copy. So people have to write code as follows

x = get_mvariable(:a)  # return an instance of MxArray
a = jarray(x)          # makes a view of x (using pointer_to_array internally)
...                    # do stuff on a
delete(x)              # free the memory in x

If there is a way to attach x (an use-defined object) to a (an instance of Array), then I can use finalizer to simplify the memory management cycle though. Otherwise the finalizer associated with a doesn't know what to delete.

Second, the mapping from MATLAB to Julia is one-to-one.

Ooh, typo ==> the mapping from MATLAB to Julia is NOT one-to-one.

[Toivo Henningsson]

About typing: how about

@mget x::String
@mget x::Vector
@mget x::Number

etc to specify the type that you want to get back? If no type is specified, you could default to the most general representation of an object, often a Matrix.

[Steven G. Johnson]

On Monday, March 4, 2013 11:25:18 PM UTC-5, Dahua wrote:

I created a package MATLAB.jl (https://github.com/lindahua/MATLAB.jl). 

This package allows users to call MATLAB functions from within Julia, thus making it easier to use the sheer amount of toolboxes available in MATLAB. I also believe this would be helpful for people to are migrating from MATLAB to Julia.

It might be nice to have an mxcall function to call Matlab functions directly without pushing global variables into the Matlab workspace, e.g.

   mxcall(:plot, x, y)

that converts its arguments to MxArray, calls the :plot function, calls "plot" (via mexCallMATLAB, see http://www.mathworks.com/help/matlab/apiref/mexcallmatlab.html), and returns the value as another mxArray.

--SGJ

PS. Shouldn't MxArray have a finalizer to deallocate the matrix when it is garbage-collected?

[Dahua]

Great idea! I will try along this line.

[Dahua]

Hi, Steven

I was aware of such functions. 

Unfortunately, all those functions with prefix mex (e.g. mexCallMATLAB) is supposed to be called only within a mex function. Though not taking a MATLAB session as an argument, such functions actually have quite complex interactions with the host session.

So it is fine that if you open MATLAB and run a mex file (which internally calls mexCallMATLAB). But you are not able to use this function externally. 

[Steven G. Johnson]

On Tuesday, March 5, 2013 1:11:30 PM UTC-5, Dahua wrote:

Hi, Steven

I was aware of such functions. 

Unfortunately, all those functions with prefix mex (e.g. mexCallMATLAB) is supposed to be called only within a mex function. Though not taking a MATLAB session as an argument, such functions actually have quite complex interactions with the host session.

That's too bad.  Of course, you could still implement an mxcall("func", args...) by pushing the arguments to Matlab as variables jl_mxcall_arg1, jl_mxcall_arg2, etcetera and then calling func as a string to evaluate with these arguments.

[Dahua]

@mget has been implemented.

You can now write

@mput x y

@matlab begin

    u = x + y

    v = x - y

end

@mget u v

Also, it now supports the syntax proposed by Toivo (i.e. specifying the kind of variable to get), as

@mget u::Vector v::Array

[Dahua]

Many more functions are added.

It now supports a most builtin data types in MATLAB (including numeric arrays, logical arrays, structs, cell arrays, strings, and sparse matrices), and the conversion between these types and Julia variables. 

It provides @mput to put variables to MATLAB, @mget to retrieve variables from MATLAB, and @matlab to evaluate a statement.

According to Steven's suggestion, it also provides an mxcall function, with which you can directly call a MATLAB function on Julia variables. (This function internally puts inputs to MATLAB, and gets results from MATLAB, so it may incur some overhead for communication between these two domains).

I will submit this to METADATA.jl soon. 

[Tim Holy]

This looks very useful, thanks for tackling it!

--Tim

[Vectorman]

Thank you Dahua

[Vectorman]

Is this usable in Windows? if so what is the installation procedure?

Many Thanks,

Aeron

[Dahua]

Hi Aeron,

I haven't tested this on Windows yet, as my major development platforms are Ubuntu and Mac OS.

Most part of the package is platform-independent. The key of having it work in Windows is to let dlopen find "libmx.dll" and "libeng.dll". I will verify the detailed procedure in a Windows VM and added the instructions later.

- Dahua

[Vectorman]

Thank you Dahua, that would be really helpful.  

[Vectorman]

Hi Guys,

Does anyone know how to get this working on windows or is there another alternative? I tried Tim's zeroMQ and couldn't get the mex files to compile in matlab....

Thank you

[Tim Holy]

...and I don't know enough about Windows to suggest how to fix it!

--Tim

[Keno Fischer]

I'll see if I can help out. Won't get to it until later though. 

[Dahua]

For this to be used in windows:

there are two steps:

1. add $matlabroot\bin\win32 or $matlabroot\bin\win64 to the PATH environment variable. So the engine knows where to find MATLAB. Here $matlabroot is the path of the root folder in which your MATLAB resides.

2. add $MATLABROOT\extern\lib\win32\microsoft or $MATLABROOT\extern\lib\win64\microsoft to a directory where dlopen would look for the DLL files.

But I don't know how dlopen determine where to look for dll files in windows. Any hints here?

As along as both steps are done, you should be able to use MATLAB.jl.

[Dahua]

I would like to announce a recent update to this package. 

The package now supports various ways to read/write mat files. See https://github.com/lindahua/MATLAB.jl#readwrite-mat-files for details.

One difference from MAT.jl is that these functions allow you to get variables as an instance of MxArray and use the tools provided by these package to convert them to Julia variables in any way you want. They also allow you to only retrieve a subset of variables.

- Dahua

[Jonathan Malmaud]

Great work. Do you have a sense of how the performance of reading/writing very large .mat files with matlab.jl compares to MAT.jl? 

[Dahua]

Did not do a benchmark. As they both rely on HDF5 under the hood, I guess there won't be huge difference in performance. I just feel that they are more flexible for my own projects.

- Dahua