Subject:Re: Python from MatlabFrom:Pablo Riera <pablo.riera@xxxxxxxx>Date:Tue, 26 Aug 2014 02:20:00 -0300List-Archive:<http://lists.mcgill.ca/scripts/wa.exe?LIST=AUDITORY>--047d7bdc8d5ebaa46005018175c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just see this link and I thought it has a lot of information relevant to what was discussed in this thread. http://stackoverflow.com/questions/9845292/a-tool-to-convert-matlab-code-to= -python Bests, 2014-08-25 4:30 GMT-03:00 Etienne Gaudrain <e.p.c.gaudrain@xxxxxxxx>: > Hi Jont, > > There are a few benchmarks around (although results change very quickly), > and Dan can probably comment more on this. My experience is that default > Scipy/Numpy packages are generally on a par or a bit slower than Matlab. > But on big projects with a lot of nested function calls or GUI elements > Matlab quickly becomes slow (or at least that was the case in the pre-JIT > days, don't know how it is now). The fact that you can explicitly control > thread in Python can also help making things much more efficient (without > the need of a terrible expensive toolbox), especially for realtime > processing. But I think what makes Python glamorous (for those who need i= t) > is the possibility to include C code, directly in the Python file, for > things that need to be very fast. That's more elegant than doing a mex > file. And of course you can also recompile Numpy and Scipy on your machin= e > for a bit of extra performance. > > But to be fair I'm probably not the best person to answer this as I > generally only use Python for things Matlab is really poor at: > - GUI programming (because you want a properly object-oriented language > for that, with clear thread handling) > - Text manipulations (or actually any data manipulation that's not in > native Matlab format) > - Figure plotting (because Matlab is so painfully limited) > - Any general purpose task for which a signal-processing oriented languag= e > is not suited for > > Typically, when I program an auditory experiment, I use Matlab if I need = a > very basic GUI, but Python if I need anything a bit more fancy. I use > Matlab for all the signal processing (real time or not) and sound > presentation. Then I use Matlab for data pre-processing and Python and R > for data analysis/plotting. > > If I didn't depend on things like STRAIGHT, or until now, auditory models= , > I would probably switch altogether to Python to simplify my working > environment and save the cost of a Matlab license. > > Best, > -Etienne > > > > On 24/08/2014 18:20, Jont Allen wrote: > >> Etienne >> What was your feeling about the relative performance of matlab vs python= , >> computationally? >> Jont >> >> On 08/23/2014 03:38 PM, Etienne Gaudrain wrote: >> >>> Hi Alain, >>> >>> The few times I had to do that, I actually programmed everything in >>> Python using mlabwrap, and called the script with a system command from >>> Matlab... >>> >>> Another option seem to be using JPython, the Java implementation of >>> Python, which can be fully integrated in Matlab's Java interface, but I >>> must admit I have no clue how (and I hear that not all libraries are >>> implemented in JPython). >>> >>> Otherwise, it looks like someone wrote a client/server interface: >>> https://code.google.com/p/python-matlab-wormholes/ >>> Haven't tried it though. >>> >>> Good luck! >>> -Etienne >>> >>> >>> On 22/08/2014 23:30, Alain de Cheveigne wrote: >>> >>>> [To list members not interested in Matlab, etc.: apologies for the >>>> annoyance. The discussion is somewhat relevant to audition, in that >>>> modeling, experiment control, and data analysis increasingly rely on >>>> computers, and the choice of a high-quality computation environment is >>>> crucial.] >>>> Hi Jan, >>>> >>>> A client/server solution indeed sounds ideal. I don't know what it >>>> involves in terms of programming effort, but I'm sure that effort woul= d be >>>> well spent. >>>> >>>> The ideal solution would be: >>>> - simple to use, like calling "result=3DtoPython(' >>>> pythonFunction',arguments);" >>>> - efficient, i.e. minimal overhead for data transfer, >>>> - reliable, system-independent, and future-proof, >>>> - secure. >>>> >>>> Several people mentioned calling Python via a shell command, passing >>>> values by file, etc. I'm concerned that these solutions might involv= e >>>> greater overhead, more complex syntax, possibly greater system >>>> dependencies, and possibly security issues. >>>> >>>> Alain >>>> >>>> >>>> >>>> On 22 Aug 2014, at 13:47, Jan Schnupp <jan.schnupp@xxxxxxxx> >>>> wrote: >>>> >>>> Or you could >>>>> python and matlab work together on some sort of client/server model. >>>>> That would be more elegant - the matlab and python parts then wouldn'= t >>>>> even have to be on the same machine, but the programming investment i= s >>>>> very large. I don't know of any developments to make this sort of >>>>> stuff easier that are even on the distant horizon. If other list >>>>> members know of any I would be interested to hear about them. >>>>> >>>> > -- > Etienne Gaudrain, PhD > UMCG, Afdeling KNO, BB20 > PO Box 30.001 > 9700 RB Groningen, NL > > Room P3.236 > Phone +31 5036 13290 > Skype egaudrain > > Note: emails to this address are limited to 10 MB. To send larger files, > use egaudrain.cam@xxxxxxxx > --=20 =E2=99=AB --047d7bdc8d5ebaa46005018175c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I just see this link and I thought it has a lot of informa= tion relevant to what was discussed in this thread.=C2=A0<div><br></div><di= v><a href=3D"http://stackoverflow.com/questions/9845292/a-tool-to-convert-m= atlab-code-to-python">http://stackoverflow.com/questions/9845292/a-tool-to-= convert-matlab-code-to-python</a><br> </div><div><br></div><div>Bests,</div><div><br></div><div class=3D"gmail_ex= tra"><br><br><div class=3D"gmail_quote">2014-08-25 4:30 GMT-03:00 Etienne G= audrain <span dir=3D"ltr"><<a href=3D"mailto:e.p.c.gaudrain@xxxxxxxx" tar= get=3D"_blank">e.p.c.gaudrain@xxxxxxxx</a>></span>:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Hi Jont,<br> <br> There are a few benchmarks around (although results change very quickly), a= nd Dan can probably comment more on this. My experience is that default Sci= py/Numpy packages are generally on a par or a bit slower than Matlab. But o= n big projects with a lot of nested function calls or GUI elements Matlab q= uickly becomes slow (or at least that was the case in the pre-JIT days, don= 't know how it is now). The fact that you can explicitly control thread= in Python can also help making things much more efficient (without the nee= d of a terrible expensive toolbox), especially for realtime processing. But= I think what makes Python glamorous (for those who need it) is the possibi= lity to include C code, directly in the Python file, for things that need t= o be very fast. That's more elegant than doing a mex file. And of cours= e you can also recompile Numpy and Scipy on your machine for a bit of extra= performance.<br> <br> But to be fair I'm probably not the best person to answer this as I gen= erally only use Python for things Matlab is really poor at:<br> - GUI programming (because you want a properly object-oriented language for= that, with clear thread handling)<br> - Text manipulations (or actually any data manipulation that's not in n= ative Matlab format)<br> - Figure plotting (because Matlab is so painfully limited)<br> - Any general purpose task for which a signal-processing oriented language = is not suited for<br> <br> Typically, when I program an auditory experiment, I use Matlab if I need a = very basic GUI, but Python if I need anything a bit more fancy. I use Matla= b for all the signal processing (real time or not) and sound presentation. = Then I use Matlab for data pre-processing and Python and R for data analysi= s/plotting.<br> <br> If I didn't depend on things like STRAIGHT, or until now, auditory mode= ls, I would probably switch altogether to Python to simplify my working env= ironment and save the cost of a Matlab license.<br> <br> Best,<br> -Etienne<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <br> On 24/08/2014 18:20, Jont Allen wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Etienne<br> What was your feeling about the relative performance of matlab vs python, c= omputationally?<br> Jont<br> <br> On 08/23/2014 03:38 PM, Etienne Gaudrain wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Hi Alain,<br> <br> The few times I had to do that, I actually programmed everything in<br> Python using mlabwrap, and called the script with a system command from<br> Matlab...<br> <br> Another option seem to be using JPython, the Java implementation of<br> Python, which can be fully integrated in Matlab's Java interface, but I= <br> must admit I have no clue how (and I hear that not all libraries are<br> implemented in JPython).<br> <br> Otherwise, it looks like someone wrote a client/server interface:<br> <a href=3D"https://code.google.com/p/python-matlab-wormholes/" target=3D"_b= lank">https://code.google.com/p/<u></u>python-matlab-wormholes/</a><br> Haven't tried it though.<br> <br> Good luck!<br> -Etienne<br> <br> <br> On 22/08/2014 23:30, Alain de Cheveigne wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> [To list members not interested in Matlab, etc.: apologies for the annoyanc= e.=C2=A0 The discussion is somewhat relevant to audition, in that modeling,= experiment control, and data analysis increasingly rely on computers, and = the choice of a high-quality computation environment is crucial.]<br> =C2=A0 =C2=A0Hi Jan,<br> <br> A client/server solution indeed sounds ideal.=C2=A0 I don't know what i= t involves in terms of programming effort, but I'm sure that effort wou= ld be well spent.<br> <br> The ideal solution would be:<br> - simple to use, like calling "result=3DtoPython('<u></u>pythonFun= ction',arguments);"<br> - efficient, i.e. minimal overhead for data transfer,<br> - reliable, system-independent, and future-proof,<br> - secure.<br> <br> Several people mentioned calling Python via a shell command, passing values= by file, etc.=C2=A0 =C2=A0I'm concerned that these solutions might inv= olve greater overhead, more complex syntax, possibly greater system depende= ncies, and possibly security issues.<br> <br> Alain<br> <br> <br> <br> On 22 Aug 2014, at 13:47, Jan Schnupp <<a href=3D"mailto:jan.schnupp@xxxxxxxx= g.ox.ac.uk" target=3D"_blank">jan.schnupp@xxxxxxxx</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Or you could<br> python and matlab work together on some sort of client/server model.<br> That would be more elegant - the matlab and python parts then wouldn't<= br> even have to be on the same machine, but the programming investment is<br> very large. I don't know of any developments to make this sort of<br> stuff easier that are even on the distant horizon. If other list<br> members know of any I would be interested to hear about them.<br> </blockquote></blockquote></blockquote></blockquote> <br></div></div><div class=3D"HOEnZb"><div class=3D"h5"> -- <br> Etienne Gaudrain, PhD<br> UMCG, Afdeling KNO, BB20<br> PO Box 30.001<br> 9700 RB Groningen, NL<br> <br> Room P3.236<br> Phone +31 5036 13290<br> Skype egaudrain<br> <br> Note: emails to this address are limited to 10 MB. To send larger files, us= e <a href=3D"mailto:egaudrain.cam@xxxxxxxx" target=3D"_blank">egaudrain.ca= m@xxxxxxxx</a>.<br> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>= =C2=A0=E2=99=AB <br> </div></div> --047d7bdc8d5ebaa46005018175c2--

This message came from the mail archive

http://www.auditory.org/postings/2014/

maintained by: DAn Ellis <dpwe@ee.columbia.edu>

Electrical Engineering Dept., Columbia University