On Sun, Aug 15, 2010 at 1:43 PM, Sturla Molden <stu...@molden.no> wrote: > >> Could those contributing here put up a Cookbook page of "reasons why >> we've moved on from MATLAB", to be used as a resource by people trying >> to convince supervisors/professors/sponsors/clients that they should >> be allowed to use Python? > > There are many reasons, to name a few: > > 1. Ease of programming. Python is just a better language. Python is a > general purpose language, MATLAB is restricted to simple numerical code. > Python is easier to read (Matlab is more like Ruby or Lua). > > 2. Pass-by-value of arrays in Matlab. This basically means Matlab is > unsuable for work with large data sets. Serious Matlab programming usually > mean C programming with MEX wrappers. I find myself writing much more C or > C++ when working with Matlab, which seriously impairs my productivity and > creativity (it is easier to prototype and experiment in Python than C). > > 3. Better integration with C and Fortran in Python. Cython, ctypes and > f2py is a lot easier than hand-coding CMEX and FMEX wrappers. C and > Fortran integration is important for scientific computing. Also, Matlab > does not play well with Fortran 95, just Fortran 77. For scientific > computing, C, C++ and Fortran 77 are PITAs compared to Fortran 95. I even > prefer Cython to the former three. > > 4. Matlab is single-treaded. Python allows threads, although there is a > GIL (which can be freed when running C or Fortran library code). Matlab > use MKL for multi-cores, NumPy/SciPy can be compiled against MKL or ACML. > Threads are not just for parallel processing, but also for I/O and GUI > interaction. > > 5. Heap-fragmentation makes long-running (32-bit) Matlab processes > unstable. Instead of fixing the broken allocator, Matlab has a "pack" > command that must be run e.g. once an hour. A long-running Python process > can be trusted to complete if the code is stable, not so with Matlab in my > experience. One has to save the state of the Matlab simulation/analysis > regularly, and restart from where it stopped. > > 6. Matlab saves figures by taking a copy of the screen buffer. It is very > annoying to discover that a long-running process has saved dozens of > images of the screen saver, Windows' login screen, totally black images, > or the mouse pointer. > > 7. Can we use OpenGL or VTK easily from Matlab? > > 8. GUI programming: Compare Matlab's rudimentary GUI support with wxPython > or PyQt. > > 9. It is easy to use MPI from Python (e.g. mpi4py or just ctypes with the > MPI library). The multiprocessing package also makes Python > multiprocessing and IPC easy. Matlab has a huge fingerprint. Do you want > multiple Matlab instances running in parallel? How much RAM do you have? > > 10. Memory-mapping is not usable in Matlab due to e.g. pass-by-value > semantics, even though it is theoretically possible to memory map a file > using a C MEX function. In Python we can memory map a file and alias the > buffer with a NumPy array. > > 11. Database-support. Python has support for most major databases, and > even has embedded dabases included in the standard library (e.g. bsddb and > sqlite). Python supports HDF5 (PyTables and h5py). Efficient use of HDF5 > is difficult from Matlab due to pass-by-value semantics. > > 12. Python costs less, even when subscribing to Enthough. > > 13. Matlab toolboxes cost extra. There is no extra fee to use scipy.signal > and scipy.stats.
The cost and the licensing headaches I have had with MATLAB in our labs and with my student version (32-bit only though they don't tell you this until after purchase that I saw, one machine only, and one OS only even if it's on the same machine/same user) have really turned me off from using it even though it is more or less the standard for macroeconomics at the moment. I also found getting my 32-bit MATLAB to compile C extensions on a 64-bit system/software to be a PITA (somewhat related, I still haven't been able to install mlabwrap), but maybe that's just my lack of knowledge. > > 14. Google and NASA use Python. > > 15. It is easier to teach Python to students. My university (Oslo) use > Python as teaching language for that reason. That is, with this textbook > written for teaching Python to science students: > > http://books.google.no/books?id=cVof07z_rA4C&printsec=frontcover#v=onepage&q&f=false And it's a no-brainer to go to MATLAB after learning the ins and outs of Python. Python has a much better community for beginners (any level really) I think. Python gives you the skill set to work in other languages and environments while the converse is not necessarily true. > > 16. Matplotlib makes nicer figures (e.g. antialiased rendering). > > 17. It is easy to spawn processes from Python and communicate with pipes. > Thus we can use external programs easily from Python. > > 18. Python's standard library has support for almost any thinkable > problem. The number of external libraries is immense. > > 19. Another memory issue: NumPy does not make a copy when creating a view. > We don't need to copy data to reference strided array sections or > subarrays. NumPy works like Fortran 95 pointers, which is very memory > efficient and expressive for numerical work. > > 20. Etc. (I could go on and on, but have to stop somewhere.) > > > Some strong points for Matlab: > > 1. The IDE, debugger, and interactive prompt. ipython cannot compare to > Matlab. Though Spyder is coming along nicely. > > 2. FFTW. > > 3. Java VM. > > 4. More users. > > 5. Better documentation. > And as Josef mention, the file exchange is nice, though a lot of the code is BSD licensed. My $.02, Skipper > > >> A similar page for IDL would be great....and did anyone notice that >> IDL 8.0 has a number of language enhancements, all designed to make it >> more like Python? Sadly, they fall well short. > > IDL feels too much like FORTRAN IV, whcih by the way is an F-word. > > > > > > Sturla > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
