[IPOL discuss] matlab to C/C++ translation tools

[Nicolas Limare]

Hi,

To be clear, my idea with MATLAB-to-C++ translations was not to
publish (and hence review) MATLAB code in IPOL and use the C++
translation internally to run the demos. As detailed by Pascal, there
are many obstacles to a good C++ translation of MATLAB code, and we
don't want to publish a MATLAB code and run an even slightly different
algorithm in C++ for the demo.

I was thinking the other way: provide a way for MATLAB-only
researchers to publish in IPOL by using a translation tool, probably
with some assistance. Then the C++ code, re-read and probably modified
by the author or a co-author, would be the only version formally
published, reviewed, and used for the demo. The MATLAB version could
be distributed as a non-reviewed supplementary material. Being
officially non-reviewed avoid any ambiguity: in case of differences
between the C++ and MATLAB implementations, the C++ one is clearly the
one of reference.
 
In my idea, this would be a way to help MATLAB users publish in
IPOL. Otherwise, to have MATLAB in IPOL (despite the "black box"
problem), we at least need people to prepare some software guideline
for this language, decide how to choose between the different versions
of MATLAB, select allowed toolboxes, choose to support mex files
(C/C++? Fortran? external libs?), etc.

> I first want to point out that translation of arbitrary MATLAB code to
> C++ is a monster of a problem.  There are fundamental differences
> between these languages

Agreed, and I suppose the translation tools don't handle "any
arbitrary MATLAB code". On the other hand, most of the research codes
I expect to see use few or none of these difficult-to-translate
features, and many people program in MATLAB like they would do in C
with a matrix datatype and the slicing\ and looping shortcuts.

> Humans are much better than machines at making human-readable code.

> The downside is that translated code might depend on any or all of
> those libraries that MATLAB uses.  We currently allow just a few
> essential and very mature libraries (FFTW, libpng, libtiff, and zlib)
> to avoid maintenance problems.  For example, if a library has a
> security bug that involves API changes to fix, then the published code
> would need to be updated to the new API---but we certainly want to
> minimize any changes to already-published code.

In that case, I think we should use the "support code" section of the
software guidelines[1]. It states that external libraries, if not
in the official list, can be provided in source with the algorithm
implementation. This is already done by a few articles with the Eigen
library.

[1]https://tools.ipol.im/wiki/ref/software_guidelines/#support-code 

-- 
Nicolas LIMARE - CMLA - ENS Cachan         http://limare.perso.math.cnrs.fr/
IPOL - image processing on line                          http://www.ipol.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20130324/fde703d1/attachment.pgp>