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

How to write better scientific code in Python?

zerowithdot.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: How to write better scientific code in Python?

#51

Post by odonnellryan »

mattkrause wrote: post #49
odonnellryan wrote: post #12

Earlier quoted context omitted.

I always feel this is a little unfair. Sure, a Python program and an R program, written the same way, using the same data structures, etc.. is going to usually show the R program is faster. But getting to that point is where the challenge is, and I feel that Python makes thinking about things like data structures and the algorithms you're using (in the case of external libraries) or writing much easier than other lan…

The catch, IMO, is that the need to stay in the numpy sandbox really constrains how you choose data structures and algorithms. Storing N-dimensional points in a Point class, for example, is often so slow as to be a non-starter. Admittedly, it's not just a Python problem: struggles with array-of-structs vs. struct-of-array representations are pretty ubiquitous.

That's true if you need to stay in that sandbox, which isn't always the case!

Re: How to write better scientific code in Python?

#52

Post by hrzn »

jointpdf wrote: post #38

The terrible irony of this post is that they use a completely wrong definition of expected value. They write down an integral...but then implement something totally different. You cannot calculate the EV of a random variable X by taking the mean of random samples drawn from the distribution of X (e.g. try it with the Cauchy distribution—see if you get something approaching the actual EV). The only thing they accompli…

Note that the actual EV of a Cauchy random variable is undefined...

Re: How to write better scientific code in Python?

#53

Post by diarrhea »

Isn’t there also a blatant mistake in the content of the post?

The naive approach for approximating e keeps track of two floats. No arrays. So minimal, aka negligible memory footprint.

Then they introduce iterators, promoting that yielding values is more efficient. Yet suddenly, using islice, they are actually producing and having to store a list of values. So now they do have to worry about memory, as opposed to before. Yet, the article claims/implies the opposite.

Re: How to write better scientific code in Python?

#54

Post by mturmon »

ww_wpg wrote: post #48
jointpdf wrote: post #38

The terrible irony of this post is that they use a completely wrong definition of expected value. They write down an integral...but then implement something totally different. You cannot calculate the EV of a random variable X by taking the mean of random samples drawn from the distribution of X (e.g. try it with the Cauchy distribution—see if you get something approaching the actual EV). The only thing they accompli…

> You cannot calculate the EV of a random variable X by taking the mean of random samples drawn from the distribution of X My understanding of statistics is rudimentary so forgive me but doesn't the sample mean of a normally distributed variable tend towards the expected value for the population?

The sample mean of a Normal RV does tend towards the population expected value, sure.

The GP comment is talking about a Cauchy RV, which has heavy tails. So it has enough probability mass at large values that the expected value is infinite. Discarding constant scale factors, in this case:

  E[X] = Int{0..infty} x * p(x) dx 
       = Int{0..infty} x * (1/x^2) dx 
       = Int{0..infty} (1/x) dx 
       = +infty
So, the sample mean of Cauchy random variates will not converge to any real number.

Re: How to write better scientific code in Python?

#55

Post by mturmon »

sega_sai wrote: post #25

Scientist here, who has been writing code for > 20 years. I don't buy pretty much anything in the article. This was a bunch of opinionated examples. Science programming in my opinion has many different levels which require different approaches and techniques. Very often the first code written will be just a quick and dirty. If the idea worked out, I may refactor it, make the code prettier, speed it up a bit. Very-ver…

Exactly! The real decision you're making with scientific codes in lightly-explored problem domains is, how permanent and versatile of a solution do I need here?

Alas, the OP is deploying some CS abstractions to genericize very simple problems that have already been very well-explored ("find the sample mean").

It's stirring up antibodies among all the investigators who ever over-engineered an approach that was subsequently junked! (shuffles feet awkwardly)

Re: How to write better scientific code in Python?

#56

Post by watersb »

mjburgess wrote: post #14

I think to any audience other than fairly hardcore software engineers this is going to read a little... mad. The first code example was exceptionally clear, from then on, we get increasingly incomprehensible. "Better" it isnt. Scientific code is often write-once, run-once, done. And since mathematics/statistics is largely already formalised at the level of distributions, sampling, and so on -- we shouldn't expect to…

> Scientific code is often write-once, run-once, done.

If only it were so!

Lots and lots of "scientific" code turned out to be re-formatting data. There were some things I wrote in Perl, then re-wrote in Java (which was the standard for non-compute-bound code at the time).

But then there was the actual computation...

Holy cow the code from the 1970s we had to learn, to transform into freaking Java code. And holy cow the poor souls that came after me, howling in torment at my code.

Re: How to write better scientific code in Python?

#57

Post by vitorsr »

jointpdf wrote: post #38

The terrible irony of this post is that they use a completely wrong definition of expected value. They write down an integral...but then implement something totally different. You cannot calculate the EV of a random variable X by taking the mean of random samples drawn from the distribution of X (e.g. try it with the Cauchy distribution—see if you get something approaching the actual EV). The only thing they accompli…

The uncomfortable truth is that merely subscribing to the tenets of current software development “best practices” does not compensate for limitations in knowledge of applied mathematical sciences.

Re: How to write better scientific code in Python?

#58

Post by cjalmeida »

bluenose69 wrote: post #23

This article starts with naive code that is unlikely to be written by working scientists unless they are really quite new this type of work. And, quite quickly, the article reaches a level of detail that might not engage the initial readers. As a scientist with several decades of programming experience, it seems that those who write this sort of naive code are at an early stage of learning, and they might be better o…

Came here to say the same thing. With multiple dispatch and JIT compilation, you’ll go a long way in Julia with the naive version of the code.

Re: How to write better scientific code in Python?

#59

Post by patrick451 »

ad404b8a372f2b9 wrote: post #20
mjburgess wrote: post #14

I think to any audience other than fairly hardcore software engineers this is going to read a little... mad. The first code example was exceptionally clear, from then on, we get increasingly incomprehensible. "Better" it isnt. Scientific code is often write-once, run-once, done. And since mathematics/statistics is largely already formalised at the level of distributions, sampling, and so on -- we shouldn't expect to…

I agree, the bad code at the start is clearer than 99% of the scientific code I've read, without exaggeration. The typing & the abstractions proposed are not only unnecessary but also unrealistic for research code. If scientists want to improve their code, the first and most important step is to get them to use descriptive verbose names for their variables and functions, and to learn the single responsibility princip…

I disagree with the first half. Scientific code is meant to be read with the corresponding journal paper in hand. The journal paper didn't use "descriptive, verbose variable names", and foisting that into the code makes it even less comprehensible. The more the code looks like the paper, the better.

Re: How to write better scientific code in Python?

#60

Post by analog31 »

I've been doing scientific programming for almost 40 years. I'm still learning ways to write better code.

What I've come to realize is that there are some unique things about scientific coding, related to hyper-agile development and the use of specialized domain knowledge. But at the end of the day, good code is good code. I don't say this as an expert, but as an amateur noticing that the issues I read about resemble problems that I've experienced.

That doesn't necessarily mean we should follow the latest software development methods and tools. For one thing, the software development world doesn't even agree on those tools. For another, we're typically (ballpark guess) 10 or even 20 years behind the software world in terms of the complexity of our programs, and the size of our teams. We can safely get away with older techniques that are easier for us to learn and apply.

Also, there are things that we don't need, such as intuitive GUIs, seamless error recovery, installers, devops, monetization, file formats, and so forth. For a very small script, crashing is a perfectly reasonable way to handle something like bounds checking, and a language with decent error messaging will be 100x more sophisticated than anything we're likely to come up with ourselves.

I think the way to help us learn to code is to include good programming practices inline with instruction on coding. My Pascal textbook was that way. For instance variable scoping was introduced with an explanation about how to choose good scoping, such as why to avoid globals.

Refactoring might be the biggest thing: Teaching the discipline of going through old code and improving it. Human nature says that we will cut corners when we're having fun and focusing on the science and results. Also, most of us are learning this stuff on the go -- many of us were not hired to program, and our bosses may be unaware that we're doing it. So we have to circle back, and tune things up. This is how we do exploratory science anyway. My habit is, when I learn a new technique, I go back into some old code and try to apply it.

Testing is important too, but maybe in a different sense: A huge tool for testing scientific code is visualization of intermediate results.

Post reply on HN