Matplotlib For Python Developers

Craig Maloney writes "Ever since there was a collection of numbers, it seems that invariably someone will want a graph of those numbers. There are literally hundreds of different styles of graphs, and almost as many programs and tools to make those graphs. Matplotlib, a library and toolkit for the Python language, provides an easy and effective way to make some impressive graphics with little more than a smattering of Python. Matplotlib for Python Developers is equally impressive at distilling the core set of features of Matplotlib in a way that shows the reader how to get the most out the Matplotlib toolkit." Read below for the rest of Craig's review. Matplotlib for Python Developers author Sandro Tosi pages 291 publisher Packt Publishing rating 9/10 reviewer Craig Maloney ISBN 978-1-847197-90-0 summary A comprehensive overview of the powerful Matplotlib Python library Matplotlib for Python Developers begins with the customary introduction to the Matplotlib library. It includes where to download Matplotlib, as well as brief installation instructions for both Linux, Macintosh, and Windows platforms. The book then quickly moves to the next chapter, where the basic library functions are presented, via the interactive iPython shell. Each section of the chapter introduces a new part of the graph, with items like titles, grid lines, and labels being explained clearly and concisely. Also briefly presented are other useful libraries like numpy, as well as the various back-ends that Matplotlib supports. Chapter 3 continues the even pace, presenting more plot styles, and plot types, including polar graphs. These two chapters cover the fundamentals of Matplotlib very well, with each step clearly marked by what the graph should look like once completed.

The next chapter introduces more advanced plotting concepts that Matplotlib is capable of handling. The chapter begins with the three ways that Matplotlib may be used (The pyplot module, pylab, and the Object Oriented interface). From there, the book delves into subplots, multiple figures, additional axes, logarithmic axes, date plotting, contour plots, and image plots. Also included are sections on using LaTeX and TeX with Matplotlib, both for exporting graphs, as well as using TeX inside plots via Mathtext. By the end of the chapter, I felt very comfortable with the environment and the capabilities of Matplotlib, both as an interactive environment, and as a module for my own programs.

The next four chapters cover integrating Matplotlib with GTK+, QT4, wxWidgets, and web-based environments. The chapters for GTK+, QT4, and wxWidgets each begin by presenting a basic overview of the toolkit, and why one might want to use that particular toolkit. Next, the book shows how to embed a Matplotlib figure in a window, both with static and real-time data input. The book then shows how to use the toolkit's builder with Matplotlib (Glade for GTK+, QT Designer for QT4, and wxGlade for wxWidgets. The chapter on web development veers slightly from this format by showing several examples of using CGI and mod_python with Matplotlib before showing how to use Matplotlib with Django and Pylons.

The last chapter pulls together some "real world" examples together for the grand finale. The examples clearly show how Matplotlib would work for such plotting Apache web logs, fitting curves, and plotting geographic data. The geographic data plotting uses an additional module called basemap, which allows for plotting precisely on a map. This example floored me with the amount of power that Matplotlib possesses.

Overall, I found this book to be informative, without a lot of fluff. The organization of the book sometimes dipped into a chaotic presentation of "oh, look at this", but overall the author kept a very even pace, with clearly defined goals and clean resolution of those goals. Matplotlib for Python Developers is definitely a book that I would pick up to refresh my memory for using Matplotlib. The asking price is a bit steep for book that is just shy of 300 pages, but overall I highly recommend it for anyone looking to get started with this exceptional library. I'd also recommend it for anyone looking for alternatives to some of the other plotting packages available. Matplotlib is quite powerful, and Matplotlib for Python Developers makes this power very accessible.

You can purchase Matplotlib for Python Developers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Why does everything need 250+ pages?

[Animats]

This is something that ought to be one chapter in a Python book, not another boat-anchor of a standalone book.

Re:Why does everything need 250+ pages?

[Em Emalb]

Because you don't become a matplotlib master by doing 12,000 things, you become a matplotlib master by doing 4 things 12,000 times.

Or something. Hell man, I agree with you.

Re:Why does everything need 250+ pages?

[kgibbsvt]

Have you actually used matplotlib? Like with any plotting package (or at least all the ones I've ever used) there are some subtle but important details where a 20 page handout just wouldn't do. You don't like the book, don't buy the f'ing thing.

- kg

Re:Why does everything need 250+ pages?

[goombah99]

Matplotlib which I use a lot, has really sucky documentation so this 250 pages would amount to basically all the documents. Additionally, you have to realize that matplot lib is not one coherent entity. it's a mish mash of many many things in numberical analysis much of it having to manage legacy cases and pertending to ape matlab syntax. So there's lots of special cases to cover.

On the otherhand I really have ot wonder sometimes if matplotlib is a dead project. All of the standard distro's have 3D plotting that doesn't work anymore or depend on packages that are not maintained. The only modern 3d plotting in matplot lib is available through the enthought distro that folds in mayav. But since it does not support the full syntax of matplot lib and invents it's own new object structure, it's hard to write programs that one can distribute. Your end users may not be using enthought.

Mat plot lib is wonderful because it lets matlab users switch to python. But it sucks because it seems like it's not being maintained well.

Re:Why does everything need 250+ pages?

[Hatta]

If you can't think of enough ways to graphically display information to fill a 250 page book, that says more about your lack of imagination than the utility of a plotting library.

Re:Why does everything need 250+ pages?

[ceoyoyo]

If your chosen python packager doesn't do an adequate job of including matplotlib then install it yourself. It's a double click (or equivalent) on the major platforms. Certainly not dead.

Re:Why does everything need 250+ pages?

[goombah99]

If your chosen python packager doesn't do an adequate job of including matplotlib then install it yourself. It's a double click (or equivalent) on the major platforms. Certainly not dead.

ha! have you ever tried to install the 3d packages or any of the advanced math stuff. it's most definitely not easy. it's dependency hell. hence the package manager is the only way that seems to work. It is true you can find a few binary distros out there. but again everything I said is true: the 3D depends on unmaintained packages and you can't find them in all distros. As a result it makes distributing code to other scientist a problem.

Re:Why does everything need 250+ pages?

[gnalle]

Is anybody working on a book about scipy? I would buy it.

Re:Why does everything need 250+ pages?

[ceoyoyo]

Yes, I have. The math stuff is just fine. The hardest part is usually installing LaTeX. The 3D stuff is unmaintained. There was some initial interest in it a few years ago and then it sort of died because there are other, better ways to plot in 3D. Even so, I believe the VTK integration still works reasonably well, and it just requires installing VTK and one other package. You might have a point that the third-party 3D addons to matplotlib are dead, but matplotlib itself certainly isn't.

The best way to distribute a Python environment is to tar the whole thing up and send it to whomever. An alternative is just to tar up the site-packages directory. For a long time I had a separate, easily accessible site-packages that could be packaged and distributed to everyone in the lab on a regular basis. On OS X you can even make a pretty double click installer in about five minutes.

Re:Why does everything need 250+ pages?

[goombah99]

The best way to distribute a Python environment is to tar the whole thing up and send it to whomever. An alternative is just to tar up the site-packages directory. For a long time I had a separate, easily accessible site-packages that could be packaged and distributed to everyone in the lab on a regular basis. On OS X you can even make a pretty double click installer in about five minutes.

I'd love some advice on this if you would care to share. I'm always afraid that when I do an install it will end up putting something into a tree I'll miss in a tar ball. The other problem is that when I'm using a distro like fink, I'm not sure how to make sure I include everything I need to send python in a self contained way without sending all of fink. Tips wold be apreciated. I'm not a python nuts and bolts genius, more of an end user.

Re:Why does everything need 250+ pages?

[ceoyoyo]

Since you mentioned Fink I'm assuming you're on a Mac?

On any Unix it's a good idea to do a Python install in someplace other than the system Python location. Particularly on the Mac. Some system scripts are written in Python and it's a good idea not to mess with the Python they depend on.

The standard way to do an install on the Mac is as a framework. If you're building Python from scratch, you use the flag --framework-install. I haven't done that for a while since the binaries available from python.org are excellent and it's much easier just to double click the installer.

The resulting Python environment will be completely self contained, in /Library/Frameworks/Python.framework. You can tar this up and send it to someone (or drag and drop it). So long as they untar it in the same place they'll have a duplicate of your Python environment. OS X actually treats Python.framework as a file in many cases, just as a .app is actually a folder, but gets treated like a file.

Making your framework Python run as default can be a little bit tricky. You've basically got two choices. You can alias "python" to /Library/Frameworks/Python.framework/Versions/Current/bin/pythonw or you can change the /usr/local/bin python to a link that points there. I think some installers might do the latter for you. I prefer the latter method since it works for all users.

You do just have to keep track of some of the other things that a given Python module might depend on. For example, if you're using LaTeX in matplotlib you'll need to have LaTeX installed. Unfortunately there isn't really any way around that, but external dependencies in Python modules are usually kept to a minimum.

To answer your Fink question, don't use Fink. At least not for Python. The native compiled version is MUCH nicer, and easier to get along with. For example, non-Fink matplotlib includes a Cocoa backend, so your graphs appear in native cocoa windows, rather than Tk rendered under X when using Fink.

Re:Why does everything need 250+ pages?

[goombah99]

thanks a lot. that really helped.

Re:Why does everything need 250+ pages?

[ceoyoyo]

Happy to help.

Miracle cure

[Anonymous Coward]

This book looks like a miracle cure for insomnia sufferers. Maybe I should show it to my doctor.

Matplotlib book report

[Anonymous Coward]

Well, as samzenpus already mentioned, the name of the book that I read was Matplotlib For Python Developers. It's about this library, a library for making graphs, and exporting graphs, and GTK+. Did I mention this book was written by a guy named Sandro Tosi? And published by the good people at Packt Publishing. So, in conclusion, on the Maloney scale of one to ten--ten being the highest, one being the lowest and five being average--I give this book a nine. Any questions?

Marketers making techical decisions.

[Anonymous Coward]

It's probably just another case of absolutely non-technical marketing executives making a decision regarding what's mostly a technical matter. They're a problem in every industry, unfortunately, including publishing.

Although they don't understand the technical matters they're dealing with, they'll often make wide-ranging technical decisions anyways, even when these decisions make no sense and ultimately lead to total failure.

Books that should be 20 pages long end up being 250. Web sites that should be simple end up getting infested with shitty Flash animations. The truth gets thrown out in favor of bullshit. That's just marketing for you.

*yawn*

[Anonymous Coward]

Wake me up when someone writes about Sillyplotadlib for Monty Python developers.

already reviewed

[mehemiah]

is it my imagination or has this been reviewed on slashdot before?

Re:already reviewed

[Em Emalb]

is it my imagination or has this been reviewed on slashdot before?

Re:already reviewed

[Anonymous Coward]

is it my imagination or has this comment been made on slashdot before?

Re:already reviewed

[bensch128]

is it my imagination or has this been reviewed on slashdot before?
--

Re:already reviewed

[mehemiah]

woops almost but not quite

Python for Scientific use

[Thelasko]

I've heard quite a few people here on Slashdot talk about how useful Python is as a substitute for MATLAB. Honestly, I don't get it. Python is trying to be a language for both hard core programming, and scientific programing. These two disciplines have very different needs. I don't want to load 20 modules before I can begin coding. I just want to input my algorithm and get a result I expect (not 5/2=2).

It seems that version 3.0 has gotten better for us scientific users. However, I think the programmers out there are now dissatisfied.

Re:Python for Scientific use

[maxume]

Why are you anthropomorphizing?

The core Python dev team is probably mostly agnostic towards changes that benefit scientists, especially if there are no costs to programmers, or huge amounts of maintenance.

Another group of people is working hard to make tools for doing science in Python.

Switching over to doing float division by default isn't that huge a change, and it is aimed at beginners, not scientists. If number literals had been converted over to being interpreted as rationals, maybe you'd have an argument there (scientists probably don't necessarily care if there are some inaccuracies introduced due to representational problems with various number types, but rationals are least likely to violate expectations).

Re:Python for Scientific use

[Anonymous Coward]

Put your 20 imports into a common module and import that then. Have you actually even used the language?

Re:Python for Scientific use

[markovg]

I've heard quite a few people here on Slashdot talk about how useful Python is as a substitute for MATLAB. Honestly, I don't get it.

MATLAB is a great product, and what it does it does well. But sooner or later you grow out of it, depending on how far you need to push it, and how much previous experience you have with real programming languages. When that day comes, Python is there waiting, and its can be sooo refreshing.

Re:Python for Scientific use

[kolabaum]

I would consider Octave to be a much better substitute for MATLAB rather than Python for those who just wants to 'get the job done'. That being said, however, I think anyone who uses Python for scientific work (for whatever reason) would greatly appreciate Matplotlib due to the resemblance to MATLAB's built-in plot functions.

Re:Python for Scientific use

[fuzzyfuzzyfungus]

Does loading those twenty modules hurt you if, by virtue of their being in common use, there is some trivial automated way of doing it?

With the exception of people writing bare-metal assembly for microcontrollers or something, pretty much everyone who sits down to write some code has huge swaths of pre-written stuff loaded for them. The only difference is how much of that happens automatically, by default, and how much you see and do yourself.

If the science types happen to like python for some syntactic or structural or design reasons; but need a bunch of modules to make it do what they want, it isn't exactly rocket surgery to bundle them all together so a single "import science" does the job, or even hack together a slight variant of the python environment where that particular import is simply done silently by default.

Re:Python for Scientific use

[LarryRiedel]

I've heard quite a few people here on Slashdot talk about how useful Python is as a substitute for MATLAB. Honestly, I don't get it.

I think there are many programs built on MATLAB which could be as easily and effectively built on Python and associated libraries. I do not see scipy/numpy/ipython/matplotlib as a dropin replacement for the MATLAB interactive environment, because they are different (even if equally capable).

Python is trying to be a language for both hard core programming, and scientific programing.

I do not feel like it is trying to be either. I think it is trying to be as suitable as it can for both of those things without compromising elegance.

I don't want to load 20 modules before I can begin coding. I just want to input my algorithm and get a result I expect (not 5/2=2).

Since I can trivially make a file "mystartup.py" with import statements like "from __future__ import division" and run the interpreter as "python -i mystartup.py", this seems like a non-problem to me.

Re:Python for Scientific use

[radtea]

I just want to input my algorithm and get a result I expect (not 5/2=2).

What result do you expect from 5/2? I expect 2... 5/2 == 2 in C, C++ and FORTRAN (I think... I don't write much FORTRAN code these days...)

Python does an excellent job of making both useful scientific functionality available via scipy and numpy and a wealth of other toolkits, and at the same time allowing us to package stuff up in usable applications. It provides all the real-world applications language facilities that MATLAB, Mathematica, R, etc lack.

I deal with people who "code" in those environments all the time, and they are not my peers: they have fundamentally failed to grasp almost everything important about programming, from design principles to documentation. For someone who knows how to write software--which MATLAB et al "programmers" do not, as a professional understands the term--Python is pretty much ideal for expressing algorithms and wrapping them in useful applications.

Re:Python for Scientific use

[0100010001010011]

Wake me when there is something even close to replace Simulink. Matlab is cool and all, but the real power of the program is Simulink.

Re:Python for Scientific use

[Helmholtz Coil]

That echoes my experience. I generally prefer Chaco for plots in Python since it seems to handle large datasets better than matplotlib (although matplotlib seems more functional), but matplotlib is comfortable for MATLAB users. I'm working on a SciPy project with a couple of MATLAB refugees and they love matplotlib.

Re:Python for Scientific use

[honkycat]

I use Python for scientific computing and much, much, much prefer it to MATLAB. Most of what I do does not require sophisticated library routines, and the sophisticated stuff I do need generally either aren't common enough to exist for MATLAB or are quirky enough that I wouldn't trust someone else's library to have the details right. Thus, the typically cited advantages of MATLAB are not there for me. Python provides a much better thought out programming language. It's sometimes a bit less convenient for interactivity, but really I got used to using it (plus matplotlib an numpy) quickly and I have not felt the urge to move back to MATLAB for quite some time. Very occasionally I'll pop in to do a crude curve fit, but not often.

The needs of scientific programming and hard core programming (whatever exactly that means) are not so different. As for not wanting to load modules, um, what? I can think of reasonable complaints about Python, but I don't consider that among them. That reeks of "it's different so I don't like it," which is not a well thought through reason.

Re:Python for Scientific use

[William Stein]

> I don't want to load 20 modules before I can begin coding. I just want to input my algorithm and get a result I expect (not 5/2=2). You might want to try Sage (sagemath.org and sagenb.org). It's Python, but it fixes the "5/2" issue and preloads numerous modules.

Re:Python for Scientific use

[Anonymous Coward]

Wow, don't ever use Fortran for scientific programming, then. It's just as picky about distinguishing between integer constants and real constants. I suspect, however, that people who actually do scientific programming are sufficiently well-versed in numerical methods to understand that distinction.

Re:Python for Scientific use

[MightyYar]

Depending on your requirements, Scicos might be what you are looking for.

Re:Python for Scientific use

[Anonymous Coward]

5/2=2

Ah, the infamous reverse Orwell.

Re:Python for Scientific use

[Helmholtz Coil]

I'd also add that when it comes to shipping code to a client, pointing them to a Python download vs. shelling out for a MATLAB license can be a factor as well. I like MATLAB but there's no denying there's a degree of sticker shock with it.

Re:Python for Scientific use

[Anonymous Coward]

Have you looked at scilab and Xcos (used to be called Scicos)? It looks similar to Simulink although I haven't had an excuse to use it yet.

Re:Python for Scientific use

[matt_martin]

Not even quite sure MATLAB "does what it does well". Its usually a great way to get started, especially if you don't quite know what you are doing. But then I often find myself wondering why I am working around bugs and re-writing functions in a $10k software package. Moved almost everything to python/numpy/scipy/Matplotlib over a year ago and really haven't looked back.

Here's one thing that Matplotlib should not have replicated from MATLAB: insane memory usage.
Please folks, lets get it under control: 1G of memory to display a med-large image is a joke !

Re:Python for Scientific use

[Anonymous Coward]

"5/2=2" is not an "issue". That's exactly the output you should expect for integer division, which is what 5/2 is asking for.

Re:Python for Scientific use

[WeatherGod]

What result do you expect from 5/2? I expect 2... 5/2 == 2 in C, C++ and FORTRAN (I think... I don't write much FORTRAN code these days...)

Just watch out in python 3.0, this will change. Because of python's duck-typing, you can never be certain if you were getting an integer or a float, and so it is possible to get different behaviors implicitly. Because python's mantra is "Explicit is better than Implicit", python 3.0 will only do integer (called floored) division when you do '//'.

Re:Python for Scientific use

[mangu]

I don't want to load 20 modules before I can begin coding.

That's why I don't like Matlab. Not only you have to import every single function you use, but each function comes in a separate file. And when you find the function you need on the web, you have to shell out an extra $5k to get the libraries it depends on.

My only worry about Python is that version 3 abomination. They not only managed to make each change towards a more complicated way to use, but also deprecated such a basic thing as string formatting. About one third of the code I write is related to text I/O, so a quick and easy way to format strings is very near the top priority on any language.

Last time I checked there are ten times as many references to the C language on Google as references to Python, so I cannot imagine why they want to get rid of the C-compatible string formatting. They created something that, in every single example I have seen, takes at least twice as much effort to write, offering no significant advantage.

If somebody needs a more sophisticated method for formatting strings, go ahead and create a new formatting library. But leave the true and tested way that has been working for nearly forty years alone. You cannot deprecate a basic functionality of a language just like that without dire consequences.

Re:Python for Scientific use

[highacnumber]

Exactly. Sage, for instance, pretty much does that and adds in a lot of other mathematical and statistical programs through various interfaces (http:www.sagemath.org).

Re:Python for Scientific use

[Discrete_infinity]

Yes, I saw that and had similar thoughts. Also they should look at virtual environment and look at Interactive python

Re:Python for Scientific use

[smaddox]

Or modelica. I haven't used it, but it looks interesting.

Re:Python for Scientific use

[smaddox]

What kind of a scientist doesn't include at least 2 significant digits?

>>> 5.0/2.0
2.5

Problem solved

Re:Python for Scientific use

[BusterB]

When did they get rid of C-style string formatting? That's news to me.

bcook@bcook-box:~$ python3
Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "%d %s" % (1, "Hello")
'1 Hello'

Re:Python for Scientific use

[Anonymous Coward]

Old-style string formatting was not deprecated. There are no plans to remove it at any point. And it isn't C-compatible.

Re:Python for Scientific use

[ceoyoyo]

It doesn't matter I'd you grasp basic code design or not, Matlab et al simply don't support that sort I thing, or have support poorly grafted on afterward because they were never designed for real coding. I say this as a scientist who uses everything from assembler to Python and has had the unenviable task of figuring out what someone else's thousand line long matlab programs were doing.

Re:Python for Scientific use

[elashish14]

For math:

from __future__ import division

Re:Python for Scientific use

[pclminion]

That's exactly the output you should expect for integer division, which is what 5/2 is asking for.

On what planet? Just because C works that way, and Python works that way (at least until now), doesn't mean it's the best way, or the most useful way, or that it could never be changed.

That's EXACTLY the point being made here -- people are touting Python as a scientific computing platform, but the result "5/2 == 2" is almost never what you want when doing scientific calculations. So from the standpoint of scientific coding, some features are really not ideal.

Re:Python for Scientific use

[Adys]

They aren't getting rid of C-style string formatting. They are adding a format method to strings, which uses a different syntax. The current modulo override (str % format) is staying, and they haven't decided whether they will one day get rid of it.

Re:Python for Scientific use

[photonic]

I disagree very strongly with Octave being a better alternative. Octave is just an open source matlab clone, so if all you want is to run your old scripts with only minor modifications and without paying anyone, octave might be the way to go. Other than that, plotting in Octave sucks pretty hard, you basically have to learn Gnuplot from scratch. Even matlab itself is not a star in plotting, after 15+ years you still have to be a guru to get publication-style plots, but it is already miles better than octave. Python+Numpy+Scipy+Matplotlib, however, does not try to be a clone, but it tries to become something better than Matlab. As a start, Python is a real OO programming language by itself with an enormous toolbox that is ready to do everything from easy string manipulation to whole web-frameworks in a very elegant way. Matlab was built for doing linear algebra and using it to do any real programming just feels awkward, I guess octave is similar in that sense. The matrix stuff was bolted onto python later with Numpy, so it is missing a tiny bit of specialized syntax found in matlab/octave, but other than that you can do exactly the same in both languages. Numpy even has some cool stuff like singleton expansion by default, which is not found in matlab. The big advantage Matlab still has over python is in the toolboxes, but this will change in the next few years as Scipy matures. The plotting done with Matplotlib, finally, works very well and is already better than matlab on some points, like making anti-aliased plots without any effort.

Re:Python for Scientific use

[RichardJenkins]

Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 5/2 #Diving integers in Python 2.6 gives an integer
2
>>> from __future__ import division
>>> 5/2 #Things work differently in the future
2.5
>>> 5//2 #You can use a double '/' to explicitly force an integer in Python 3
2

Re:Python for Scientific use

[Anonymous Coward]

If you take 5/2 in scientific programming and expect anything but 2 (or *possibly* 3)--your education has a bug.

5/2 = 2.

It is the best way because C works that way--because that's how *TYPE THEORY* works, and good old Mr. Thompson actually thought that out--along with its implications when implemented on an imperfect non-idealized computer that actually has storage constraints. Converting an integer to a real arbitrarily gains precision, which is a big no-no if you actually did scientific programming. I'm gonna wager you just don't understand mathematics with a statement like yours.

It isn't a question of integer vs. floating point--it's a question of signifigant figures. The only question is whether you take that 2.5 your system computed and round up to 3 (= 3.0000...) or not. There's pretty good arguments for doing it randomly at that value due to rounding issues...

But you know--don't let your lack of background or abundance of preconceived opinions stop you from spewing BS like that all over the net.

If you wanted to get really technical, 5.0 / 2 should still be 2--which would be a fault of python.

Re:Python for Scientific use

[martin-boundary]

Well, no. Mathematically speaking, 5/2 = 2 makes no sense. What makes sense is 5/2 = 2 with remainder 1. That's what Euclid's algorithm gives us.

The correct approach should be to represent the output of 5/2 as a pair of integers, but my guess is that for some reason the early language designers felt that an operation taking one interger into a pair of integers wasn't elegant or too much trouble to get right, and so we ended up with the ugliness that is / and its little used cousin %.

Re:Python for Scientific use

[daver00]

In my experience, while Matlab is a great way to get started, the code you produce in Matlab tends to be difficult to port across nicely, even to Python, because Matlab just does stuff in such a unique and honestly, bizarre way. I agree, Matlab doesn't really do anything well in my opinion, hell I am a TA for first year Matlab classes at my uni and I hate every minute of it.

Re:Python for Scientific use

[daver00]

Why? Simulink sucks, what on earth would prevent you from doing that stuff in raw Python, or a good micro language? Do you think control systems really need a $10k package to operate? Simulink is great for prototyping, and for engineers who can't program, thats about it I reckon.

Re:Python for Scientific use

[pclminion]

What the hell are you rambling about? Long numerical calculations do not involve intermediate rounding except in very specific circumstances. Data always have some amount of noise to them -- rounding at inappropriate moments AMPLIFIES the noise. The direction to which a value rounds depends which side of 0.5 the fractional part falls on. If the exact value (which we cannot know precisely) is very close to 0.5 in the fractional part, then whether the value rounds up or rounds down may depend entirely on the noise.

Re:Python for Scientific use

[2.7182]

Actually, I think Matlab survives a lot based on urban legend and another strange thing - it is easy to make plots. Like Maple and mathematica, the simple environment is really what keeps it going. Try writing some basic linear algebra operations in C++ with some not too fancy methods and you will find Matlab is no faster, or even slower. If you are already functional in C or Python or whatever, steer clear of Matlab. Unless perhaps there is some reason you want to use it to design hardware controllers. In that sense it is pretty cool.

Re:Python for Scientific use

[Anonymous Coward]

Which is why you should expect 2 or 3, not 2.5.

Floating point ROUNDS BY DEFINITION. It is an incomplete, imprecise format--incapable of representing a number a simple as "1/3". And it's a damned useful one if you understand its limits.

If you don't want rounding you should use an appropriate (and usually slow) numeric type if you don't want rounding to occur merely by virtue of representing the number in finite, IEEE754 specific memory chunks.

If you want the remainder--you should do integer division, and then fetch the modulo. Whether you go up or down may depend wholly upon the noise--but you don't propagate that through your arithmetic. If your measurement is accurate to only a hundredths, that's what you do your math out to--anything else implies false precision in the result. What the hell good is math accurate out to 10 places when I only have an 8 bit A2D on an input in the process loop?

Saying 5/2 yields anything but an integer is an error of introducing additional precision into the computation. If you want to represent an extra decimal digit because that's how your place does it...fine--but 2.5 isn't a floating point quantity--that is to say, a value midway between 2 and 3, with one signifigant digit--is not a floating point quanity.

2.5000000000000000 is. e.g. 0x4004000000000000

Congratulations, your arithmetic now has 15 more sigfigs than what happened when you used a pencil.

You don't round fractions, functions, transcendentals...whatever...when you do it on paper. You toss that into a programming language in a billion iteration loop thinking you're working with "reals" and you're in for a WORLD of rounding error, unless you're in a happy application with a decent random distribution on the roundoff tails.

Don't confuse programming with math. Computer science is math. Programming is a hack on top of it to get it working.

"Mathematically speaking, 5/2 = 2" makes no sense only because of your definition of the symbol. I guarantee you, the compiler and interpreter have defined it differently such that it does make sense.

Re:Python for Scientific use

[mangu]

The original plan was to completely eliminate the '%' string formatting operator by version 3.2

I don't know if they are still committed to this, since, as I mentioned, this is one of the stupidest decisions one can imagine. But they still mention in the str.format method documentation that "This method of string formatting is the new standard in Python 3.0, and should be preferred to the % formatting described in String Formatting Operations in new code."

In the PEP-3101 documentation the abstract says: "This PEP proposes a new system for built-in string formatting operations, intended as a replacement for the existing '%' string formatting operator"

In the official Python 3 specification it's mentioned that "A new system for built-in string formatting operations replaces the % string formatting operator. (However, the % operator is still supported; it will be deprecated in Python 3.1 and removed from the language at some later time.)"

So, there is a very well defined intention to eliminate the '%' string formatting operator, although I believe they will find it harder to implement than they thought at first.

If they go ahead and implement every stupid proposal that has been made for Python 3, I think the best solution would be to fork Python. Name it the "Python 2.7" version, one that will never reach version 3. My proposal is to do like Donald Knuth did for TeX versions, which approach the value of pi. Let's have Python 2.7, 2.7.1, ... 2.7.1.8.2.8.1.8.2.8.4.5.9.0.4.5, etc.

Re:Python for Scientific use

[buchner.johannes]

Has anyone actually worked with Sage? How is it? How / when did you find it superior? Pros/cons?

Re:Python for Scientific use

[Capsaicin]

Why are you anthropomorphizing?

Because it's a narrative device that can be used effectively to communicate. You didn't have any trouble understanding that "python" in that context stood for the python development community, did you? You didn't seriously think he was ascribing a human like intelligence to a language specification, did you? That anthropomorphism avoids clutter and actually increases readability, and after all, readability counts. :P

That being said, I have to agree with you. Part of the strength of python surely is its general applicability so effectively fostered by the SIGs. I'm not even sure what OP means by "hard core" programming. That's what C is for, no?

As far as switching over to float divisions by default, I thought that was meant to cut down on newbie bug reports ;) IOW, it's a little annoying to oldtimers (and the folks who regard integer division are the more natural) but probably obeys the principle of least surprise for most naive programmers out there.

Re:Python for Scientific use

[pclminion]

2.5000000000000000 is. e.g. 0x4004000000000000 Congratulations, your arithmetic now has 15 more sigfigs than what happened when you used a pencil.

What the hell are you talking about? Just because the value in the register, if written out, is 2.5000000000000000, doesn't mean that anybody believes that the value is exact.

What the hell good is math accurate out to 10 places when I only have an 8 bit A2D on an input in the process loop?

Because I don't want to accumulate roundoff noise in each fucking calculation? Nobody is disputing the importance of significant figures. But intermediate rounding is just throwing noise into the mix for no good damn reason.

Re:Python for Scientific use

[MechaStreisand]

Yes they are. Skip down to the section Changes Already Present In Python 2.6. String formatting is deprecated in favor of their new horrible way. They're going to try to get rid of the old, good way. I won't switch to 3.0 unless they give up on that, but so far they haven't.

Re:Python for Scientific use

[brunos]

Hi, I see your point: Python is getting a lot better for scientific use, maybe not so much due to the changes in 3.0 but rather because the community has grown (e.g. Python(x,y), Enthought). There are a few things that make Python what I use most of the time for scientific work: - The language is better thought out i.e. the Matlab tradition of having one function per file is just annoying. - The quality of the old Fortran algorithms which scipy wraps is consistently better than that of Matlab functions e.g. Matlab fitting routines are a mess, I get much more accurate results with scipy. - Compatibility between versions: matlab code from my colleagues always needs some work to run: either because there have been some changes between matlab versions, or they use a function from a toolbox that I don't have, even though there is an equivalent one in standard matlab. Since we changed to Python all is fine. - When you cannot vectorize a small piece of code, scipy offers a few ways in which compiled code can be added transparently: cython, pyrex, f2py and even pycuda. Much easier than .mex in matlab. - Python has a large set of very useful libraries for doing scientific work e.g. networkx, vpython ... - Thanks to Python's large set of other libraries, it is trivial to do things such as parsing complex files, interfacing with lab equipment (pyvisa, ...) interfacing with the windows/linux/mac GUIs, using databases, sending data over the network etc. All these things are really handy in the lab. - I don't mind paying for software, but the license management is really a problem: It has happened quite a few times, that Matlab has stopped working because something in the license management had changed. Loosing a day of work of a research group is expensive. - Of course, the fact that students can just install Python for free, and maybe use it in their future non-scientific job is a plus.

Re:Python for Scientific use

[Anonymous Coward]

I deal with people who "code" in those environments all the time, and they are not my peers:

don't be such a language snob. I'm sure many of them are much smarter and better scientists than you are, even if they aren't the uber programmer you are.

For example I'm mainly a C programmer, but from time to time I use Matlab for various tasks that are better done in Matlab. Does that make me a bad C programmer or not understand good design? Of course not. Are there bad or beginner C programmers? Of course there are.

Let folks use the best tool for the job (for them!) and drop the superiority complex, it will hurt your career and personal relationships in both the short and long terms.

Re:Python for Scientific use

[Anonymous Coward]

The Matlab IDE is also very useful and the Python+Numpy+Scipy combo should really come with a similar outfit. The ease of starting up Matlab and immediatly starting to program is very appealing. Nonetheless, the language has quirks and matlab plotting with handles is awkward. I'd love for Python to adopt the cleaner Matlab matrix syntax but it's not going to happen.

Re:Python for Scientific use

[totalli]

Scicos might be what you are looking for

Re:Python for Scientific use

[maxume]

I asked the anthropomorphism question because it seemed like maybe he was taking the device a little too literally, treating the community as a monolithic block. It was a device of my own.

Re:Python for Scientific use

[jipn4]

I don't want to load 20 modules before I can begin coding. I just want to input my algorithm and get a result I expect

In the real world of scientific programming, that's often not enough. A lot of scientific software needs to collect data from instruments, parse, format, deal with databases, perform visualizations, present user interfaces to lab assistants, interface with foreign libraries, etc. It needs to be unit tested, regression tested, maintained, reused, refactored, etc. Scientific libraries often become big and complex with hundreds of modules and tons of name conflicts.

A language that just loads everything into a global environment and lets you code some matrix multiplications is fine for classroom use, and it's also fine for graduate students who come up with an algorithm, publish a paper, and move on. But that's not good enough for a lot of real-world scientific applications. Another big problem with MATLAB is its licensing and pricing (Octave and Freemat don't address that issue because they aren't fully MATLAB compatible, meaning many libraries just don't run in them).

As a VHLL, Python strikes a good balance between software engineering support and support for scientific programming. And its libraries have long surpassed MATLAB's, except for some specific domains. One could probably design an even better language for serious scientific programming than Python, but until someone does, people are likely going to stick with Python.

If MATLAB works for you, fine, stick with it. But don't presume based on your very limited needs to talk about what "scientific programming" is all about.

Re:Python for Scientific use

[Anonymous Coward]

It really doesn't matter much. For a dynamically typed language, either choice is OK and proven.

Probably, most casual users (including MATLAB users) prefer a float result from 5/2, and experienced users don't care that much. Using explicit "//" where you do want integer division means better type checking, among other things.

Python is general purpose

[Kludge]

Python's dynamic object orientation allows it to be used for a wide range of rapid development in many fields.
I use it for scientific programming. While it does not have as many libraries as matlab or R, it is great because I can call R routines from python plus does things like threading and complex file manipulation, that the others do poorly.

Python is not bad numerically, you just have to be clear about what objects you are using when. If you don't want 5/2=2, then use 5./2.

Easy?

[Anonymous Coward]

Matplotlib is bar far the most difficult plotting package I have ever seen. You need to manually adjust every small detail of your plots including axes, tick marks, legends and even spacing for the various components in your plot. It's even worse than MATLAB. The API is difficult and documentation poor. The only sane reason to use Matplotlib is if you have a web application written in Python and need a plotting package that can handle numpy data structures.

$45???

[Anonymous Coward]

No thanks. I have a better idea:

http://www.google.com/search?q=matplotlib

What about APL?

[NicknamesAreStupid]

http://www.sigapl.org/whyapl.htm

To all you C++ flamers...

[serviscope_minor]

Python threads seem to bring the C++ flamers out of the woodwork. Just so you know, Matplotlib is written in C++. I happen to like both languages.

Re:To all you C++ flamers...

[Anonymous Coward]

I spend roughly half of my programming time writing C++ and half writing python (mostly doing performance analyses on the grid-based C++ stuff). They are both great, provide appropriate tools for the job at hand and are entirely complementary.

I spend a fair amount of my time using matplotlib for data visualisation and I will be buying this book immediately, mostly because the docs are a bit crap and I feel there is a lot of convenience and power there that I haven't yet got my head round . The MATLAB vs matplotlib debate that seems to be going on in the other posts is irrelevant to me. I use matplotlib to generate visualisations of data I gather in a heavily distributed computing environment. Science/maths has nothing to do with it and I would never consider using MATLAB, not least because I can't see any earthly reason my company would want to pay for it.

Re:To all you C++ flamers...

[Anonymous Coward]

Who is flaming C++ here? You are bringing up some imaginary adversaries which you then start to debate, like you are talking with the voices in your head. If you have some real comments to make, post a comment to someone else's post, and do not start a new thread.

Try Veusz for an easier life

[xiox]

If you find matplotlib hard, try my Veusz python plotting package. It has a GUI you can build plots within. It is scriptable in python, and even the saved file format is a python script to generate the plot. It can read a variety of data formats.

Re:Try Veusz for an easier life

[Anonymous Coward]

mod parent up

Alternative to matplotlib

[Anonymous Coward]

At one point I was trying to decide which graphics plotting library I wanted to get proficient with. I considered mathplotlib but I eventually decided on R + ggplot and am very satisfied. Some examples here. True, I was doing mainly statistical stuff so the R connection wasn't a liability. But I like the philosophy of ggplot: the "gg" stands for "grammar of graphics". The library doesn't demand that you adjust every little thing separately to make interesting graphs; it gives you a variety of concepts (in ggplot parlance, geoms, layers, statistics, scales, etc.) and lets you combine them in arbitrary ways. It takes some getting used to but you end up being able to make great graphs without much twiddling with the details.

Python..meh

[Anonymous Coward]

No word yet if the chapters are indented properly.

This book claims publication quality plots...

[yerM)M]

It's too bad they didn't use any in the book.

I have used matplotlib for journal plots and actually gave away a copy at a conference I ran so I have to say I really do like the book overall, but if you scan through the pages, you might be turned off.

In Defense of Matlab

[tobiah]

Python has it's strengths, but there are good reasons Matlab is so widely used:

Price: There is a price to everything, Matlab's is up-front and what you get is guaranteed support and development. If there is a bug or serious shortcoming you know someone is working on it like their job depends on it.
Graphics: Matlab has the most feature-rich and usable graphical environment of any of its would-be competitors, none of which do 3D well.
Speed: Core Matlab operations are highly optimized in C; properly vectorized Matlab code will run much faster than what most programmers could write in C themselves.
Interoperability: Java and .Net calls can be made from the Matlab command line, integrating compiled C is well-supported and very straightforward. Python can do these things, but it's not automatic or well-documented.
Documentation: it's there, and it's good.
Dev Environment: the debugging tools, profiler, and lint integration are really helpful.

Re:In Defense of Matlab

[daver00]

Speed: Core Matlab operations are highly optimized in C; properly vectorized Matlab code will run much faster than what most programmers could write in C themselves.

I'm not disagreeing with you per se, as I'm not extremely experienced in Matlab, but my empirical observations (working on my own code here) have shown that this isnt really true. I have recently written identical pieces of code in Matlab and Python/Numpy, with the same level of vectorisation I spose, and found Numpy to be significantly faster at times, not always, but often enough for me to think this stuff about Matlab being fast is just bunk.

I know how much faster my Python code would be if I used weave or just straight C, so if the raw Python can compete with Matlab, then how on earth can Matlab compete with C? Again, YMMV, but I really have my doubts about the 'speed' of Matlab.

Re:In Defense of Matlab

[Anonymous Coward]

but matlab has a lot of undocumented bugs.
everyone i know in computational/quantitative science has had to re-implement or work-around built-in matlab commands because of undocumented bugs (for instance functions not always having their documented behavior, or even just graphics libraries running out of memory).
not to say that python is bug free somehow, but:
-as a python user i didn't have to pay money for the bugs
-as a python user i can examine the source code of every line of every function if i need to track down a bug.

the reason why matlab is so widely used is the same as the reason why FORTAN is widely used: there was an era when it truly was the best tool available. then a lot of people who had done parts of their thesis work in matlab became PIs and encouraged their students and post-docs to learn MATLAB. MATLAB is taught in lots of university courses aimed at young/future scientists. not because it's better, but because it's the only thing that the instructors know how to use.

Re:In Defense of Matlab

[Anonymous Coward]

> If there is a bug or serious shortcoming you know someone is working on it like their job depends on it.

Hahahaha. I've reported bugs that have been open for *years* with zero development effort assigned to them.

Re:In Defense of Matlab

[alexibu]

I own a copy of Matlab, but am moving more and more stuff out of it.
It integrates with command line very poorly (on windows).
The java interface parts look like shit.
The language sucks for real development work.
They want to pay them a fee to retain the future ability to purchase toolboxes, even though I don't want support.
The only thing I am still using is the griddata function because it is better than octaves.
Most of my work is now in python with gnuplot.

Re:In Defense of Matlab

[Billly Gates]

This begs to differ if python is really interpreted anymore? Java and .NETs CLR use bytecode and JIT so the speed differences are not that big or at all unless you continuously load and unload large amounts of code. If its only a 10% difference then upgrading your cpu can bring the same effect. I wonder how fast python is and what kind of compiler or interpreter it is as well.

Re:In Defense of Matlab

[tobiah]

It's not Matlab competing with raw Python in your example, but with the compiled C and Fortran of NumPy. They're going to be about the same speed. Matlab and Python are both interpretive languages, so pretty slow. However, the slowest most intensive parts have been compiled to get the "best" of both worlds, ease of use and speed.

Re:In Defense of Matlab

[tobiah]

the reason why matlab is so widely used is the same as the reason why FORTAN is widely used: there was an era when it truly was the best tool available... but because it's the only thing that the instructors know how to use.

Ya, momentum is definitely part of why Matlab is popular, but you ignore all of the other reasons I list, which are significant. Those are features you just can't get in a single package elsewhere.

I don't expect Matlab to be king forever, it is showing its age and there are many contenders for the crown. Perhaps Python+ will be the succesor. But it's going to take more than momentum to get there, the community will need to address the feature gap, and offer clearer advantages than "free".

Re:In Defense of Matlab

[tobiah]

Gnuplot is solid, I'm surprised I don't hear of it with Python. How do you connect them? My impression was there isn't a good link available.

Re:In Defense of Matlab

[brantondaveperson]

Not to mention using it with simulink, which is pretty impressive.
Also the differential equation solvers are pretty smart, if you need them.
Plus we use it with the symbolic math toolbox, which is very powerful and as far as I know there is no free replacement for it. Not that I would expect there to be, symbolic math is pretty hard to program I should think. The last free one I tried didn't even know that cos^2+sin^2 == 1

Re:In Defense of Matlab

[Xyrus]

Price:

That's a positive? You can't even get a price unless you create an account with them and "login". Unless whoever you're doing the research for provides you with the budget or has it someplace you can get to it (and has bought the seats so you aren't fighting everyone for your chance to use it) you're going to be shelling out some cash.

As far as working on bugs or shortcomings, your not guaranteed anything. Like any other product your bug/feature/whatever goes into a priority queue. If you're a lowly grad student you're going to be taking a back seat to their bigger customers. If it's a critical bug, then they'll probably fix it. Anything else though is up to them.

MatPlotLib is free. It's open source. If there is a bug, you can either report it or fix yourself. You're not tied down to a vendor. If you don't like something you can change it or fork it. If you want to fix a shortcoming you don't have to wait.

MATLAB is a good tool, but price is not an advantage I would tout.

Graphics: Matlab has the most feature-rich and usable graphical environment of any of its would-be competitors, none of which do 3D well.

Oh good $DIETY no it doesn't, at least not on all platforms. Perhaps the versions I've seen are old, but the thing was an enormous resource hog that was slow to render and would practically bring a dual-core notebook to it's knees. WorldWind and IDV rendered faster than MATLAB, and it was doing far more and they are written in Java.

Speed: Core Matlab operations are highly optimized in C; properly vectorized Matlab code will run much faster than what most programmers could write in C themselves.

The same can be said about any native highly optimized math library. Granted their API and language make it easy to use, but fast math operations are not unique MATLAB.

Interoperability:

I've never used MATLAB's interoperability features so can't comment on them. The big sticking point with python's interoperability is when it comes to passing objects around. Simple types are easy enough but complex objects can make things obtuse. Does MATLAB have some sort of object translation layer? If so, that is a definite plus. If you mean only calling methods with basic types, well then there really isn't much of a win there.

Documentation:

In my experience I've found commercial documentation is usually better than open source documentation. There are exceptions to this, but this is a fair point in this case. Then again, MatPlotLib is fairly "new". But point taken.

Dev Environment: the debugging tools, profiler, and lint integration are really helpful.

Eclipse+PyDev. Or if your old school you can use the command line tools for debugging and profiling. Point being, Python has a lot a lot a lot a lot a lot A LOT a lot of tools and is almost fanatically embraced by the open source community. It's cross platform and has thousands of libraries. MatPlotLib, Scipy, Numpy, and the others are just extensions to a powerful multi-purpose language. If you also apply blitz and the numerical C libs, then python ranks right up there when it comes to computation.

Point being, people can now get MATLAB like functionality without paying out the nose.

Don't get me wrong, I think MATLAB still has advantages and in some cases significant ones (especially if you're looking for specific tool-sets). But the ones you mentioned aren't the best ones to use.

Re:In Defense of Matlab

[Anonymous Coward]

For me, gnuplot is the best plotting program out there. It's very easy to use from python using Gnuplot.py (http://gnuplot-py.sourceforge.net). It essentially starts a gnuplot session that sends it commands through a pipe. You can choose if data is sent through a FIFO or temporary files (slower, but required for some of the interactive plotting features).

In a nutshell:

import Gnuplot as gp
g=gp.Gnuplot()
g.plot("sin(x)")

Conversion of most sensible python data types is done on the fly:
g.plot( [(x,x**2) for x in range(-5,5)] )

Plus, g.interact() will just drop you into the currently running gnuplot session, which can be very convenient.

Re:In Defense of Matlab

[insignificant1]

Look into the libraries that Sage Math uses for near-Mathematica symbolic manipulation. Or just use Sage (which is built on top of Python).

Simulink I haven't found a great replacement for within Python, but graphical programming is often more of an impediment than a help for me. For layout of one-off control systems, it was nice, but I've just gotten too efficient with text editing (and I'm to the point that I can visualize what's going on) to want to worry about connecting wires, double-clicking, changing properties, etc. (To wit, last time I used Simulink, I auto-generated all of the block diagrams and set all block properties with an m-file script.)

Re:In Defense of Matlab

[insignificant1]

Check your comparison facts:

1) Near-compiled speed with a scripting front-end? Try NumPy out, it works the SAME WAY as Matlab (vectorize your code and it runs at near-compiled speed). There isn't any secret to how Matlab does things, it's just what they've put together into one package and the loyal userbase that keeps them going.

2) UI's: iPython or Spyder are user interfaces achieving similar goals to that of Matlab (I prefer the former as I'm a command-line junkie, but the latter will make you believe you're in Matlab: lint and debugger are integrated).

3) Bugs: maybe somebody codes like their job depended on it, but the bugs I've seen got fixed with their 6-month release cycle. That didn't help me a damn bit.

4) Price "up-front": hahahaha, you're joking, right? So if you want your bugs fixed, like I said, most get fixed in their semi-yearly releases, but you only get THOSE if you have an active (a recurring cost) support contract. And then you find that one of your toolboxes or another sw requires the Matlab version that still has the bug in it. Now you're SOL. Commercial software ain't all roses, especially if you aren't a fortune 100 company or a big research institution. I update my Python, NumPy, SciPy, and Matplotlib whenever they have a release OR bugfix/patch, for free, now until doomsday.

Re:In Defense of Matlab

[insignificant1]

Check out Enthought's Python package, it includes amazing 3D visualization (on par with Matlab or superior, I think), the IDE you like from Matlab, good support, good documentation, etc. I don't think that Matlab has much advantage except for certain application-specific software that has just happened to be designed to interoperate with Matlab.

The Enthought pricing page: http://www.enthought.com/products/epd_sublevels.php
(But note that you can get most of the functionality of the software for free, just you mentioned paying for support as an advantage of Matlab.)

Re:In Defense of Matlab

[Vesvvi]

Graphics: Matlab has the most feature-rich and usable graphical environment of any of its would-be competitors, none of which do 3D well.

I'm interpreting that to say that Matlab does a better job at 3D than the competitors, which is exactly the opposite of my experiences.

I work 100% in Python/Scipy/etc, and my brother does 100% Matlab. He had to come to me for suggestions when Matlab failed to handle visualization of his extremely large 3D datasets (I can't comment on whether he really had exhausted Matlab's functionality for that purpose). Although it's true that Matplotlib has pretty poor 3D support, Python gives you many more avenues: Blender+Python actually gave incredibly good performance for an interactive data environment, although it certainly wasn't designed for it. And VTK will give you anything you want, if you're prepared to put in the time.

Re:In Defense of Matlab

[insignificant1]

Wait, wait, wait. Are you saying "Yes, NumPy and Matlab work the same way, so no advantage to Matlab," or are you saying "the comparison isn't fair because compiled-C/Fortran routines being called by Numpy are being compared to compiled-C/Fortran routines being called by Matlab?"

If you're saying the latter, you need to know that the two software packages pretty much work the same way, you write a quick script and the array (vector) data is passed into a compiled routine to munch on and only when the routine is done operating over all of the data does the result get passed back up to the script (hence both use the "vectorized" coding style). In this sense, Matlab and NumPy are THE SAME.

And lest you be confused, Matlab used Atlas-compiled BLAS routines as of a few releases ago, and as of late they were using the Intel-compiled Netlib-like routines (BLAS, LAPACK, LINPACK, etc.). There is no Mathworks special sauce that makes these fast. Mathworks just passes data down to these routines like NumPy does.

Oh, and I think you meant to say "interpreted," not "interpretive."

Re:In Defense of Matlab

[Anonymous Coward]

For 3D, Mayavi is way more powerful than anything Matlab has. Of course, if you are only interested in very simple stuff, it's going to be simpler in Matlab, but if you want to visualize real complex data...

Re:In Defense of Matlab

[Anonymous Coward]

You can only get it for free for 30 days, the license does not mention usage after 30 days with no support package.

Re:In Defense of Matlab

[daver00]

In this sense, Matlab and NumPy are THE SAME.

Not the same, but very similar. As far as I'm aware Matlab uses a Fortran backend, while Numpy uses C. Now thats kind of picking at straws, but my point is honestly I don't think Matlab is faster than Python.

Either way I guess it depends on your toolbox in Matlab, or library in Python. Given both I'd choose Python every day of the week.

Re:In Defense of Matlab

[Vireo]

Speed in interpreted languages such as Python and Matlab depends strongly on what it is doing exactly, and how it is done. For example, both Matlab and the numpy Python module use external, pre-compiled, and highly optimized basic linear algebra subroutines (BLAS) for things like matrix multiplication. Matlab ships with several different BLAS, but it's even possible for Matlab to use the ATLAS BLAS which numpy uses.

So the speed would be the same in that case, assuming both your Matlab installation and numpy are configured to use the same number of processors (linear algebra is typically highly parallel, and in huge matrix operations, multi-thread overhead will be negligible).

If you code your own matrix multiplication naively in C, you may end up with a factor of 6 or 7 in speed *below* that of Matlab.

However if we're talking about generic loops for example, C is then much, much faster. Matlab has a Just-in-Time (JIT) optimizer which vectorizes straightforward loops; the same for Python is not ready yet (this would be the Unladen Swallow project from Google I think). Depending on the precise morphology of a loop, very different speeds would be obtained in Matlab, C or Python. The lesson here is to use numpy or scipy precompiled and pre-optimized code whenever this is possible. But when it's done right, there's generally much less difference between Matlab, Python and optimized C than many people think.

Re:In Defense of Matlab

[Vireo]

A few quick comments on this well-informed post...

Price: you're right here, Matlab is expensive and is locking you down, but at least you get very decent support from The MathWorks.

Graphics: Matlab has a huge library of very usable graphics functions. However it is nonetheless lacking in certain areas. GUIs is one of them (you can only embed Matlab graphics in a Matlab GUI, and the various methods to build a GUI in Matlab mostly sucks compared to what is possible outside of Matlab). Also, while Matlab figures exported to other format (PDF, EPS, bitmaps) are fine, on-screen Matlab figures are not anti-aliased and sometimes present quirks that are not really there. Matplotlib uses the Antigrain library for screen output, so the end result is much more pleasing to the eye.

Speed: Using numpy, you benefit from the binary linear algebra subroutine (BLAS) speed, much as Matlab. Generic loops tends to be slower than Matlab because of Matlab's Just-in-Time (JIT) optimizer.

Documentation: I'll give you this one hands-down: Matlab has *excellent* documentation, written by experts in the field. This is an often neglected area, but clean and profuse documentation and examples allows you to do more things, much quicker.

Dev environment: very good in Matlab, but using any Python syntax-aware text editor + the IPython shell, I don't miss much when developing Python. Python is generally more consistent (e.g. you can define a multi-statement function interactively in the Python shell), which speeds up development. Also, Matlab is beginning to feel a namespace crunch. All functions in all toolboxes are in the same namespace in Matlab, and it's beginning hard to find creative new names for my own function, all the most if they replicate some Matlab's built-in capability. Python's namespace / module imports solves this problem very nicely.

Re:In Defense of Matlab

[BuildMonkey]

You missed a big one:
Toolboxes: The set of toolboxes available for MATLAB is rich, capable, and documented. Yes, if I hack enough things together there are packages available for other languages that can do some of what MATLAB toolboxes can do. But at the end of the day, when I need to design filter coefficients, find a stabilizing gain, etc. I turn to MATLAB because it's there, I don't have to hunt for the packages, the results are repeatable on a different machine with a different version of MATLAB, and my time is worth something to my employer.

Re:In Defense of Matlab

[insignificant1]

Like I said, most of the software is available completely free, just not directly from Enthought; they are responsible for much of SciPy, which is 100% FOSS. MayaVi 1.x is completely free. NumPy is completely free. Documentation for these is completely free.

The Enthought package that they put together, which includes MayaVi 2.x, is not free. But the parent poster wanted paid-for support, so I recommended the Enthought package. For another good free bundled package, check out python(x,y).

Re:In Defense of Matlab

[tobiah]

Graphics: Matlab has a huge library of very usable graphics functions. However it is nonetheless lacking in certain areas. GUIs is one of them (you can only embed Matlab graphics in a Matlab GUI, and the various methods to build a GUI in Matlab mostly sucks compared to what is possible outside of Matlab).

It took me a long time to figure out Matlab graphics. Their "guide" function is nice for mocking up GUIs, but is not anything you want to use for making them. Handle graphics should be used the way they were originally designed; as OO objects managed by set and get. Since then I haven't found anything I want to do with Matlab graphics that I can't. It is total control.

Dev environment: All functions in all toolboxes are in the same namespace in Matlab, and it's beginning hard to find creative new names for my own function, all the most if they replicate some Matlab's built-in capability. Python's namespace / module imports solves this problem very nicely.

Yup, been an issue for awhile. However the 2008 class-definition and package-definition components go a long way to address it. They're moving towards becoming a primarily object-oriented language. Of course Python is already there, but Matlab has recognized the weakness and is moving forcefully to correct it. And sometimes there is an advantage is showing up late, means you can learn from someone else's mistakes. Although here I mostly see learning from what was successful.

Nice Post

[codeAlDente]

I might ditch Matlab completely, especially given what I've read here, because I hate its license manager, it's expensive, and its performance on Macs is pretty sorry. Expenses can grow fast if you try to collaborate and nobody uses the same toolboxes. However, its syntax is intuitive to the mathematically inclined, it handles large arrays efficiently (!), and its GUI is really nice. I prefer Igor Pro for scientific graphing, but its syntax is a little more complex, it's limited to 4D arrays, and it's compiled. As long as someone else is buying, I'm glad to include Matlab in my work, but if I'm strapped for cash I might go with an octave/python/xmgrace combo.

Care about roundoff? You better know types.

[Vesvvi]

Isn't it fair to say that if you're worried about roundoff noise in repeated calculations, you've passed the point from being just a scientist to a someone who should be concerned with general programming theory and conventions, and hence at least familiar and comfortable with notation that denotes type?

My introduction to IEEE 754 was brought about via Python, when my chemistry kinetic simulations weren't running right (many millions of iterations, scaling factors with huge and tiny exponents). Understanding and fixing that problem took an hour or two, which far overshadowed the minute-long pause when I first found that 5/2 = 2.

In the end, the benefits of having the power of a real programming environment far outstrip the very small entry barrier. I personally feel that in the modern world you have no business calling yourself a scientist of any kind unless you can write a basic data manipulation script (parse and write a flatfile csv/tabs/CRLF etc) in some language of your choice. Massive quantities of data and meta-analyses are now the norm, making manual transcription or even copy/paste a thing of the past, and it is not acceptable to be hobbled by the feature set of existing software.

Re:Care about roundoff? You better know types.

[pclminion]

Isn't it fair to say that if you're worried about roundoff noise in repeated calculations, you've passed the point from being just a scientist to a someone who should be concerned with general programming theory and conventions, and hence at least familiar and comfortable with notation that denotes type?

I understand types. The question here is which type the literal value "5" or "2" ought to be. Right now, these literals are interpreted as integers. A lot of people would prefer the default to be some real type. I'm talking about the syntax of the language, not suggesting that integer arithmetic is useless.

Re:Care about roundoff? You better know types.

[RichardJenkins]

>> Right now, these literals are interpreted as integers

Not if you're using python 3 - it will treat numbers as floats if you divide with them. If you're not using python 3, you can have python 2.6 do the same:

>>> 5/2
2
>>> from __future__ import division
>>> 5/2
2.5

Re:Care about roundoff? You better know types.

[Vesvvi]

Well, if that's the question at hand, then I prefer "5" and "2" to be integers. Perhaps this is naive, but my assumption is that standard will cause mistaken use of the wrong type to be catastrophically wrong, and hence easier to detect. An accidental float will happily churn through your calculations through many steps before you run into a situation where it causes a problem, but 5/2=2 gives you dramatic errors very quickly if you're thinking floats.

Gotta love AdSense

[ThatsNotPudding]

The ad attached to this story's RSS summary is for reptile cages.

IDEs for Python

[jipn4]

There are some excellent IDEs for Python. They don't "come with" Python because they are big and somewhat platform dependent. Python IDEs that are useful for scientific work include Python(x,y), Sage, reInteract, and DrPython (you can find them on Google).

You're right that Python syntax is not perfectly adapted to scientific use, but I haven't found it to be a big deal. By being based on a general purpose language, however, you get a huge set of libraries that you simply can't get for MATLAB. And maybe Python will eventually adopt a couple more infix operators for common matrix operations.