Pauli Virtanen wrote:
> Hi all,
>
> ti, 2006-11-07 kello 11:23 +0900, David Cournapeau kirjoitti:
>
>> I am trying to find a nice way to communicate between matlab and
>> python. I am aware of pymat, which does that, but the code is
>> deprecated, and I thing basing the code on ctypes would lead to much
>> more robust code.
>>
>> http://claymore.engineer.gvsu.edu/%7Esteriana/Software/pymat.html
>>
>> I have a really simple prototype which can send and get back data from
>> matlab, but I was wondering if it would be possible to use a scheme
>> similar to ctypes instead of having to convert it by hand.
>>
>
> A while ago I wrote a mex extension to embed the Python interpreter
> inside Matlab:
>
> http://www.iki.fi/pav/pythoncall
>
> I guess it's something like an inverse of pymat :)
>
>
Yes, but at the end, I think they enable similar things. Thanks for the
link !
> But I guess this is not really what you are looking for, since at
> present it just does a memory copy when passing arrays between Matlab
> and Python. Though, shared arrays might be just possible to implement if
> memory management is done carefully.
>
In my case, it is much worse:
1 first, you have numpy data that you have to copy to mxArray, the
structure representing arrays in matlab C api.
2 then when you "send" data to the matlab engine, this is done
automatically through pipe by the matlab engine API (maybe pipe does
not imply copying; I don't know much about pipe from a programming point
of view, actually)
3 The arrays you get back from matlab are in matlab mxArray
structures: right now, I copy their data to new numpy arrays.
At first, I just developed a prototype without thinking too much,
and the result was much slower than I thought: sending a numpy with
2e5x10 double takes around 100 ms on my quite powerful machine (around
14 cycles per item for the best case). I suspect it is because I copy
memory in a non contiguous manner (matlab arrays have a internal F
storage for real arrays, but complex arrays are really two different
arrays, which is different than Fortran convention I think, making the
copy cost really expensive for complex arrays). To see if I was doing
something wrong, I compared with numpy.require(ar, requirements =
'F_CONTIGUOUS'), which is even much slower
There is not much I can do about 2, it looks like there is a way to
avoid copying for 1, and my question was more specific to 3 (but
reusable in 1, maybe, if I am smart enough). Basically:
* how to create an object which has the same interface than numpy
arrays, but owns the data from a foreign structure, which data are
availble when building the object (The idea was to create a class which
implements the array interface from python, kind of proxy class, which
owns the data from mxArray; owns here is from a memory management point
of view).
David
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
