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

31–40 of 103 posts

Re: Why Python rocks for research

#31

Post by ogrisel »

hogu wrote: post #19
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…

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 documentation on the other panel.

Re: Why Python rocks for research

#32

Post by nurbl »

kwantam wrote: post #28
sintesoro wrote: post #21

Python is good, you could also consider Maxima. A single example: f(x):= x^2+3 x+7; Maxima provides: Symbolic computation, blas and laplack integration for numeric algebra, 500 pages manual in several languages, a complete library for statistics, differential equation, calculus, series. Graphics with matplotllib. Also maxima language is not much complicate that python: for i in range(10):print i i versus for i:0 thru…

Maxima rocks for symbolic math. I prefer it to Mathematica, which is saying a lot. In contrast, octave always feels like "almost-Matlab" and I still prefer the latter. Also see wxMaxima, which will (among many other things) produce LaTeX for you.

If you haven't already, you might also want to check out Sage (http://www.sagemath.org/) It uses python to "glue" together other free math tools (e.g. Maxima) into a unified system with a nice interface.

Re: Why Python rocks for research

#33

Post by dagw »

sintesoro wrote: post #21

Python is good, you could also consider Maxima. A single example: f(x):= x^2+3 x+7; Maxima provides: Symbolic computation, blas and laplack integration for numeric algebra, 500 pages manual in several languages, a complete library for statistics, differential equation, calculus, series. Graphics with matplotllib. Also maxima language is not much complicate that python: for i in range(10):print i i versus for i:0 thru…

Python has sage and sympy for doing symbolic math. Although admittedly they're quite primitive compared to maple and mathematica (haven't used Maxima, so I can't really compare)

Re: Why Python rocks for research

#34

Post by thesz »

Dn_Ab wrote: post #13
vog wrote: post #5

Earlier quoted context omitted.

> There are an awful lot of languages that provide ... Still, how many of them have a fast interactive interpreter ("command line") with a decent usability? How many of those provide good libraries for numerical as well as symbolic math? With an API that is easy to write, to understand and to extend? Python may not be the only language with those qualities, but there aren't many languages (and ecosystems around them)…

There are Ocaml, F# and Clojure with some combination of great tools, speed (clojure addressed this recently I think but i only have visual experience with clojure), light syntax, books and documentation, repl,excellent platform, wide libarary choice and or decent interop with C. Also F# is doing some really cool stuff to do with datasets awareness in the language. Haskell seems a perfect fit for mathematical use and…

I am with you on Haskell.

It counts on Freedom, Readability, Documentation System (including lhs2tex which will turn your "integrate f 0 a" into \Int_0^a{f dx}), High-level vs low-level, Standard library (including hackage/cabal), Data structures, Module system, Calling syntax, Default arguments (currying), Multiple programming paradigms (there was a saying that Haskell is the best imperative language). It partially counts on most other points.

Myself, I choose Haskell for my research project, as it was best language on (expressiveness times safety) scale. Strong type system certainly helps sweeping out errors.

Re: Why Python rocks for research

#35

Post by BrandonM »

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_boolean):
      do_stuff()

  if (the_result_of_this_function(on_this_arg) == 10 and
      this_overly_descriptive_boolean):
      do_stuff()
To me, the first one is quite clearly a continuation line (no statement can start with "and"). The second requires closer inspection.

Re: Why Python rocks for research

#36

Post by ogrisel »

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…

If your system is complicated enough (which can be the case for complex machine learning or NLP algorithms), an 8 pages paper (common limit for many conferences) cannot describe all the implementation details but those implementation details might be very important to be able to reproduce the results.

Hence code should be both published, well documented and readable.

Re: Why Python rocks for research

#37

Post by variety »

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…

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 90s / early naughts.

Re: Why Python rocks for research

#38

Post by njharman »

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…

>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.

Re: Why Python rocks for research

#39

Post by njharman »

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…

PEP8 is wrong on several counts. It even understands this the first section (after introduction) is "A Foolish Consistency is the Hobgoblin of Little Minds" which is about the spirit of pep8 readability and consistency and explains some situations when you should violate pep8.

Re: Why Python rocks for research

#40

Post by Avshalom »

ogrisel wrote: post #36
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…

If your system is complicated enough (which can be the case for complex machine learning or NLP algorithms), an 8 pages paper (common limit for many conferences) cannot describe all the implementation details but those implementation details might be very important to be able to reproduce the results. Hence code should be both published, well documented and readable.

Fair enough. When I think of scientific uses of python I think astronomy, atmospheric physics, finite element analysis and linear systems using existing techniques...

Existing techniques in general really. Fields where the interest is the data and the implications of the data. Fields like ML and NLP where the algorithm/technique is the thing of interest then yeah sure the code is important.

Post reply on HN