Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Python rocks for research

stat.washington.edu

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Why Python rocks for research

#81

Post by stoney »

hogu wrote: post #60
rdouble wrote: post #46

I've wasted most of my professional life tweaking various unix software to make it work. However, the typical scientific python setup proved to be too frustrating to install on OSX. The recommended solution is to just buy the Enthought distro. If I'm paying for software anyway, why is Enthought better than Matlab?

disclaimer I work for enthought I did my whole phd in matlab. EPD is much cheaper and is free for academics even if it weren't free, I would use it anyways. but it really isn't why is EPD better than matlab, it's why python is better than matlab. matlab is a domain specific application with a domain specific language. It doesn't work well with things outside of its domain. python is a general purpose language (And as…

Is there something similar to Simulink available for Python yet? That's pretty much the only killer feature of Matlab for me these days. Any other number crunching I do in Python.

Re: Why Python rocks for research

#82

Post by b_emery »

> In MatLab everything is flat – all functions are declared in the global namespace. However, this discourages code reusability by making the programmer do extra work keeping disparate program components separate. In other words, without a hierarchical structure to the program, it’s difficult to extract and reuse specific functionality.

I completely disagree. Reusable Matlab code has been my holy grail for the last couple of years. The key is to break out specific functionality as subfunctions. When these are abstracted and generally useful elsewhere, then they become new tools for the toolbox. The subfunctions also make great starting points for repurposing code. This layout results in much less work.

Re: Why Python rocks for research

#83

Post by maurits »

hogu wrote: post #79
maurits wrote: post #72

I feel this article is somewhat unbalanced in its single minded rejoice for a certain tool/environment. So in the same spirit here come a couple of reasons not to switch from Matlab to Python, all stemming from my experience when I decided to try to switch from Matlab to Python/C - installing all these packages on (any) system is painful. Different versions don't play together or don't work (yet) on some platform and…

install is painful - enthought python distribution does make it pretty painless, but its not free for non-academics agreed on documentation actually I think python's visualization capabilities are more powerful, have you looked at mlab? the 3d capabilities there are insane I use python because I can do rapid prototyping, and turn it into a full application with the same code base. did you ultimately go back to matlab…

Well, I only got it all the work ( on OS X ) like an hour or two ago, and am currently happily learning&exploring.

I wanted to venture beyond Matlab because for what I am currently doing the environment and language is to limited, yet I do not wish to prototype in C++. Python together with some libraries seemed to be a deal in heaven. I also thought it would function as a better stepping stone towards an actual application.

Re: Why Python rocks for research

#84

Post by tel »

b_emery wrote: post #82

> In MatLab everything is flat – all functions are declared in the global namespace. However, this discourages code reusability by making the programmer do extra work keeping disparate program components separate. In other words, without a hierarchical structure to the program, it’s difficult to extract and reuse specific functionality. I completely disagree. Reusable Matlab code has been my holy grail for the last c…

It's absolutely true that using more functions makes your code more maintainable. It's also absolutely true that nearly every other language on the planet does this better than Matlab.

Re: Why Python rocks for research

#85

Post by Anon84 »

hogu wrote: post #66
rdouble wrote: post #63

Earlier quoted context omitted.

Thank you, that is the kind of response I was looking for. I will take a look at Enthought.

you WILL get frustrated by some things - some of the matrix concatenation operations are less convenient, some of the libraries are less polished, it's been worth it for me. msg me if you need help. use IPython, not just python shell for interactivity. also checkout 3d datavisualization with mayavi, that stuff is really awesome.

Is there a mayavi tutorial somewhere? It looks pretty interesting, but I could never figure it out.

Re: Why Python rocks for research

#86

Post by hogu »

stoney wrote: post #81
hogu wrote: post #60

Earlier quoted context omitted.

disclaimer I work for enthought I did my whole phd in matlab. EPD is much cheaper and is free for academics even if it weren't free, I would use it anyways. but it really isn't why is EPD better than matlab, it's why python is better than matlab. matlab is a domain specific application with a domain specific language. It doesn't work well with things outside of its domain. python is a general purpose language (And as…

Is there something similar to Simulink available for Python yet? That's pretty much the only killer feature of Matlab for me these days. Any other number crunching I do in Python.

not that I know of

Re: Why Python rocks for research

#87

Post by hogu »

Anon84 wrote: post #85
hogu wrote: post #66

Earlier quoted context omitted.

you WILL get frustrated by some things - some of the matrix concatenation operations are less convenient, some of the libraries are less polished, it's been worth it for me. msg me if you need help. use IPython, not just python shell for interactivity. also checkout 3d datavisualization with mayavi, that stuff is really awesome.

Is there a mayavi tutorial somewhere? It looks pretty interesting, but I could never figure it out.

http://conference.scipy.org/scipy2010/tutorials.html

there was a mayavi tutorial, and the files are available at the link

Re: Why Python rocks for research

#88

Post by leot »

Avshalom wrote: post #29
ogrisel wrote: post #27

Earlier quoted context omitted.

That must change. Science must be reproducible. Other researchers should be able to dive into each others code quickly to understand the impact of implementation details.

Well yes and no, if they're doing their job right they describe the method in such a way that you don't need their code to reproduce their results. Code should not be Documentation. Further nobody trusts anybody's code anyway unless it's just a couple of trivial calls to a pre-vetted software package like IRAF, AIPS (to name some astronomy related one), or LAPACK. So generally they don't want your code. the exception…

Python, unlike any other language I've dealt with, lends itself very nicely to producing stuff that's reusable and easy to understand. I chalk this up to

* lack of elitism in documentation (e.g. there are always plenty of examples)

* lack of elitism in conventions for code use: everything "just works", generally without any boilerplate

* installing libraries is a snap, and the whole module organization system is intuitive and elegant

* assumption that anything that's not a script is a library

* documentation conventions (doctests, e.g., are a nice stepping stone to good documentation _and_ code testing)

* the "there's only one way to do it" attitude

* large standard library

On the other topic: you are describing the way research works "today", which is actually pretty poorly (why, e.g., does all data need to be surrounded by so many words of introduction and discussion? why can't I just add something to someone else's work like I can add to an open source project?). This model of research will change, at one point or another, to resemble the much more efficient, effective, and fun, open source project model.

Re: Why Python rocks for research

#89

Post by wildanimal »

levesque wrote: post #9
agconway wrote: post #4

Python rocks, but Python + R + bash rocks way harder for research

R is definitely powerful and a good part of any scientific data analysis toolkit. I use python, ipython, matplotlib, numpy and R. I call my R scripts directly from python using rpy.

Agreed. I use Python for heavy shell-scripting and text-processing (though R surprisingly does have respectable facilities for all but the most overwhelming of these tasks) and R for the rest of the analysis. I've thought about switching to NumPy/SciPy as it's part of Python to integrate everything, but R's data frame, factors, and reshape, plyr, and lattice packages makes you think very differently about how to approach the data - and hard to go back to lower-level manipulation of arrays; not to mention all the stats/graphics packages which are very easy to install and apply. And documentation of its functions is superb.

Re: Why Python rocks for research

#90

Post by wildanimal »

wgrover wrote: post #55
rdouble wrote: post #46

I've wasted most of my professional life tweaking various unix software to make it work. However, the typical scientific python setup proved to be too frustrating to install on OSX. The recommended solution is to just buy the Enthought distro. If I'm paying for software anyway, why is Enthought better than Matlab?

I've never had any problems putting a research-grade python setup on OSX - just use the .dmg installer files files available for python (2.6.X for compatibility), numpy, scipy, and matplotlib. But I agree that the Enthought Python Distro is also a good alternative (if a little bloated for my needs), and it's also free for academics.

When I tried to use easy_install with the EPD it tried to take me to their repository, for which we don't have appropriate permissions? So I sucked it up and installed some from .dmg's and others from source (matplotlib was difficult). And I found out just because it's Python doesn't mean it's portable - for instance NumPy/SciPy is hardly ever installed on other machines (it's not trivial, as is written here many times), and I find that administrators won't update their Python installation so I've had to re-write bits of my code to accommodate Python 2.3-2.4 at times! But all said, it's a nice tool and hopefully these installation/ version issues will work itself out.
Post reply on HN