[SciPy-dev] Online SciPy Journal

Jonathan Guyer guyer at nist.gov
Sat Sep 30 10:21:13 EDT 2006


On Sep 30, 2006, at 3:42 AM, Bill Baxter wrote:

> Novelty is always one of the main criteria for
> reviewing anywhere I've sent papers.  So something like "implementing
> an FFT module for SciPy" wouldn't go over well with any of the venues
> I'm familiar with.  "There's nothing novel about the FFT" would be the
> rejection.

Which is a shame, because I've encountered several instances lately  
of "nothing novel algorithms" that don't work as published. When you  
finally dig up somebody's code that "works", you discover that  
there's some little hack needed, or just some branch of the algorithm  
that they forgot to publish. This isn't unique to computational  
science, of course; the experimental world is full of results that  
can only be obtained by their "discoverers" (code fusion, anybody?);  
but I think it's particular inexcusable in the computational realm,  
since it's entirely feasible to hand your entire "experimental  
apparatus" to anybody that wants it.

I think it would be a wonderful thing for the reproducibility of  
scientific results if authors were required to publish their code and  
their data instead of just a description of their code and plots of  
their data.

Nonetheless, I understand there needs to be some sort of distinction  
between "yet another implementation of a very well understood and  
accepted algorithm" (FFT is arguably in this category) and "here's a  
way to do something novel along with how I actually did it". Taking a  
bunch of accepted algorithms and putting them together in a way that  
they can talk to each other and are reliable and the whole thing  
makes sense *should* be interesting to the scientific community.



More information about the SciPy-Dev mailing list