[Numpy-discussion] [SciPy-Dev] Good-bye, sort of (John Hunter)
Sun Aug 15 13:00:38 CDT 2010
On Sun, Aug 15, 2010 at 1:43 PM, Sturla Molden <email@example.com> 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
> 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:
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
> 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
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.
>> 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.
> NumPy-Discussion mailing list
More information about the NumPy-Discussion