> 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. 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 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. 2. FFTW. 3. Java VM. 4. More users. 5. Better documentation. > 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
