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
signature.asc
Description: Digital signature
-- IPOL - Image Processing On Line - http://ipol.im/ contact [email protected] - http://www.ipol.im/meta/contact/ news+feeds twitter @IPOL_journal - http://www.ipol.im/meta/feeds/ announces [email protected] - http://tools.ipol.im/mm/announce/ discussions [email protected] - http://tools.ipol.im/mm/discuss/
