[IPOL discuss] Editorial Board

[Nicolas Limare]

Hi Enric,

> I send this document to all the members of the board so that everyone
> is aware of these important changes.

Here are my comments, from the current 1.03 draft.

> In Brief: Check List, Check Service and Examples
> Requirements specific to M-code:
> * each function in a single file with the same name as the function
> * run the whole algorithm by calling a single function on numeric input
> * does not open windows or plots, does not save or read files
> * the demo program reads and writes image files, but does not open windows
> * available toolboxes: image processing, wavelets, optimization
> General recommendations:
> * max 80 characters per line, max 1000 lines per file
> * algorithmic and auxiliary code in different files
> * detailed comments for every function and every implementation step
> * the M-code runs on any version of Matlab and Octave

* "does not open windows or plots" and "the demo program [...] does not
  open windows": repetition?
* "does not save or read files" and "the demo program reads and writes
  image files": contradiction?
* "the M-code runs on any version of Matlab and Octave" looks too
  ambitious... I'm pretty sure no non-trivial code runs on both
  current Matlab and legacy version from 20 years ago. Maybe the
  phrase could be "M-code runs on Matlab and Octave and does not
  require a specific version of the interpreter"

Most of the M-code requirements are only expressed in this "In Brief"
section, not detailed in the main document (unlike everything else in
these guidelines). Will that be added later before adoption of the new
version?

I have three other additions I propose for this guidelines update, not
related to Matlab:

* In section 2.6, we should not mention CLAPACK, it's unmaintained.
  Instead, we should ask people to use LAPACKE or LAPACK with gcc ABI.
  -> http://nicolas.limare.net/pro/notes/2014/10/31_cblas_clapack_lapacke/

* In section 2.2, I recently found that requiring code to also work
  without OpenMP can make the code more complexe, difficult to read
  and error-prone if we want to use OpenMP features bewind simple loop
  parallelization (my example was with managing a pool of random
  number generator states without sacrificing performance or exact
  reproducibility).
  I think that OpenMP 3.0 is supported by every compiler one yould
  want to use to build a research software, so it is acceptable that a
  software would require OpenMP. The guidelines could be changed to
  "software *should* also be compilable and usable without OpenMP,
  with same results" and "software compiled with openmp *must* work
  and provide same results for any number of execution threads
  (including one)"

* In section 2.7, on "the published software should only use the
  support code via calls to algorithmic functions, and should not be
  based on it", I recently heard an interesting distinction between
  "framework" and "toolbox" software design, and I think it would be
  relevant here.

I will try to propose a phrasing for these three items this week.

Finally, since you are considering allowing Python code too, my quick
opinion on this matter is that Python code is slightly better than
Matlab, but only slightly. The "freedom and openness" of Python are
great, but in IPOL context these things are secondary to stability; a
free and open software that doesn't work is less useful than a
non-free software on a proprietary platform that works. About Python
stability, it's usually "not bad", but far from perfect:
* new features are frequently added to the Python standard lib, so
  minimum version must be carefully chosen
* numpy is essential for scientific computing but has some stability
  issues:
  -> https://khinsen.wordpress.com/2014/09/12/the-state-of-numpy/


-- 
Nicolas Limare
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20150706/88acc8a2/attachment.sig>