Is Python appropriate for algorithms focused on scientific computing? [closed]

Question

My interests in programming lie mainly in algorithms, and lately I have seen many reputable researchers write a lot of their code in python. How easy and convenient is python for scientific computing? Does it have a library of algorithms that compares to matlab's? Is Python a scripting language or does it compile? Is it a great language for prototyping an algorithm? How long would it take me to learn enough of it to be productive provided I know C well and OO programming somewhat? Is it OO based?

Sorry for the condensed format of questions, but I'm very curious and was hoping a more experienced programmer could help me out.

Answer 1

How easy and convenient is python for scientific computing?

Scipy/NumPy.

Does it have a library of algorithms that compares to matlab's?

Yes.

Is Python a scripting language or does it compile?

Interpreted.

Is it a great language for prototyping an algorithm?

Yes.

How long would it take me to learn enough of it to be productive provided I know C well and OO programming somewhat?

Depends.

Is it OO based?

Yes.

Answer 2

How easy and convenient is python for scientific computing?

Very! You should try attending the SciPy conferences (every year there's one in the US and one in Europe) to get a real feeling for that, but even just the rest of the scipy.org site should give you some impression.

Does it have a library of algorithms that compares to matlab's?

I don't know matlab, but the amount of stuff available in/for Python is staggering.

Is Python a scripting language or does it compile?

Python is a language, and it offers many implementations (all open-source).

The most popular one, CPython, compiles sources to its own bytecode which its virtual machine then executes (the compilation is very fast and happens transparently when needed, but compiled files are typically stored on disk and recompiled only when needed). That's very similar to Java/JVM or C#/.Net, except the compilation step can be subsumed with the execution step (but of course you can have a build system which compiles ahead-of-time, if you want).

Jython compiles to JVM bytecode, which a JVM then executes; Microsoft's IronPython (their first fully open source project, I believe) compiles to CRL (".Net bytecode") which .Net and Mono can then execute. They both support both just-in-time and ahead-of-time compilation to their respective bytecodes.

PyPy can compile Python sources to many things, including (for a subset of Python) directly (ahead-of-time) to native machine language or (for all of Python) to an intermediate code which is then compiled to machine language in just-in-time fashion. PyPy is incredibly flexible in terms of the kind of build systems you can set up. (Its name comes from the fact that it's coded in Python itself, and that's surely still a plus in many terms, but the speed of the code it makes, and its flexibility, are its biggest strengths today).

These four implementations are all production quality at this time (historically, they became so in the order I've listed -- PyPy most recently, and actually pretty recently indeed, but I like what I see there very much these days).

Is it a great language for prototyping an algorithm?

I can't think of a better one; see chapter 18 of the Python Cookbook, especially the introduction by Tim Peters, for more. That intro is entirely readable in the Google Books link I just gave, and I really can't do it justice in what's already going to be a long SO answer; please click on the link and read that intro!

How long would it take me to learn enough of it to be productive provided I know C well and OO programming somewhat?

When I first met Python, after browsing through the tutorial, I decided to give it a try when I had a free weekend with my family away: I'd devote one weekend (Friday 6pm to Sunday midnight, or, well, wee hours on Monday perhaps) to learning the language by doing in it a CGI web app to compute and show various kinds of bridge probabilities (as a bridge enthusiast, but known in the field mostly through my probability and computer work about it, it's a problem I've long loved: I learned Fortran back in my freshman year, though at that time as an EE major I wasn't supposed to do programming until junior year, by punching cards to solve that kind of problem;-).

Of course I didn't expect to finish the task from scratch in 54 hours or so (minus sleep time;-) while teaching myself the language and its library (CGI and the needed algorithms I already knew well), but I wanted to see how far I would get (evaluating Python vs the other languages I was a guru in at the time, mostly perl and C++).

Less than 24 hours later (admittedly having slept little that night, I was just too excited), I stepped back and had to admit that I was finished -- not only did my little CGI web app have all the functionality I had had in mind, but I had also made it able to give output in different natural languages by building from scratch a little templating system (I knew there were plenty -- that's why I named mine yaptu, "Yet Another Python Templating Utility" -- but I just didn't have time to learn anything outside of the language and standard library... rolling my own was faster;-).

That's when I irretrievably fell in love with Python. Not long after, I ended up leaving my existing high-flying career for a spell writing books and freelancing with Python, and a few years later I moved across an ocean and two continents to join one of the largest companies extensively using Python (my current employer, Google) -- in the meantime having re-married (to my current wife, Anna -- she was also co-author in one of my books and the first woman Member of the Python Software Foundation). Our "vanity" license plate reads P♥THON...;-). So, OK, I'm biased. But it all started with those <24 hours in which I accomplished more than I had hoped to do in >54 hours (despite being, like all SW developers, an incurable optimist whenever it comes to "how long will it take me to do X" for any SW-centered X;-).

Is it OO based?

Yes, but multi-paradigm (like C++... but even more than C++) -- you don't have to use classes when you don't need them, and it has reasonable support for functional programming too (definitely not as deep as "true" FP languages like Haskell, but still very useful for many tasks).