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

51–60 of 103 posts

Re: Why Python rocks for research

#51

Post by [deleted] »

njharman wrote: post #38
Avshalom wrote: post #29

Earlier quoted context omitted.

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…

>Code should not be Documentation. Code is for humans to read, that it compiles/interprets to a program is a side effect. Otherwise we'd all be passing around binaries (or byte encoded files) with our thick stacks of documentation.

[deleted]

Re: Why Python rocks for research

#52

Post by hyperbovine »

RodgerTheGreat wrote: post #3

This article makes some fairly convincing arguments that Python is a more flexible tool than Matlab or Perl, but I can't help but come away with the sense that the author hasn't tried many other languages. There are an awful lot of languages that provide iterators, a powerful set of data structures, extensive libraries and facilities for structuring and maintaining large codebases. .Net languages (maybe F# would be g…

It's all about Numpy. Mayavi, IPython, mlab & friends are great for when I need to plot things or look at data, but Numpy is the workhorse I keep coming back to day in and day out. And also, the thing I wish for most when I have to use other languages. The combination of the speed of C and the elegance of, well, anything that is not C, is hard to beat. Once you get down the basics of array broadcasting, types, etc., it's possible to do some amazingly elegant things in Numpy, and quickly too. The numpy library has seemingly every array function I have ever wanted. If I were Matlab I'd be scared :-)

Re: Why Python rocks for research

#53

Post by miloshasan »

Python is awfully close to being a superior (and free) replacement for Matlab, but there are a few annoyances that keep preventing me from switching forever. Unfortunately, these are mostly not bugs but bad design that is believed to be correct by the core developers, so it is unlikely to ever change:

- Matrices are a pain. The r_[] and c_[] operators could be a reasonable replacement for Matlab's elegant matrix construction syntax, but they do not work as expected (as smart hstack and vstack), instead doing something completely different and inconsistent for vectors and matrices.

- Tensors are a bigger pain. Matlab has a very well-defined semantics for operations like permute and reshape; in NumPy these operations sometimes create just a view, at other times they reshuffle the memory contents. I know the idea was to "protect" the user from having to know the memory layout of data, but this idea is bad.

- Ipython is great in every way except when it comes to reloading parts of your program. After any tiny change to your code, the only safe thing to do is to quit ipython and start it again. All the other options (run, reset, reload...) make some secret and wrong assumptions on what you want to reload. In contrast, this works flawlessly in Matlab.

Re: Why Python rocks for research

#54

Post by Goladus »

ogrisel wrote: post #31
hogu wrote: post #19

Earlier quoted context omitted.

I wasn't aware of pep8 when I started, most science people arrive at python from a different path. What I mean is, for a long time I knew much more about numpy than about python itself. there are some things in pep8 that are bad for science, the spaces around operations, and also the 80 chars to a line... scientific expressions are often long and complicated, yes you can do it while adhering to pep8, but its kind of…

The 80 chars limit has a justification: expressions that don't fit on 80 chars (or two lines using parens) are not readable anyway. In such a case temporary variables with meaningful names would both help respect the 80 chars constraint and make the expression easier to understand by the reader. Furthermore having 80 chars is great to have vertically split editors with the code on one panel and the tests or the docum…

> The 80 chars limit has a justification: expressions that don't fit on 80 chars (or two lines using parens) are not readable anyway

I disagree. There are many cases, especially after 2-3 levels of indentation, where 80 characters is an unreasonably narrow space. I don't have a strong preference for reading code within 80 characters. And I'd much rather comments use 80 characters plus indentation rather than worry about whether I've got my screens vertically split.

> Furthermore having 80 chars is great to have vertically split editors with the code on one panel and the tests or the documentation on the other panel.

Having lines here or there that go beyond 80 characters doesn't completely prevent you from doing this, and having an entire statement on a single line of code makes line-based tools like grep or kill-line more effective.

Limiting to 80 characters is a good idea, but it's easy to see that there are a few significant tradeoffs, and that someone trying to get something done is not going to want to bother.

Re: Why Python rocks for research

#55

Post by wgrover »

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.

Re: Why Python rocks for research

#56

Post by mfukar »

njharman wrote: post #38
Avshalom wrote: post #29

Earlier quoted context omitted.

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…

>Code should not be Documentation. Code is for humans to read, that it compiles/interprets to a program is a side effect. Otherwise we'd all be passing around binaries (or byte encoded files) with our thick stacks of documentation.

What's your take on the multitude of software that you buy together with all the README files, Word or PDF documents describing how to use the software, what does it do, and all that jazz? Do we (humans) get to view all that code and see what Microsoft Office Word 2007 can do for us?

Re: Why Python rocks for research

#57

Post by cageface »

phren0logy wrote: post #26
djacobs wrote: post #16

Earlier quoted context omitted.

I'm in the same boat and it seems like several others as well. I'm fine moving to Python for the moment, but I wonder how the Ruby community will ever know if there's enough of a demand for scientific tools to merit their development?

I prefer Ruby generally, but honestly Ruby and Python are sufficiently similar that I'd rather smart programmers put their time to good use doing something other than reimplementing Python's science libs. I think that making some tools available in a totally different language (maybe something functional) would be much more useful, because it would allow for a very different approach to the problem if needed. In a pe…

Agreed. There's only so much skilled labor available for this kind of thing.

This is exactly why I'm focusing on Python lately. Ruby is a great language but I don't want to be pigeon-holed as a web guy forever. I've already done over 10 years of web dev and I'd like to try out a couple of new problem domains before I kick the bucket.

Re: Why Python rocks for research

#58

Post by variety »

expeditious wrote: post #49
variety wrote: post #37

Earlier quoted context omitted.

actually, he doesn't make any assertions that Python is more flexible than Perl (which would be rather doubtful), only that it is more readable (which, as a perlista, I'm sad to say is probably true). but I also get the sense that this is the first time he's seriously delved into a dynamic programming language. much of what he's saying about Python is exactly what bioinformaticists were saying about Perl in the late…

The thing about readability of Perl vs. Python ... I dunno. I don't think it's the syntax itself that causes Perl to have some readability issues. Stuff like `$foo =~ s/bar/baz/g` or `join '-', split( q{ }, $a_str)` is very readable. Context and corner cases maybe makes readability suffer. For example, what does `m///g` do in scalar vs. list context? I don't recall.

you might say that Perl's lack of (obvious, first-pass) readability is a two-headed dog from hell:

- it's a (very) good thing, in that there's -a- -lot- of expressive power hiding in those corner cases (esp list v. scalar context). in fact perl is nearly unique in the degree to which it embraces, rather than seeks to quash the potential for nuance and flexibility to be found in the various eddies and whirlpools that lie "between" non-whitespace elements of code. this is something that goes to the deepest intellectual roots of the language (to be more like the way the human brain thinks, rather than the way machines think).

- it's a (very) bad thing, in that the same "power" for expressiveness just represents little more than an endless stream of banana peels to most first time users (understandably sending many of them running into the arms of the other major dynamic programming languages). and that it just makes it too damn easy to write (barely) functional, pothole-laden frontline scripts (such that Perl is partly responsible for "scripting" being such a dirty word, in many quarters).

another aspect people don't like to talk about its nearly coprophilic fondness for not just nuanced and context-sensitive, but intentionally obtuse syntax (the impossible to remember "special" variables such as $[, $;, $' etc being probably the worst examples).

this also (sadly) has a lot to do with the community's deference to the aesthetics of its original authors (and is also plenty understandable, given the extent to which unabashed ugliness -- as personified by makefiles, shell languages and macro-laden C and C++ -- ruled the day at the time).

unfortunately it also blinds a lot of Perl folk to the fact that beloved muse just happens to look awful darn cluttery (or worse) to many reasonably intelligent people who come from more "modern" programming backgrounds (or who at least came onto the scene comparatively recently).

Re: Why Python rocks for research

#59

Post by zephyrfalcon »

BrandonM wrote: post #35
ogrisel wrote: post #12

And the corollary: Why do researchers never respect the PEP8 when they write python code? Yes I am a bit overreacting since the blog post is very well written and I actually agree 100% with the content. But please people: respect the PEP8 [1]. It makes your readers feel at home while reading your code. It is very important if you want to get new contributors to your project. See [2] for instance. [1] http://www.pytho…

From PEP 8: > The preferred place to break around a binary operator is after the operator, not before it. I'd be interested in hearing the justification for this rule. I think that leading a continuation line with the binary operator makes it super-clear that it is a continuation line. What is the benefit of the preferred style? Compare: if (the_result_of_this_function(on_this_arg) == 10 and this_overly_descriptive_b…

I would write:

  if the_result_of_this_function(on_this_arg) == 10 \
  and this_overly_descriptive_boolean:
      do_stuff()
Indenting the second line of the if statement would, at first glance, indicate that it's part of the block instead. Then again, it depends. If it was the header of a def statement, I would follow the PEP, e.g.

  def __init__(self, width, height,
                     color='black', emphasis=None, highlight=0):
On a side note, I once did the "Art & Logic challenge" [http://www.artlogic.com/] and they use guidelines that apply to several languages, e.g. you would use the same formatting style for C++ and for Python, if at all possible. Much of it flies in the face of PEP 8.

Re: Why Python rocks for research

#60

Post by hogu »

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 such, has good general purpose constructs) but it happens to have excellent scientific and mathematical libraries. This is useful when you actually have to apply your research and build an application.

numpy is also better for large data, because slicing arrays does not create copies of them (you can make it do so if you want to, but it doesn't by default) in matlab, slicing large arrays can cause you to run out of memory.

Cython makes it really easy to start out with python, and then optimize your code down into C.

with python you can run your calculations over a massive compute grid. Use messaging libraries like PyZMQ to distribute your data and result, and build real time GUIs to consume the final results.

- a matlab cluster is quite expensive

- chacko - another enthought python library which is free and open source is great for real time datavisualization, matlab does not have anything equivalent.

- python has a large number of messaging libraries, with matlab I think you're stuck with MPI.

Matlab always made me feel limited. I would work on a problem, and then reach a point where Matlab could not do what I needed to do.

That rarely happens to me with python.

Post reply on HN