--On 5 janvier 2015 08:43:45 +0000 Sturla Molden <sturla.mol...@gmail.com> 
wrote:

> To me it seems that algorithms in scientific papers and books are
> described in various forms of pseudo-code.

That's indeed what people do when they write a paper about an algorithm. 
But many if not most algorithms in computational science are never 
published in a specific article. Very often, a scientific article gives 
only an outline of a method in plain English. The only full documentation 
of the method is the implementation.

> Perhaps we need a notation
> which is universal and ethernal like the language mathematics. But I am
> not sure Python could or should try to be that "scripting" language.

Neither Python nor any other programming was designed for that task, and 
none of them is really a good fit. But today's de facto situation is that 
programming languages fulfill the role of algorithmic specification 
languages in computational science. And I don't expect this to change 
rapidly, in particular because to the best of my knowledge there is no 
better choice available at the moment.

I wrote an article on this topic that will appear in the March 2015 issue 
of "Computing in Science and Engineering". It concludes that for now, a 
simple Python script is probably the best you can do for an executable 
specification of an algorithm. However, I also recommend not using big 
libraries such as NumPy in such scripts.

> I also think it is reasonable to ask if journals should require code as
> algorithmic documentation to be written in some ISO standard language like
> C or Fortran 90. The behavior of Python and NumPy are not dictated by
> standards, and as such is not better than pseudo-code.

True, but the ISO specifications of C and Fortran have so many holes 
("undefined behavior") that they are not really much better for the job. 
And again, we can't ignore the reality of the de facto use today: there are 
no such requirements or even guidelines, so Python scripts are often the 
best we have as algorithmic documentation.

Konrad.

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to